Vulnerability management

The loop, not the scan

The single most common failure in vulnerability management isn’t a missed CVE — it’s treating a scan as the deliverable. A scan is the start of work, not the end of it. NIST SP 800-40r4 frames the whole thing as enterprise patch and vulnerability management, an ongoing process with explicit phases, precisely because a one-shot report rots the moment new CVEs land and new hosts spin up. The state of the world changes daily; a quarterly PDF is stale before the meeting ends.

The loop has four moving parts, and the value lives in the connections between them:

• Discover — know what you have and what’s wrong with it. Asset inventory first (you cannot patch a host you forgot exists), then authenticated scans, agent telemetry, SBOM-driven dependency checks, and external surface discovery.
• Prioritize — turn a flood of findings into a ranked queue using exploitability and exposure, not raw severity.
• Remediate — patch, configure, isolate, or compensate — with a clock attached (the SLA).
• Verify — re-scan and confirm the finding is actually gone, then feed the result back to discovery.

Skip verification and you don’t have a loop — you have an open-ended list where “we patched it” and “it’s fixed” are two different claims you never reconcile. The day an auditor asks “show me this CVE is closed across all 200 hosts,” the team that verified can answer in minutes; the team that just deployed a patch is now scanning under pressure.

Prioritize by exploitability and exposure, not raw CVSS

Here is the number that reorganizes how a senior thinks about this: of all CVEs published in a given year, only a small fraction — studies and CISA’s KEV data put it well under 5% — are ever exploited in the wild. Yet a naive program treats every CVSS 9.8 as equally on fire. That’s how you burn a sprint patching a critical-rated RCE in a library that’s compiled in but never reachable, while a “medium” misconfiguration on your internet-facing login sits open.

CVSS gives you a base severity — a vendor-neutral 0–10 score of how bad the flaw is if exploited. It is genuinely useful, and FIRST (who steward the spec) are explicit that the base score is severity, not risk. To get to risk you layer two things CVSS base alone doesn’t capture:

• Exploitability — is there a working exploit, and is it being used? CVSS v3.1’s temporal metrics and v4.0’s threat metrics encode this, but the sharpest signal is CISA’s Known Exploited Vulnerabilities (KEV) catalog and EPSS (a probability that a CVE will be exploited in the next 30 days). A CVE in KEV jumps to the front of the queue almost regardless of its base score.
• Exposure — is the affected thing actually reachable and running in your environment? Internet-facing beats internal; a loaded, listening service beats dormant code; a host with sensitive data beats a throwaway box. This is your context, and no external feed has it.

The senior reflex: rank = severity × exploitability × exposure, applied in that order as filters. Start from the KEV-and-exposed intersection, and the 311 criticals collapse to a queue you can actually clear.

The two CVSS-9.8 rows are the whole lesson: identical base scores, opposite priorities, because exploitability and exposure pull them apart. Rank by base score alone and you’d work them in a coin-flip order; rank by the full picture and the queue is obvious.

SLAs: the clock that makes “later” accountable

A priority with no deadline is a suggestion. The remediation SLA is the commitment that a finding of a given severity gets closed within a fixed window — and it exists to stop the slow leak where “we’ll get to it” quietly becomes “it’s been open 400 days.” Typical tiers look like: critical / actively exploited → 7–15 days, high → 30 days, medium → 90 days, low → next planned cycle. (CISA’s binding directives for federal agencies use exactly this shape — KEV entries on tight, fixed deadlines — and it’s a sane default to port into a private SLA.)

The number itself is a tradeoff, not a law of physics. Patch too fast and you risk shipping a broken update to production with no testing window; patch too slow and you leave the exploit window open. The senior move is to make the SLA severity-tiered and exception-tracked: most findings ride the standard clock, and anything that can’t make its deadline gets an explicit, owned, time-boxed exception with a compensating control — never a silent slip. An SLA you breach constantly and never measure is worse than none, because it manufactures false assurance.

Verify, then close the loop

“Patched” is a deploy event. “Fixed” is an observed state. The gap between them is where programs quietly fail: a patch that didn’t apply to 12 of 200 hosts, a config change reverted by the next deploy, a container image rebuilt from a still-vulnerable base. Verification re-scans the affected assets and confirms the finding is actually gone — and only then does the ticket close. The verification result flows back into discovery, which is what makes this a loop rather than a list: the same scan that confirms today’s fix surfaces tomorrow’s new finding.

This feedback is also how you measure the program itself. The metrics that matter aren’t “how many CVEs do we have” — that number is unbounded and demoralizing. They’re mean time to remediate (MTTR) by severity, percentage of findings closed within SLA, and recurrence rate (findings that come back because the fix didn’t stick). A program reporting those can answer “are we getting safer?” with evidence; one reporting raw counts can only answer “is the scanner still running?”