Vulnerability Triage

TL;DR checklist

• Dedupe scanner reports to the actual fix point.
• Check runtime reachability, exploitability, and exposure.
• Record fix, defer, or suppression with evidence and owner.

Key read-only checks

• Read scanner output, package/image version, reachable code path, and exploit context.

Common pitfalls

• Do not treat scanner severity alone as the remediation order.

Agent procedure

Follow the Workflow, Safety rules, and Quality checklist below.

Quick references

• Workflow below.

Last verified: unverified

When to use

Use when scanner output (trivy/grype/govulncheck/gosec/checkov/CodeQL/Dependabot or similar) needs decisions: prioritize, dedupe, fix, defer, or suppress. This is the process skill that stops scanners from becoming ignored noise.

Goal

Turn raw findings into a short, ranked list of real actions — with every suppression justified and expiring, and nothing critical hiding in a wall of duplicates.

Workflow

1. Dedupe first — the same CVE reported by 3 scanners across 5 images is one decision, not 15 findings. Group by (vulnerability, root component); the fix point is usually one base image bump or one dependency line.
2. Reachability beats severity — a Critical in a library function the code never calls is below a Medium in the request path. Use reachability evidence where the ecosystem provides it (govulncheck call-graph analysis for Go is the model — it reports only vulnerabilities whose functions the code actually reaches); elsewhere approximate: is the vulnerable component loaded at runtime, or a build-time/test dependency?

3. Prioritize on three axes — exploitability (is it in CISA KEV? high EPSS? public PoC?), exposure (internet-facing request path vs internal batch job), fix availability:

   Situation	Action
   Exploitable (KEV/PoC) + exposed + fix exists	Fix now, out of band
   Exploitable + exposed, no fix	Compensating control now (WAF rule, network policy, feature flag off) + track upstream
   Fix exists, not exposed / not reachable	Normal backlog, batch with next dependency-update PR
   No fix, not reachable	Accepted risk — documented, with re-check date
   Scanner wrong (version misdetect, vendored patch)	False positive — suppress with evidence

4. Fix at the root — prefer one base-image bump or one go get -u <module> over N per-image suppressions; check whether the fix is already waiting in an open Renovate/ Dependabot PR before creating work.
5. Suppress with discipline — every suppression (.trivyignore, //nolint:gosec, #checkov:skip, VEX statement) carries: reason, evidence, owner, expiry. Suppression without expiry is silent permanent risk acceptance:

   # CVE-2026-12345 accepted until 2026-09-01 (owner: abevz)
   # reason: vulnerable function not reachable (govulncheck clean); vendor fix in v2.4

6. One backlog — findings that survive triage land where work actually happens (issues/ Jira/Dependency-Track), not in per-scanner dashboards nobody owns. If the same finding gets re-triaged every sprint, the process — not the scanner — is broken.
7. Close the loop — after fixing: re-scan to confirm, and check the expiring-suppressions list for anything past due while you're there.

Safety rules

• Never blanket-suppress by severity ("ignore all Mediums") or by file glob — suppressions are per-finding with individual justification.
• Do not mark something false-positive without evidence (version check, reachability output, vendored-patch commit) — "probably fine" is a deferral, not a false positive.
• Accepted risk requires naming who accepted it and when it's re-evaluated — the agent proposes, a human accepts.
• Do not auto-upgrade dependencies as part of triage — propose the upgrade; testing and merging it is a separate, reviewed change.

Output format

## Fix now (exploitable + exposed + fixable)
- <CVE/finding> — <root fix, one action even if N findings collapse into it>

## Compensating controls needed (no fix available)
## Backlog (batch into next update cycle)
## Accepted risk (proposed — needs human sign-off, with re-check date)
## False positives (with evidence)
## Suppressions past expiry

Quality checklist

• Findings were deduped to root components before ranking
• Reachability/exposure considered, not raw CVSS alone
• Every suppression proposed has reason, evidence, owner, expiry
• Root-cause fixes preferred over per-instance suppressions
• Accepted-risk items are flagged for human sign-off, not silently accepted