From 7d6a0754701c18661afe897a8d6b5eedf418de8a Mon Sep 17 00:00:00 2001 From: Nehanth Date: Tue, 20 Oct 2026 20:50:20 -0400 Subject: [PATCH] feat(osv): grade dependency reachability and promote reachable CVEs MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Make the dependency-CVE path deterministic at the two steps where it was silently losing reachable advisories to run-to-run variance. - threat model: buildContext now emits a required, graded "Dependency reachability" block — one line per dependency (HIGH/MEDIUM/LOW + call site + consequence), covering every advisory osv found, instead of a soft "note where it's used" prose instruction that collapsed into a vague summary on noisier runs. - investigation: CORE_PROMPT now treats those grades as promotion guidance — HIGH with a confirmed call site is a finding to promote (not "just a library default"), MEDIUM is judged on its merits, LOW stays as context unless a missed call site is found. Reachability is gated upstream; the investigation confirms and writes it up. Verified on fastapi: the Starlette unbounded-body DoS now promotes to a located finding (dropped as context in prior runs), while transitive anyio/idna stay LOW with zero false-positive findings. Co-Authored-By: Claude Opus 4.8 --- docs/dependency-cves.md | 3 ++- .../deepsec/src/__tests__/osv-enrich.test.ts | 15 +++++++++++++++ packages/deepsec/src/setup/osv-enrich.ts | 18 +++++++++++++++++- packages/processor/src/prompt/core.ts | 8 ++++++++ prompt-samples/01-empty-project.md | 8 ++++++++ prompt-samples/02-nextjs-tsx-batch.md | 8 ++++++++ prompt-samples/03-django-py-batch.md | 8 ++++++++ ...olyglot-python-batch-filters-other-techs.md | 8 ++++++++ ...lot-typescript-batch-filters-other-techs.md | 8 ++++++++ prompt-samples/06-polyglot-mixed-batch.md | 8 ++++++++ prompt-samples/07-overflow-fallback.md | 8 ++++++++ prompt-samples/08-with-info-and-append.md | 8 ++++++++ prompt-samples/09-laravel-php-batch.md | 8 ++++++++ prompt-samples/10-rails-rb-batch.md | 8 ++++++++ prompt-samples/11-go-multi-framework-batch.md | 8 ++++++++ 15 files changed, 130 insertions(+), 2 deletions(-) diff --git a/docs/dependency-cves.md b/docs/dependency-cves.md index c70be2c6..08291e93 100644 --- a/docs/dependency-cves.md +++ b/docs/dependency-cves.md @@ -47,7 +47,8 @@ The step calls external binaries and degrades cleanly when they are absent (it l - `data//setup/osv-findings.json` records the vulnerable packages and their advisory IDs. This file and the resolver's evidence files live under the gitignored `setup/` directory. - The threat model (`INFO.md`) gains a **Known-vulnerable dependencies** section. Rows resolved from a version range are labeled as such, since that version may not be the one installed. -- Matcher generation receives the threat model, so an advisory whose vulnerable call is reachable in the code gets a matcher and becomes a scan candidate. The investigation phase then judges reachability and writes the finding. +- That section requires a **Dependency reachability** verdict with one graded line per dependency (`HIGH`/`MEDIUM`/`LOW`, the vulnerable call site as `file:line` or "not called", and the consequence if reached). Fixing this structure keeps a reachable advisory from being summarized away as prose, so the same dependency is graded the same way across runs. +- Matcher generation receives the threat model, so an advisory graded reachable gets a matcher aimed at its call site and becomes a scan candidate. The investigation phase then confirms reachability and writes the finding. ## Security notes diff --git a/packages/deepsec/src/__tests__/osv-enrich.test.ts b/packages/deepsec/src/__tests__/osv-enrich.test.ts index bfcbbf39..c8301483 100644 --- a/packages/deepsec/src/__tests__/osv-enrich.test.ts +++ b/packages/deepsec/src/__tests__/osv-enrich.test.ts @@ -233,6 +233,21 @@ describe("buildContext resolved-version labeling", () => { expect(ctx).not.toMatch(/`log4j-core@2\.14\.1` \(resolved/); }); + it("emits the required graded reachability block naming every dependency", () => { + const ctx = buildContext([ + { name: "starlette", version: "0.46.0", vulns: [{ id: "X" }], resolved: true }, + { name: "anyio", version: "3.6.2", vulns: [{ id: "Y" }], resolved: true }, + { name: "idna", version: "2.8.0", vulns: [{ id: "Z" }], resolved: true }, + ]); + // the structured directive is present and demands a per-dep graded verdict + expect(ctx).toContain("### Dependency reachability (required)"); + expect(ctx).toMatch(/HIGH\|MEDIUM\|LOW/); + // every dependency is named in the directive so none can be silently dropped + expect(ctx).toContain("`starlette`"); + expect(ctx).toContain("`anyio`"); + expect(ctx).toContain("`idna`"); + }); + it("flags a package as resolved via resolvedPaths", () => { const raw = JSON.stringify({ results: [ diff --git a/packages/deepsec/src/setup/osv-enrich.ts b/packages/deepsec/src/setup/osv-enrich.ts index 9161b14b..65d1e313 100644 --- a/packages/deepsec/src/setup/osv-enrich.ts +++ b/packages/deepsec/src/setup/osv-enrich.ts @@ -442,11 +442,27 @@ export function buildContext(hits: OsvPackageHit[]): string { const vulnLines = h.vulns.map((v) => ` - ${v.id}${v.summary ? `: ${v.summary}` : ""}`); return [`- \`${h.name}@${h.version}\`${marker}`, ...vulnLines].join("\n"); }); + // Every dependency below must appear in the required verdict block, so the + // review always produces a graded, line-anchored reachability judgment per + // dependency. Leaving this to free prose is what makes a reachable advisory + // (e.g. an unbounded form parse) silently vanish on a noisier run: one run + // writes "HIGH reachability, routing.py:443 → multipart DoS" and the finding + // lands; another writes "starlette is a heavily-used dependency" and it is + // dropped. Pinning the structure removes that variance from the promote step. + const names = hits.map((h) => `\`${h.name}\``).join(", "); return [ OSV_CONTEXT_HEADING, "", - 'These dependencies have published advisories (id followed by what the advisory is about). Rows marked "resolved range version" come from resolving a version range and may not be the installed version — treat them as applicable-if-resolved, not confirmed-present. In the Threat model and Project-specific patterns to flag sections, note where this codebase actually imports or calls each one, so the review can judge whether the advisory is reachable here rather than merely present.', + 'These dependencies have published advisories (id followed by what the advisory is about). Rows marked "resolved range version" come from resolving a version range and may not be the installed version — treat them as applicable-if-resolved, not confirmed-present.', "", ...blocks, + "", + "### Dependency reachability (required)", + "", + `In the Threat model section, emit a \`Dependency reachability\` subsection with exactly one line for EVERY dependency above (${names}) — do not omit any, do not merge them into prose. Use this fixed format per line:`, + "", + '`- @ — reachability — — `', + "", + "Grade reachability by whether this codebase actually reaches the vulnerable code path: HIGH when it imports and calls the affected API on an attacker-reachable path (name the `file:line`), LOW when the package is only transitive or the affected API is never called here. A dependency graded HIGH with a reachable call site is a finding to promote (steer a matcher at that `file:line`), not merely context; LOW ones stay recorded here. Keep this verdict for every dependency even across refreshes.", ].join("\n"); } diff --git a/packages/processor/src/prompt/core.ts b/packages/processor/src/prompt/core.ts index acf9f627..067ad8c3 100644 --- a/packages/processor/src/prompt/core.ts +++ b/packages/processor/src/prompt/core.ts @@ -69,6 +69,14 @@ Before classifying an issue, check for mitigations: If fully mitigated, do NOT flag it. Report only genuine, exploitable vulnerabilities. +## Known-vulnerable dependencies + +When project context (INFO.md) includes a **Dependency reachability** section, treat its graded verdicts as promotion guidance for dependency-advisory candidates: + +- **HIGH reachability** with a named call site (\`file:line\`): the vulnerable dependency code is reached from this codebase. Promote it to a finding at that site — do NOT dismiss it as "just a library default" or "the application's responsibility." The advisory's own severity carries into the finding. A HIGH verdict means reachability is already established upstream; your job is to confirm the call site and write it up, not to re-litigate whether a reachable advisory is worth reporting. +- **MEDIUM reachability**: judge it on its merits like any other candidate. +- **LOW reachability**: the affected API is not called, or the package is only transitive. Keep it as context; do NOT raise a standalone finding on the basis of a LOW grade. The one exception: if you find a concrete reachable call site (\`file:line\`) that the grading missed, treat it as reachable and promote — a LOW grade is a starting assumption, not a reason to ignore evidence. + ## Auth Bypass Patterns to Look For Beyond missing auth, look for **subtle bypasses** in code that appears to have auth: diff --git a/prompt-samples/01-empty-project.md b/prompt-samples/01-empty-project.md index a4ac2be9..d4a5ae6e 100644 --- a/prompt-samples/01-empty-project.md +++ b/prompt-samples/01-empty-project.md @@ -71,6 +71,14 @@ Before classifying an issue, check for mitigations: If fully mitigated, do NOT flag it. Report only genuine, exploitable vulnerabilities. +## Known-vulnerable dependencies + +When project context (INFO.md) includes a **Dependency reachability** section, treat its graded verdicts as promotion guidance for dependency-advisory candidates: + +- **HIGH reachability** with a named call site (`file:line`): the vulnerable dependency code is reached from this codebase. Promote it to a finding at that site — do NOT dismiss it as "just a library default" or "the application's responsibility." The advisory's own severity carries into the finding. A HIGH verdict means reachability is already established upstream; your job is to confirm the call site and write it up, not to re-litigate whether a reachable advisory is worth reporting. +- **MEDIUM reachability**: judge it on its merits like any other candidate. +- **LOW reachability**: the affected API is not called, or the package is only transitive. Keep it as context; do NOT raise a standalone finding on the basis of a LOW grade. The one exception: if you find a concrete reachable call site (`file:line`) that the grading missed, treat it as reachable and promote — a LOW grade is a starting assumption, not a reason to ignore evidence. + ## Auth Bypass Patterns to Look For Beyond missing auth, look for **subtle bypasses** in code that appears to have auth: diff --git a/prompt-samples/02-nextjs-tsx-batch.md b/prompt-samples/02-nextjs-tsx-batch.md index e3ea9432..3916a2c0 100644 --- a/prompt-samples/02-nextjs-tsx-batch.md +++ b/prompt-samples/02-nextjs-tsx-batch.md @@ -71,6 +71,14 @@ Before classifying an issue, check for mitigations: If fully mitigated, do NOT flag it. Report only genuine, exploitable vulnerabilities. +## Known-vulnerable dependencies + +When project context (INFO.md) includes a **Dependency reachability** section, treat its graded verdicts as promotion guidance for dependency-advisory candidates: + +- **HIGH reachability** with a named call site (`file:line`): the vulnerable dependency code is reached from this codebase. Promote it to a finding at that site — do NOT dismiss it as "just a library default" or "the application's responsibility." The advisory's own severity carries into the finding. A HIGH verdict means reachability is already established upstream; your job is to confirm the call site and write it up, not to re-litigate whether a reachable advisory is worth reporting. +- **MEDIUM reachability**: judge it on its merits like any other candidate. +- **LOW reachability**: the affected API is not called, or the package is only transitive. Keep it as context; do NOT raise a standalone finding on the basis of a LOW grade. The one exception: if you find a concrete reachable call site (`file:line`) that the grading missed, treat it as reachable and promote — a LOW grade is a starting assumption, not a reason to ignore evidence. + ## Auth Bypass Patterns to Look For Beyond missing auth, look for **subtle bypasses** in code that appears to have auth: diff --git a/prompt-samples/03-django-py-batch.md b/prompt-samples/03-django-py-batch.md index 1da66a02..e2965095 100644 --- a/prompt-samples/03-django-py-batch.md +++ b/prompt-samples/03-django-py-batch.md @@ -71,6 +71,14 @@ Before classifying an issue, check for mitigations: If fully mitigated, do NOT flag it. Report only genuine, exploitable vulnerabilities. +## Known-vulnerable dependencies + +When project context (INFO.md) includes a **Dependency reachability** section, treat its graded verdicts as promotion guidance for dependency-advisory candidates: + +- **HIGH reachability** with a named call site (`file:line`): the vulnerable dependency code is reached from this codebase. Promote it to a finding at that site — do NOT dismiss it as "just a library default" or "the application's responsibility." The advisory's own severity carries into the finding. A HIGH verdict means reachability is already established upstream; your job is to confirm the call site and write it up, not to re-litigate whether a reachable advisory is worth reporting. +- **MEDIUM reachability**: judge it on its merits like any other candidate. +- **LOW reachability**: the affected API is not called, or the package is only transitive. Keep it as context; do NOT raise a standalone finding on the basis of a LOW grade. The one exception: if you find a concrete reachable call site (`file:line`) that the grading missed, treat it as reachable and promote — a LOW grade is a starting assumption, not a reason to ignore evidence. + ## Auth Bypass Patterns to Look For Beyond missing auth, look for **subtle bypasses** in code that appears to have auth: diff --git a/prompt-samples/04-polyglot-python-batch-filters-other-techs.md b/prompt-samples/04-polyglot-python-batch-filters-other-techs.md index 955d1f30..1383e439 100644 --- a/prompt-samples/04-polyglot-python-batch-filters-other-techs.md +++ b/prompt-samples/04-polyglot-python-batch-filters-other-techs.md @@ -71,6 +71,14 @@ Before classifying an issue, check for mitigations: If fully mitigated, do NOT flag it. Report only genuine, exploitable vulnerabilities. +## Known-vulnerable dependencies + +When project context (INFO.md) includes a **Dependency reachability** section, treat its graded verdicts as promotion guidance for dependency-advisory candidates: + +- **HIGH reachability** with a named call site (`file:line`): the vulnerable dependency code is reached from this codebase. Promote it to a finding at that site — do NOT dismiss it as "just a library default" or "the application's responsibility." The advisory's own severity carries into the finding. A HIGH verdict means reachability is already established upstream; your job is to confirm the call site and write it up, not to re-litigate whether a reachable advisory is worth reporting. +- **MEDIUM reachability**: judge it on its merits like any other candidate. +- **LOW reachability**: the affected API is not called, or the package is only transitive. Keep it as context; do NOT raise a standalone finding on the basis of a LOW grade. The one exception: if you find a concrete reachable call site (`file:line`) that the grading missed, treat it as reachable and promote — a LOW grade is a starting assumption, not a reason to ignore evidence. + ## Auth Bypass Patterns to Look For Beyond missing auth, look for **subtle bypasses** in code that appears to have auth: diff --git a/prompt-samples/05-polyglot-typescript-batch-filters-other-techs.md b/prompt-samples/05-polyglot-typescript-batch-filters-other-techs.md index 1f2ac211..ceff70d3 100644 --- a/prompt-samples/05-polyglot-typescript-batch-filters-other-techs.md +++ b/prompt-samples/05-polyglot-typescript-batch-filters-other-techs.md @@ -71,6 +71,14 @@ Before classifying an issue, check for mitigations: If fully mitigated, do NOT flag it. Report only genuine, exploitable vulnerabilities. +## Known-vulnerable dependencies + +When project context (INFO.md) includes a **Dependency reachability** section, treat its graded verdicts as promotion guidance for dependency-advisory candidates: + +- **HIGH reachability** with a named call site (`file:line`): the vulnerable dependency code is reached from this codebase. Promote it to a finding at that site — do NOT dismiss it as "just a library default" or "the application's responsibility." The advisory's own severity carries into the finding. A HIGH verdict means reachability is already established upstream; your job is to confirm the call site and write it up, not to re-litigate whether a reachable advisory is worth reporting. +- **MEDIUM reachability**: judge it on its merits like any other candidate. +- **LOW reachability**: the affected API is not called, or the package is only transitive. Keep it as context; do NOT raise a standalone finding on the basis of a LOW grade. The one exception: if you find a concrete reachable call site (`file:line`) that the grading missed, treat it as reachable and promote — a LOW grade is a starting assumption, not a reason to ignore evidence. + ## Auth Bypass Patterns to Look For Beyond missing auth, look for **subtle bypasses** in code that appears to have auth: diff --git a/prompt-samples/06-polyglot-mixed-batch.md b/prompt-samples/06-polyglot-mixed-batch.md index 28802884..494c3fef 100644 --- a/prompt-samples/06-polyglot-mixed-batch.md +++ b/prompt-samples/06-polyglot-mixed-batch.md @@ -71,6 +71,14 @@ Before classifying an issue, check for mitigations: If fully mitigated, do NOT flag it. Report only genuine, exploitable vulnerabilities. +## Known-vulnerable dependencies + +When project context (INFO.md) includes a **Dependency reachability** section, treat its graded verdicts as promotion guidance for dependency-advisory candidates: + +- **HIGH reachability** with a named call site (`file:line`): the vulnerable dependency code is reached from this codebase. Promote it to a finding at that site — do NOT dismiss it as "just a library default" or "the application's responsibility." The advisory's own severity carries into the finding. A HIGH verdict means reachability is already established upstream; your job is to confirm the call site and write it up, not to re-litigate whether a reachable advisory is worth reporting. +- **MEDIUM reachability**: judge it on its merits like any other candidate. +- **LOW reachability**: the affected API is not called, or the package is only transitive. Keep it as context; do NOT raise a standalone finding on the basis of a LOW grade. The one exception: if you find a concrete reachable call site (`file:line`) that the grading missed, treat it as reachable and promote — a LOW grade is a starting assumption, not a reason to ignore evidence. + ## Auth Bypass Patterns to Look For Beyond missing auth, look for **subtle bypasses** in code that appears to have auth: diff --git a/prompt-samples/07-overflow-fallback.md b/prompt-samples/07-overflow-fallback.md index c42c3fc8..59cb368c 100644 --- a/prompt-samples/07-overflow-fallback.md +++ b/prompt-samples/07-overflow-fallback.md @@ -71,6 +71,14 @@ Before classifying an issue, check for mitigations: If fully mitigated, do NOT flag it. Report only genuine, exploitable vulnerabilities. +## Known-vulnerable dependencies + +When project context (INFO.md) includes a **Dependency reachability** section, treat its graded verdicts as promotion guidance for dependency-advisory candidates: + +- **HIGH reachability** with a named call site (`file:line`): the vulnerable dependency code is reached from this codebase. Promote it to a finding at that site — do NOT dismiss it as "just a library default" or "the application's responsibility." The advisory's own severity carries into the finding. A HIGH verdict means reachability is already established upstream; your job is to confirm the call site and write it up, not to re-litigate whether a reachable advisory is worth reporting. +- **MEDIUM reachability**: judge it on its merits like any other candidate. +- **LOW reachability**: the affected API is not called, or the package is only transitive. Keep it as context; do NOT raise a standalone finding on the basis of a LOW grade. The one exception: if you find a concrete reachable call site (`file:line`) that the grading missed, treat it as reachable and promote — a LOW grade is a starting assumption, not a reason to ignore evidence. + ## Auth Bypass Patterns to Look For Beyond missing auth, look for **subtle bypasses** in code that appears to have auth: diff --git a/prompt-samples/08-with-info-and-append.md b/prompt-samples/08-with-info-and-append.md index 30089e5b..9b4377d8 100644 --- a/prompt-samples/08-with-info-and-append.md +++ b/prompt-samples/08-with-info-and-append.md @@ -71,6 +71,14 @@ Before classifying an issue, check for mitigations: If fully mitigated, do NOT flag it. Report only genuine, exploitable vulnerabilities. +## Known-vulnerable dependencies + +When project context (INFO.md) includes a **Dependency reachability** section, treat its graded verdicts as promotion guidance for dependency-advisory candidates: + +- **HIGH reachability** with a named call site (`file:line`): the vulnerable dependency code is reached from this codebase. Promote it to a finding at that site — do NOT dismiss it as "just a library default" or "the application's responsibility." The advisory's own severity carries into the finding. A HIGH verdict means reachability is already established upstream; your job is to confirm the call site and write it up, not to re-litigate whether a reachable advisory is worth reporting. +- **MEDIUM reachability**: judge it on its merits like any other candidate. +- **LOW reachability**: the affected API is not called, or the package is only transitive. Keep it as context; do NOT raise a standalone finding on the basis of a LOW grade. The one exception: if you find a concrete reachable call site (`file:line`) that the grading missed, treat it as reachable and promote — a LOW grade is a starting assumption, not a reason to ignore evidence. + ## Auth Bypass Patterns to Look For Beyond missing auth, look for **subtle bypasses** in code that appears to have auth: diff --git a/prompt-samples/09-laravel-php-batch.md b/prompt-samples/09-laravel-php-batch.md index be2f8481..81adc822 100644 --- a/prompt-samples/09-laravel-php-batch.md +++ b/prompt-samples/09-laravel-php-batch.md @@ -71,6 +71,14 @@ Before classifying an issue, check for mitigations: If fully mitigated, do NOT flag it. Report only genuine, exploitable vulnerabilities. +## Known-vulnerable dependencies + +When project context (INFO.md) includes a **Dependency reachability** section, treat its graded verdicts as promotion guidance for dependency-advisory candidates: + +- **HIGH reachability** with a named call site (`file:line`): the vulnerable dependency code is reached from this codebase. Promote it to a finding at that site — do NOT dismiss it as "just a library default" or "the application's responsibility." The advisory's own severity carries into the finding. A HIGH verdict means reachability is already established upstream; your job is to confirm the call site and write it up, not to re-litigate whether a reachable advisory is worth reporting. +- **MEDIUM reachability**: judge it on its merits like any other candidate. +- **LOW reachability**: the affected API is not called, or the package is only transitive. Keep it as context; do NOT raise a standalone finding on the basis of a LOW grade. The one exception: if you find a concrete reachable call site (`file:line`) that the grading missed, treat it as reachable and promote — a LOW grade is a starting assumption, not a reason to ignore evidence. + ## Auth Bypass Patterns to Look For Beyond missing auth, look for **subtle bypasses** in code that appears to have auth: diff --git a/prompt-samples/10-rails-rb-batch.md b/prompt-samples/10-rails-rb-batch.md index a1f6bf4a..bcc97347 100644 --- a/prompt-samples/10-rails-rb-batch.md +++ b/prompt-samples/10-rails-rb-batch.md @@ -71,6 +71,14 @@ Before classifying an issue, check for mitigations: If fully mitigated, do NOT flag it. Report only genuine, exploitable vulnerabilities. +## Known-vulnerable dependencies + +When project context (INFO.md) includes a **Dependency reachability** section, treat its graded verdicts as promotion guidance for dependency-advisory candidates: + +- **HIGH reachability** with a named call site (`file:line`): the vulnerable dependency code is reached from this codebase. Promote it to a finding at that site — do NOT dismiss it as "just a library default" or "the application's responsibility." The advisory's own severity carries into the finding. A HIGH verdict means reachability is already established upstream; your job is to confirm the call site and write it up, not to re-litigate whether a reachable advisory is worth reporting. +- **MEDIUM reachability**: judge it on its merits like any other candidate. +- **LOW reachability**: the affected API is not called, or the package is only transitive. Keep it as context; do NOT raise a standalone finding on the basis of a LOW grade. The one exception: if you find a concrete reachable call site (`file:line`) that the grading missed, treat it as reachable and promote — a LOW grade is a starting assumption, not a reason to ignore evidence. + ## Auth Bypass Patterns to Look For Beyond missing auth, look for **subtle bypasses** in code that appears to have auth: diff --git a/prompt-samples/11-go-multi-framework-batch.md b/prompt-samples/11-go-multi-framework-batch.md index 3635e4e8..dceb06c1 100644 --- a/prompt-samples/11-go-multi-framework-batch.md +++ b/prompt-samples/11-go-multi-framework-batch.md @@ -71,6 +71,14 @@ Before classifying an issue, check for mitigations: If fully mitigated, do NOT flag it. Report only genuine, exploitable vulnerabilities. +## Known-vulnerable dependencies + +When project context (INFO.md) includes a **Dependency reachability** section, treat its graded verdicts as promotion guidance for dependency-advisory candidates: + +- **HIGH reachability** with a named call site (`file:line`): the vulnerable dependency code is reached from this codebase. Promote it to a finding at that site — do NOT dismiss it as "just a library default" or "the application's responsibility." The advisory's own severity carries into the finding. A HIGH verdict means reachability is already established upstream; your job is to confirm the call site and write it up, not to re-litigate whether a reachable advisory is worth reporting. +- **MEDIUM reachability**: judge it on its merits like any other candidate. +- **LOW reachability**: the affected API is not called, or the package is only transitive. Keep it as context; do NOT raise a standalone finding on the basis of a LOW grade. The one exception: if you find a concrete reachable call site (`file:line`) that the grading missed, treat it as reachable and promote — a LOW grade is a starting assumption, not a reason to ignore evidence. + ## Auth Bypass Patterns to Look For Beyond missing auth, look for **subtle bypasses** in code that appears to have auth: