Vulnerability management at scale: what actually matters

Most "VM programmes" I've inherited follow the same arc. Buy a scanner. Point it at everything. Open the dashboard. Watch a five-figure number of "critical" findings light up. Nobody fixes anything. The CISO asks for a percentage. The percentage doesn't move. Repeat for two years.

The fix isn't a better scanner — it's a process that turns scanner output into a small, owned, time-bound queue of work. That's the whole thing. Everything below is in service of that.

Asset truth comes first

Every VM programme dies on the rock of "is this asset still ours, and who owns it?". Before anything else:

• Pick a single source of truth for assets. Cloud accounts → tag policies. Kubernetes → namespace labels. Endpoints → MDM. Pick one per asset class and refuse all others.
• Every asset must have an owner tag pointing at a human or team that exists today, not the org chart from 18 months ago.
• Anything without an owner gets a 14-day grace period, then gets quarantined (network-isolated, scaled to zero, whatever your stack supports). Yes, things will break. That's the point — owners surface fast.

Stop ranking by CVSS

CVSS base score is calibration data, not a priority. It doesn't know whether the asset is internet-facing, whether you have the package, whether there's a public exploit, or whether your compensating control already kills the attack chain. Use it as one input, not as the answer.

The shortcut I use: EPSS × exposure × asset criticality.

• EPSS (Exploit Prediction Scoring System, by FIRST) — probability of exploitation in the wild within 30 days. Free, updated daily, calibrated against reality.
• Exposure — is this thing reachable from the internet, from another tenant, or only from a privileged admin path?
• Asset criticality — does this asset hold customer data / handle auth / run financial logic? A handful of tiers is enough.

Findings that score high on all three get same-week treatment. Anything CVSS-Critical but EPSS < 1% on an internal jump host? Backlog.

Risk-based SLAs that engineers can live with

Single-tier SLAs ("Critical = 14 days") are how you teach a team that the SLA is a fiction. Multi-tier with explicit exposure logic gives you a SLA that's both defensible and survivable.

Severity   Internet-facing   Internal     Air-gapped
Critical   72h               14 days      30 days
High       14 days           30 days      90 days
Medium     30 days           90 days      "best effort"
Low        triage queue, batched quarterly

This isn't perfect. It's defensible to an auditor and survivable for a 5-person platform team. That's the goal.

Deduplicate or drown

Three scanners pointed at the same Linux fleet will produce three findings per actual vulnerability. Triage time goes up 3×; trust in the data goes down. Pick a canonical key and merge upstream of the tracker:

• For OS packages: (asset_id, package_name, fixed_version) — not CVE. One package fix usually clears a CVE cluster.
• For containers: (image_digest, package, fixed_version) — never tag, always digest.
• For web/DAST: (host, finding_class, parameter) — same URL with different reflected XSS parameters is two findings, not one.

Get findings out of the security tool

Engineers don't open security dashboards. Push findings into where engineers already are:

• Jira / Linear / GitHub Issues, automatically created with the right project, label and owner.
• One issue per fix, not per finding — bundling the 17 CVEs that the same openssl upgrade kills into one ticket is the single biggest morale improvement you can ship.
• Renovate / Dependabot for OSS dep findings, so the fix is a PR not a ticket.

The weekly digest

Every Monday, send each owner team a short email/Slack message:

• How many findings opened, closed, breached SLA this week.
• The top 3 things to fix this week, by score, with a link to the bundled ticket.
• Trend line vs last month — boring, useful.

This is 80% of the visible value of a VM programme. The dashboard exists for the auditor; the digest is what drives the work.

Metrics that matter

Skip "vulnerability count". It's vanity. Track:

• MTTR by severity and exposure — going down means the programme works.
• % of internet-facing assets with no critical findings older than SLA — single number for the board.
• Coverage — % of known assets actively scanned. Anything not scanned is by definition zero findings, which is dangerous.
• Override / accepted-risk rate — high is a smell. Either your tiers are too aggressive or your asset criticality is wrong.

The job of a VM programme isn't to find vulnerabilities. It's to make sure the ones that matter actually get fixed before someone else finds them for you.

If you're staring at a five-figure scanner dashboard wondering where to start, that's normal — and exactly the kind of work I do. Say hello.