Vulnerability prioritization beyond the raw CVSS score: what 'exploitability' should actually mean

CVSS gives every vulnerability a number from 0 to 10, and it is tempting to treat that number as a priority queue — patch the 9.8s before the 6.4s, done. The problem is that CVSS base score measures something narrower than what most people assume: it's a structural assessment of a vulnerability's theoretical severity — how it could be exploited, what access it could grant, how much user interaction it requires — computed largely independent of whether anyone is actually exploiting it in the wild, whether the affected system is internet-facing, or whether the vulnerable component is even reachable in your actual environment.

A 9.8 in a library that's imported but never called with attacker-influenced input is a lower real-world priority than a 6.5 in an internet-facing service being actively exploited this week. The base score alone can't distinguish those cases, because it wasn't designed to — CVSS has a temporal and environmental extension that accounts for exploit maturity and environment-specific factors, but most tooling and most reports surface only the base score, because it's the one number that requires no per-environment context to compute.

What a more honest prioritization model weighs

• Known exploitation — is there evidence of this vulnerability being actively used in attacks right now, versus a theoretical proof-of-concept that's never been weaponized.
• Exposure — is the vulnerable service or component actually reachable from an untrusted network, or is it sitting behind layers that would need their own compromise first.
• Asset criticality — a vulnerability on a domain controller and the identical vulnerability on a rarely-used workstation are not the same priority, even with an identical CVSS score.
• Compensating controls already in place — network segmentation, application allowlisting, or existing monitoring can meaningfully lower real-world risk without the underlying CVE number changing at all.

None of this means CVSS is useless — it's a consistent, vendor-neutral starting point, and consistency across a fleet of hundreds of devices matters. The mistake is treating it as a finished prioritization instead of an input to one. A patch queue ordered purely by base score will often have an MSP burning a Saturday on a theoretical 9.8 with no path to exploitation while a 7.1 with a public working exploit sits two weeks out.

Where this stands for Nexus specifically: patch deployment with staged ring rollout is live end-to-end in our own practice today — the mechanism for actually getting a fix out the door once it's prioritized is real and dogfooded. Prioritization logic that layers exploitation evidence and exposure context on top of raw CVSS, rather than surfacing the base score as the only signal, is the design direction the vulnerability-management side of the platform is moving toward, not a finished claim. If you're evaluating any vendor's 'prioritization' feature, including ours as it matures, ask them to show you one vulnerability where their system ranked something below its CVSS score because of exposure or exploit context — if they can't produce a concrete example, the prioritization is probably just CVSS with a coat of paint.