A 9.8 is not a 9.8 on your network
A new CVE drops with a 9.8 base score. Your engineer pulls up two assets that match: an internet-facing single sign-on gateway and a segmented internal print server. Both rows in the queue show the same advisory, the same vector string, the same big red number. Both will sit at the same severity until someone goes and looks. That number is lying about the risk on at least one of them. Two completely different decisions live in the same row of your spreadsheet, and CVSS will not tell you which is which, because it was never designed to.
We see this pattern every week in CTEM rollouts, and the fix is not a new metric. The fix is using the metrics we already have in the order they were designed to be used, then doing the one thing none of them was ever built to do.
Why the base score keeps misleading us
The CVSS specification itself is honest about its limits. The v4.0 document explicitly lists regulatory requirements, the number of customers impacted, monetary losses, and reputational impact as factors that fall outside the scope of CVSS. Base score describes the bug in the abstract, not your exposure to it. Anyone who has read the spec already knows this, and yet most queues still triage on base score first.
Two facts make the gap actively dangerous in practice. The CVSS v4 Environmental metrics, which were built specifically to let consumers re-score a CVE for their own deployment, are barely being published. VulnCheck found that only about 25.9% of the 43,002 CVEs published in 2025 carry a v4 score at all, and the historically dominant enrichment sources, NIST NVD and CISA ADP, almost never publish v4. The official answer to environment-specific scoring is functionally absent from the data your tools ingest.
Severity also fails to predict exploitation. Of the 159 CVEs known to be exploited in the wild in Q1 2025, about 28% carried only a Medium base score. Roughly 5% of all CVEs ever get exploited in the wild at all. The big number on the advisory and the actual probability of attack are weakly correlated, which is exactly why frameworks like EPSS, KEV, and SSVC exist.
The signals that already exist
Before claiming anything new, here is the honest map. Almost every input to a contextual re-score already lives in a named system that practitioners are not using together as a stack.
Exploit likelihood is a solved class. The EPSS model at FIRST gives a 30-day exploitation probability from internet-scale signals, with v4 sharpening that estimate further. CISA KEV confirms exploitation already happened. CVSS v4 itself carries a Threat metric for Exploit Maturity. The NIST CSWP 41 LEV metric, published in May 2025, estimates the probability a CVE was already exploited from historical EPSS trends. Four overlapping sources, all free, all keyed to the CVE you are looking at.
Exposure is formalized too. CERT/CC's SSVC standardizes a System Exposure decision point with three values: Small, Controlled, and Open. The documentation is explicit that exposure should be judged against the system in its deployed context, not how the vendor expects it to be deployed.
Compensating controls sit inside SSVC already. The Controlled value covers the case where access restrictions or mitigations are in place. CVSS v4 Environmental metrics encode the same idea through modified base values you re-vector for your environment.
Reachability ships in commercial tooling. Hopper Security reports that function-level reachability typically removes about 93% of dependency noise by filtering out vulnerabilities that no execution path actually reaches. Network reachability, runtime reachability with eBPF, and image-level checks all exist in modern SCA and CSPM products.
And environment-specific scoring already has a public proof point. Picus showed Log4Shell, a static CVSS 10.0, scoring 9.1, 7.3, and 5.2 across three customer systems depending on what compensating controls were validated against simulated exploit traffic. Same bug, three scores, evidence-backed.
If you are reading this list and thinking none of it is new, you are right. The scoring world has done careful work. What the standards bodies have not done is hand a practitioner who is looking at one CVE in front of them a way to combine these signals quickly and free, without a platform license.
What still isn't in any standard
Two gaps remain after honest credit to the prior art above. The first gap is integration. The signals are scattered across five-plus systems and produced by different organizations on different schedules. No single free, manual, ten-minute method walks a triager through stacking them on one CVE. The standards individually are excellent. The synthesis is on you.
The second gap is the business layer. CVSS explicitly excludes regulatory exposure, customer impact, and similar factors. SSVC acknowledges this through its stakeholder-specific framing, but the framework still leaves blast radius and business criticality as a judgment call. If the only signal saying "this asset processes regulated data and sits at the heart of your revenue path" lives in your CMDB and your engineer's head, the standards do not close the loop.
The contribution worth shipping is a practitioner checklist that stacks the existing signals fast, then forces an explicit judgment on the layer CVSS itself called out of scope. That is the whole point of the rest of this post.
The ten-minute context rubric
Five layered questions, applied to a single CVE on a single asset, in this order. None of them are new on their own. The discipline of running all five before triaging is.
1. Exploit pressure
Is the CVE in CISA KEV? What does EPSS say? If KEV is yes, treat exploit pressure as confirmed and move to step two. If KEV is no, an EPSS score above 0.088 is a useful working threshold, and an EPSS percentile above the 95th sits in the band where the FIRST research has shown that prioritization captures roughly 82% of exploitations while remediating only about 7.3% of the catalog. NIST LEV gives you the retrospective view as a second opinion when you have time.
2. Reachability
Three checks fold into one: is the vulnerable code path callable on this asset, is the affected port listening, and is the feature even enabled? Function-level reachability tools answer the first for application code. Configuration checks answer the other two at the operating system and runtime layer. If the bug is in a library you ship but the entry function is never called, this CVE is noise on this asset, and recording it as such is more useful than letting it eat triage time every patch cycle.
3. Exposure
Score the asset using SSVC's System Exposure values. Small is a local service on a tightly controlled network. Controlled is a networked service with access restrictions or mitigations already in place. Open is internet-facing or accessible to untrusted users. Use the deployed context, not the vendor's reference architecture, exactly as SSVC says.
4. Compensating controls
What is already standing in front of the vulnerable surface? Inventory the things that would actually break the attack chain on the way in: a WAF rule for this exact class, an EDR signature for the post-exploit behavior, network segmentation between the asset and an attacker, MFA in front of the vulnerable login path. Count only validated controls, never assumed ones, because assumed posture is exactly where the gap between scored risk and actual risk lives. The Picus PXS spread on Log4Shell (9.1, 7.3, 5.2) is that same point made with telemetry: control-validated scoring is where assumed posture and actual posture stop being the same number.
5. Blast radius and business criticality
What does this asset hold, and what does it touch? Regulated data, customer credentials, an identity provider that mediates access to fifty other systems. This is the layer CVSS calls out of scope, so you have to add it explicitly because nobody else will. A pragmatic version is one categorical question plus one numeric one: what trust tier is this asset (crown jewel, business critical, support, sandbox), and how many downstream systems would a compromise reach.
The rubric should fit on one printed page. Hand it to a triager and ten minutes per CVE is plenty.
A worked example: Log4Shell across three systems
Use the public Picus dataset as the reference. A static CVSS 10.0 lands at PXS 9.1 on a system with no compensating controls, 7.3 on a system where attacks are detected but not blocked, and 5.2 on a system where the WAF blocks and the SOC logs every attempt. Run the same CVE through the rubric on those three systems and the decisions write themselves: drop everything on the first, fix this week on the second, batch into the regular patch window on the third. The bug did not change. The risk did.
The same exercise applied to a fresh 9.8 advisory, on an internet-facing SSO gateway versus a segmented internal print server, lands the same way. Exploit pressure is identical on both because it is the same CVE. Reachability already splits them: the SSO surface is live every minute of the day, while the print server's vulnerable feature has been turned off for years. From there the divergence only widens. SSVC exposure scores the gateway as Open and the print server as Small, validated controls put MFA and a WAF in front of the gateway against a flat VLAN around the print server, and the blast radius gap is the largest of all, since an SSO compromise brokers access to dozens of downstream systems while the print server holds nothing worth taking. Two assets, one advisory, two queues. That is the entire point of running the rubric.
Where this rubric falls short
The rubric is manual, which is its strength on one CVE and its breaking point at scale. A few hundred new CVEs a day means the same five questions need to be asked by software, on every asset, every time. CVSS v4 Environmental metrics are the standards body's automated answer, and the 25.9% adoption number turns that answer into something mostly aspirational for now. The rubric also depends on inputs you may not have wired into one place: an asset inventory with sensitivity tags, validated control posture, and reachability signals from your build pipeline and runtime. If any of those are missing, the rubric still helps, but step five tilts toward guesswork.
One last caveat. The 0.088 EPSS threshold is a useful default from the FIRST team's own analysis, not a universal cutoff. Tune it to your remediation capacity and re-tune it as EPSS itself evolves.
TRIS at CVEasy AI is the continuous fleet-scale version of this checklist, layering the same EPSS, KEV, SSVC, reachability, and asset-criticality signals across every asset every day, so a 9.8 stops looking the same on every row of the queue. The rubric above is what you can run today without us; the platform is what you reach for when ten minutes per CVE stops scaling.