Skip to content
CloudOps
All prompts
AI for DevOps Security & Hardening Difficulty: Intermediate ClaudeChatGPT

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.
Newsletter

Get weekly AI workflows for DevOps engineers

Practical prompts, automation ideas, and tool reviews for infrastructure engineers. One email per week. No spam.