You do not need to patch everything. You need to patch the things adversaries are exploiting this week, on the assets that matter, before the dwell time window closes. Most vulnerability management programs fail because they try to patch everything, measure themselves by scanner output, and wonder why breach reports still name CVEs from 2021.

The scanner is not the program

Tenable, Qualys, and Rapid7 all produce impressive PDFs. None of them are a vulnerability management program. A program is a decision-making pipeline: what is in scope, what is exploitable, what is exposed, who patches it, and how we know it is closed. The scanner feeds that pipeline. It is not the pipeline.

If your VM metric is "total critical vulnerabilities," you are measuring your scanner's sensitivity, not your risk. Nobody on the attacker side cares how many criticals you have. They care which one they can reach.

Prioritize by exploitation, not CVSS

CVSS tells you how bad the bug could theoretically be. It does not tell you whether anyone is using it. The CISA KEV catalog does — it is a curated list of vulnerabilities under active exploitation. Combined with EPSS probability scores, it is the closest thing we have to an honest prioritization signal.

A workable model:

  • KEV-listed, internet-exposed: patch within 7 days, no exceptions, wake people up if needed. MOVEit CVE-2023-34362 went from disclosure to mass exploitation in days.
  • KEV-listed, internal: patch within 30 days, risk-accept only with a compensating control and an expiration date.
  • High EPSS (>10%), not yet KEV: same quarter, prioritized.
  • Everything else: standard cadence by asset tier. Some of it will never get patched, and that is fine if you said so deliberately.

Asset inventory is the precondition

You cannot prioritize what you cannot see. I have watched organizations patch 10,000 Windows endpoints flawlessly while a forgotten Apache Struts server on a subsidiary's DMZ ran Log4Shell for 18 months. The scanner never had credentials for it. The CMDB never had a record of it.

An honest inventory combines authenticated scanning, EDR telemetry, cloud provider APIs, and — critically — network-based discovery to find the things that do not appear in any of the first three. The gap between "assets in the CMDB" and "assets that exist" is where breaches happen.

Accept or remediate — but decide

Risk acceptance is a legitimate tool. Indefinite risk acceptance is not. Every accepted vulnerability needs an owner, a compensating control, and an expiration date. "We cannot patch this legacy app" is not acceptance, it is deferral. Write down what would have to change for it to be remediated, and when you will reassess.

Mean-time-to-remediate across all findings is a vanity metric. Mean-time-to-remediate for KEV on internet-facing assets is a survival metric. Measure the one that matters.

Close the loop with change and detection

The patch is not done when the ticket closes. It is done when the scanner confirms the version, the change ticket references the CVE, and — for anything KEV — you have a detection for post-exploitation activity in case the patch missed something. Log4j taught us that patching the obvious instance is not the same as eradicating it; some organizations were still finding vulnerable JARs a year later.

The takeaway

Pull your last 30 days of vulnerability findings. Filter to KEV, internet-facing. How many are open? How old is the oldest? Who owns them? If you cannot answer those three questions in under five minutes, your program is a CSV dump, not a program. Fix that pipeline before you buy another scanner.