Vulnerability Management
A raw scanner report is a list of theoretical problems, not a work plan. Every base image pulls in hundreds of CVEs, most in code paths nobody calls, in packages exposed to nothing, behind network boundaries that block the exploit. Treating every CVE as equally urgent trains the team to ignore the report entirely, which is worse than not scanning at all.
The job is triage, not enumeration. A finding earns attention by being both exploitable and reachable — not by having a high CVSS score in isolation.
A vulnerability nobody can reach is a lower priority than a medium-severity one sitting on your public ingress.
1. Scan everywhere, but don't treat every scan the same
Code, dependencies, container images, IaC, and running infrastructure each need coverage, and
each surfaces different risk. A dependency CVE in a library you don't call is different from a
misconfigured security group actively exposing a database. Route each scan type to its own
queue with its own triage rules instead of one undifferentiated backlog. The scanning tools
themselves — SAST, dependency, image — belong to security-scanning; this skill is about what
happens to what they find.
Done when: every asset class (code, deps, images, infra) has an owner for its findings queue.
2. Prioritize by exploitability and reachability, not raw CVSS
CVSS measures theoretical severity assuming the vulnerable code path is reachable and unmitigated — it says nothing about your actual deployment. A critical CVE in a function your code never calls is lower priority than a medium CVE in your internet-facing auth path.
| Signal | Raises priority | Lowers priority |
|---|---|---|
| Reachability | Vulnerable function is on a call path from user input | Package installed but code path unused |
| Exposure | Internet-facing, no auth | Internal-only, behind mTLS |
| Known exploitation | Actively exploited in the wild (KEV-listed) | No known public exploit |
| Compensating control | None | WAF rule or network policy already blocks the vector |
Use reachability analysis or SCA tooling that traces call graphs where available — it turns a 400-CVE report into a 12-item list.
Done when: the top of the remediation queue is sorted by exploitability and exposure, not by CVSS number alone.
3. Set patch SLAs by severity tier, and hold to them
An SLA without enforcement is a suggestion. Tie tiers to the triage from step 2, not to raw scanner severity, so the SLA clock only starts once something is actually confirmed exploitable and reachable. Track SLA breaches visibly — a dashboard the team ignores is not a control, it's decoration.
- Critical + actively exploited: patch or mitigate within a day, page if missed.
- High + reachable: patch within the sprint.
- Everything else: batch into normal dependency-update cadence.
Done when: every open finding has an SLA clock attached and a named owner.
4. Give the team a fix, not just a finding
"Upgrade log4j" is more actionable than "CVE-2021-44228 detected." Where possible, the report should include the target version, whether it's a drop-in upgrade or a breaking change, and a compensating control if the fix isn't immediate. Findings without a clear next action rot in the backlog and erode trust in the whole program.
Done when: a developer can act on a finding without first researching what the CVE means.
5. Suppress deliberately, not by ignoring
Some findings are accepted risk — no fix exists, the path is unreachable, a compensating control covers it. Suppress those explicitly with a reason and a review date, rather than letting them sit unacknowledged. An unreviewed suppression list is how a real exploitable finding hides in noise for a year.
- Time-box every suppression and revisit it, since "unreachable today" can become reachable after a refactor.
Done when: every suppressed finding has a documented reason and an expiry for re-review.
Report
State the current open-finding count by severity tier, the SLA for each tier, and how many are currently past SLA. Name the class of finding still triaged by raw CVSS alone rather than reachability — that's where the noise is still winning, and admitting it is more useful than a clean-looking dashboard.