What companies patch, and what they don’t

Vulnerability scanners find far more issues than any team can fix. Whatever is still open in the scanner today is, by definition, what’s left after deciding what to fix first, what to live with, and what to monitor. By comparing what’s left to the full list of all published CVEs, we can work out what customers actually focus on.

The vulnerability management lifecycle

A vulnerability is a flaw in code, configuration, or a default setting that lets an attacker do something the designer didn’t intend. Each is assigned a CVE identifier, given a severity (CVSS) score, and tracked by every vulnerability scanner.

What follows is a four-step cycle. A scanner finds the issues. A risk model ranks them. A patch or configuration change clears them. A re-scan confirms the fix. The cycle repeats indefinitely, because new vulnerabilities arrive faster than old ones get fixed. The question is not whether to keep up, but which issues to fix first.

What gets patched: the prioritization gap

If customers patched without any priorities, tackling issues in random order, their backlog would match the severity breakdown of all CVEs. But it doesn’t. The chart below compares the unpatched backlog across several dozen customer environments (red) against the severity mix of all published CVEs (grey).

What’s hard to patch

Three patterns explain most of the unpatched backlog.

1. Configuration outweighs code. The most common finding across the customer base isn’t a software bug. It’s an untrusted TLS/SSL server certificate. The rest of the top ten is similar: weak cipher suites, static-key ciphers, self-signed certificates, SMB signing not required, TLS 1.0 still enabled, the BEAST attack still possible, default SNMP community names. None of these need a vendor patch. They need someone to revisit long-forgotten settings on long-running services, and that operator action is the real bottleneck.

2. Operating system vs applications. Microsoft-tagged issues (Windows OS patches, Office, Edge) dominate the customer footprint, reflecting both endpoint counts and the volume of Microsoft’s monthly release cadence. Linux is essentially absent from the backlog, which has two equally honest explanations: many Linux servers auto-update via the package manager, and the customer base is simply Windows-heavy. Browser apps (Chrome, Edge) and the occasional Adobe Acrobat / Java install are the next-biggest category.

3. Old CVEs age out, with exceptions. The second chart traces every unpatched CVE by the year it was first published, as a share of the backlog (red) versus its share of the whole NVD universe (grey).

What “good” looks like

A healthy vulnerability-management programme is built on habits more than on tooling:

• Prioritize by exploitability, not by score alone. Use CVSS to bound severity, EPSS to estimate the chance of near-term exploitation, and the CISA KEV catalogue as the deciding signal. A CVE that ranks in all three is the most urgent fix. Everything else can wait.
• Treat configuration hygiene as an ongoing programme, not a one-off project. The issues that stay open longest are default credentials, weak ciphers, and stale certificates — not vendor-patch gaps. They need their own scheduled review.
• Measure how fast you fix issues, not the total count. It rarely improves anyway, because new CVEs always arrive. What can improve is how fast you clear the issues that matter.
• Outsource what can’t be staffed for. Managed Detection and Response (MDR) providers monitor scanner output continuously and correlate it with live attacker activity, a feedback loop most in-house teams can’t sustain alongside their day job.

Charts based on an aggregated snapshot of a few dozen customer environments, compared to all published CVEs at the time of writing. Specific counts and customer identities are intentionally left out.