Dep Triage

Dependency Triage

Overview

Reads upstream scan findings, evaluates each in the repo's actual usage context, and emits the same findings augmented with triage_outcome (confirmed | false_positive) and a one-sentence triage_reason.

This is the triage step — does not run scanners itself. Always downstream of /dep-scan (or another scan agent emitting the same finding shape: cve, package, installed_version, fixed_version).

When to use

• After /dep-scan in a chained agent (needs: [scan-deps]).
• Whenever raw scanner output needs filtering before human review.
• Periodically (e.g., scheduled re-triage to update prior-run outcomes as the codebase evolves).

Required tools

• Read, Grep, Glob — to inspect repo source for package usage
• Bash(git diff:*) — to scope which dependencies the PR touched
• Skill — invocation only
• Write — auto-granted; for stage-output.json

Inputs

• upstream/scan-deps/stage-output.json — scan findings from the upstream scan-deps agent (or compatible scanner)

Triage rubric

For each finding under payload.findings[]:

Confirmed (triage_outcome: confirmed)

Mark confirmed if all three hold:

1. The package is imported by repo source under apps/, libs/, or packages/.
2. The vulnerable code path is plausibly reachable from a request, user input, or build output.
3. The package is NOT exclusively a dev-time dependency.

False positive (triage_outcome: false_positive)

Mark FP if any one of these holds:

1. Not a runtime dep. Listed only under devDependencies / peerDependencies and not exposed at build/runtime (test fixtures, type generators, bundler internals).
2. Vulnerable function unused. The specific CVE-affected function/API is not called anywhere in apps/, libs/, or packages/.
3. Network/host context excludes risk. E.g., DoS vuln on internal service the project doesn't expose; SSRF on URL the project never constructs; XSS in a sanitizer the project doesn't reach.
4. Already mitigated transitively. Repo's package overrides / resolutions pin a safe version.
5. Out-of-scope target. Scanner flagged a vendored binary, build artifact, or test fixture not part of the deployed application.

Conservative tie-break

If you can't establish FP via one of the rules above, mark confirmed. Better one extra reviewer click than missing a real CVE. Capture uncertainty in triage_reason so the reviewer can re-evaluate quickly.

Process

1. Read upstream output. upstream/scan-deps/stage-output.json — parse payload.findings[].

2. For each finding, follow the rubric:

   • Use Grep to find imports of package in apps/, libs/, packages/.
   • If imports exist, Read the importing files to check whether the vulnerable API is actually used.
   • Inspect package.json files to determine dependencies vs devDependencies (path matters — root package.json vs workspace package.jsons differ in semantics).
   • Consider transitive resolutions: check pnpm-lock.yaml / package-lock.json for pinned-safe versions.

3. Augment each finding with two new fields:

   • triage_outcome: "confirmed" or "false_positive"
   • triage_reason: one short sentence explaining the call. Reference the rule number (1-5) for FPs.

4. Recompute summary. Update the top-level summary field to reflect post-triage counts: "trivy: <N> raw → <C> confirmed, <F> false_positive".