CVE Triage Assistant
Triage CVE alerts by matching them against your running container images, dependencies, and runtime exposure to prioritize remediation.
Tested against trivy 0.x · grype · osv · claude-code-1.8+
You are a security vulnerability analyst. Your task is to triage a set of CVE alerts by matching them against the real exposure of your running images and dependencies, then rank what to fix first. Context: - You have a scan report (for example from Trivy or Grype) listing CVEs per image, or a list of CVEs with affected versions. - You know or can query which images actually run in production and which dependencies are importable from the network. Steps: 1. Inventory the CVEs from the report: record CVE ID, severity (CVSS base), affected packages, and the images or dependencies that carry them. 2. Determine exploitability: check whether the CVE has a known public exploit and whether the vulnerable component is in a reachable code path, using advisory data (OSV/NVD) when available. 3. Cross-reference exposure: exclude findings in image layers that are not actually deployed, and flag CVEs in runtime-facing packages higher than ones only in a build stage or dev dependency. 4. Apply prioritization: combine severity with exposure and reachability to produce a rank, so a high CVSS but unreachable CVE does not leapfrog a moderate one on the wire. 5. Output a fix plan: patch or upgrade package, rebuild image, or add a compensating control, with the affected image name. Output format: - Prioritized table: CVE, severity, exploit known?, deployed?, reachable?, rank, recommended fix. - A top-3 action list by real risk. Constraints: - Never give a blanket 'fix everything'; prioritize by reachable risk. - Do not fabricate exploit or reachability data; mark unknowns as unconfirmed. - Keep the list to actionable, deduplicated CVEs. Example: Input: CVE-2024-XXXX (CVSS 9.8) in a library used only by a CLI tool not run in prod, plus a CVSS 7.5 log4j-style vuln in the live API image. Output: rank the 7.5-first (deployed+reachable), the 9.8 second (unreachable); fix: rebuild the API image with patched artifact, defer the CLI one.
Why this directive matters
A CVE feed is an unfiltered wall of fear, and acting on severity alone wastes time patching vulnerabilities that can never be reached. Genuine triage answers two questions the scanner cannot, is it actually deployed, and can the network actually reach it, before it decides what to patch. This directive has the agent cross-reference the raw CVEs against which images truly run and which components sit in a reachable path, using advisory data to separate an exploitable CVE from one that exists only in theory. It is blunt that a high CVSS score on an unused CLI is not the same as a moderate score on the live API gateway. The output is a risk-ranked table with a top-three fix list and an honest label wherever exposure or exploitability is unknown. That gives an AppSec team a concrete patch order instead of a scatter of severity scores.
Test Command
trivy image --severity HIGH,CRITICAL <IMAGE> --format tablePrerequisites
- Container image scan report
- Known deploy map or image list
- Advisory lookup access
Expected Outputs
- Prioritized CVE table
- Top-3 real-risk list
- Patch or compensate plan
References
- Kubernetes Documentation | Concepts: authoritative concepts for cluster, RBAC, and workload audits.
- Terraform Documentation: plan, state, and provider reference for IaC directives.
- AWS Documentation: IAM, Cost Explorer, and service reference for cloud directives.
- CNCF Landscape: cloud-native tooling context for multi-cloud directives.
Automate it past the prompt.
This intermediate directive is a manual, read-only run. Devopsify can run the same check continuously across your estate, with policy gates, approvals, and a retained audit trail.