Why CVSS Alone Is Not a Vulnerability-Patching Strategy

Sorting a vulnerability list by CVSS score and working top to bottom feels rigorous. It is also one of the most common ways teams spend effort on the wrong things.

CVSS is useful. It just answers a different question than the one patching needs answered.

What CVSS measures

The CVSS base score describes the intrinsic characteristics of a vulnerability: attack vector, complexity, privileges required, user interaction, and impact on confidentiality, integrity, and availability. It is meant to be consistent across environments.

That consistency is the point, and the limitation. A base score does not know whether the vulnerable software is running, whether it is exposed, or whether anyone is exploiting it.

CVSS does include threat and environmental metrics for adjusting scores locally. In practice, most tools display the base score, and most teams never fill in the rest.

The problem with a sorted list

Picture two findings.

The first is a 9.8 in a library bundled with an internal build tool that runs on an isolated CI runner. The second is a 7.5 in a web server on an internet-facing production host, with public exploit code and reports of active exploitation.

A CVSS-sorted queue puts the first one ahead. Almost any experienced practitioner would fix the second one first.

Multiply that across thousands of findings and the queue becomes actively misleading. It also produces a large number of "critical" items, which teaches people to stop treating "critical" as urgent.

The factors that change priority

Exploitation

Evidence that a vulnerability is being exploited is one of the strongest signals available. CISA's KEV catalog lists vulnerabilities with confirmed exploitation. EPSS gives a probability estimate of exploitation activity in the near term. Neither is perfect, and both are far more predictive than severity alone.

Exposure

Can an attacker reach the vulnerable service? Internet-facing assets, partner-accessible endpoints, and services reachable from user workstations carry more risk than systems behind several layers of segmentation.

Asset criticality

What happens if this system is compromised? A domain controller, a payment service, or a CI system with deployment credentials matters more than a test VM. This information usually lives outside the scanner, which is why it so often gets ignored.

Reachability

For application dependencies, the vulnerable function may not be called at all. Some SCA tools can analyze whether code paths reach the affected component. Treat this as a strong hint, not a guarantee; static analysis misses dynamic behavior.

Compensating controls

A WAF rule, disabled feature, network restriction, or EDR detection can reduce risk while a patch is pending. Record these explicitly, with an owner and an expiry. "Mitigated" without a date tends to become "permanent."

Putting it together

You don't need a complex model to do better than CVSS alone. A small number of clear rules goes a long way:

• Known exploited and exposed: fix within days.
• Known exploited but internal: fix on an accelerated schedule.
• High severity, exposed, critical asset: prioritize.
• High severity, not reachable, isolated: schedule with normal maintenance.
• No fix available: apply and document mitigations.

Write the rules down. Make sure they produce a manageable number of urgent items. If everything is urgent, the rules need tightening.

Common objections

"Auditors want CVSS-based SLAs." Many frameworks allow risk-based approaches as long as they are documented and applied consistently. Keep CVSS as an input and show your reasoning.

"We don't have good asset data." That is true for most organizations. Start with what you have: internet-facing inventory and a short list of critical systems. Partial context still beats none.

"This is more work." Up front, yes. It usually reduces total work, because teams stop patching low-risk findings under emergency timelines.

The point

CVSS tells you how dangerous a vulnerability could be in a generic environment. Your patching strategy needs to reflect your environment. Use the score, then add exploitation, exposure, criticality, reachability, and controls. That is the difference between a sorted list and a plan.