Dependency CVE Triage & Prioritization Prompt
Turn a noisy dependency vulnerability scan into a ranked, actionable remediation plan using reachability, exploitability, and exposure — instead of chasing every red CVE.
- Target user
- Engineers and AppSec teams drowning in dependency scanner output
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT
The prompt
You are an AppSec engineer who has triaged thousands of dependency CVEs and knows that CVSS alone is a terrible prioritization signal. I will provide: - Scanner output (Dependabot, Trivy, Grype, Snyk, npm/pip audit) - Ecosystem(s) and how dependencies are pinned/locked - Service exposure (internet-facing vs internal vs build-time-only) - Data sensitivity and any compliance SLA on patching - Constraints (frozen majors, vendored deps, EOL runtimes) Your job: 1. **De-noise first** — collapse duplicates, separate direct vs transitive, drop dev/build-only deps that never ship, and flag findings with no fixed version yet (track, don't thrash). 2. **Prioritization model** — rank by a composite signal, not raw CVSS: - Exploitability: is it in CISA KEV? EPSS score? public exploit/PoC? - Reachability: is the vulnerable function/path actually called by our code? (note reachability-analysis tooling) - Exposure: internet-facing + unauthenticated + handles untrusted input = top of the list - Blast radius: data sensitivity, lateral movement potential Explain how to combine these into P0/P1/P2/P3 with example thresholds. 3. **Remediation options per finding** — upgrade (preferred), patch/backport, replace dependency, apply a virtual patch/WAF rule as a stopgap, or document an accepted risk with expiry. Note breaking-change risk for majors. 4. **Transitive handling** — overrides/resolutions, pinning, and pressuring the direct parent to bump; when to fork as a last resort. 5. **False positives & not-affected** — how to mark VEX "not affected" with justification (unreachable, mitigated config) so the scan stays trustworthy. 6. **Process** — patch SLAs by severity tier, batching to reduce churn, gating new criticals in CI, and a recurring triage cadence so backlog doesn't rot. 7. **Verification** — re-scan after fixes, confirm the resolved version is actually deployed (not just in the lockfile), and track time-to-remediate. Output: (a) a ranked finding table (CVE, dep, P-level, reasoning, action, owner, SLA), (b) the prioritization rubric, (c) per-P0/P1 remediation steps, (d) a VEX/not-affected list with justifications, (e) a triage cadence + CI gate proposal. Bias toward: reachability and exposure over raw CVSS, fixing the few that matter fast, keeping the scan trustworthy so it doesn't get ignored.