That 9.8 In Your Ticket Queue Isn't Your Risk Every few months I end up having the same conversation…
Liam R. — Freelance Penetration Tester
That 9.8 In Your Ticket Queue Isn't Your Risk
Every few months I end up having the same conversation. Someone forwards a CVE with a 9.8 next to it, the word "Critical" gets used a lot, and the implied question is why we haven't patched it yet. Usually the honest answer is that the affected service sits behind a management VLAN that about eleven people can reach, and it's been that way for two years.
The 9.8 isn't wrong. It's just not answering the question anyone thinks it's answering.
Base scores are built to ignore you
CVSS Base metrics are defined as intrinsic to the flaw. They're scored under a reasonable worst case assumption: the analyst assumes the vulnerable component is deployed somewhere that exploitation actually works. That's deliberate. A vendor publishes one Base score and it has to carry the same meaning for a bank, a hospital and someone's home lab.
Which means your firewall rules, your segmentation, your WAF signature, your "that port isn't exposed" argument — none of it is in there. Not because those things don't matter. Because the person scoring the CVE has no idea they exist.
If you have ever pointed at a Base score and said "this is our risk", you were pointing at a number that was computed with your environment explicitly excluded.
Where the mitigations actually go
The Environmental group. This is the part of the standard almost nobody fills in, and it's the part built specifically for this.
You get two levers. Modified Base Metrics let you re-score any Base metric against your real deployment. Network-attackable flaw on a box only reachable from the admin segment? Modified Attack Vector drops to Adjacent or Local. Exploitation needs credentials your architecture already forces? Modified Privileges Required goes up. Security Requirements (CR, IR, AR) let you weight confidentiality, integrity and availability by what the asset is for — availability on a batch reporting server is not availability on a payment gateway.
Do that work and the 9.8 becomes something defensible. Skip it and you're triaging on a number that assumes you built nothing.
One thing worth flagging if you're moving between versions. CVSS v3.1 had a Remediation Level metric in the Temporal group, so an official fix or vendor workaround nudged the score down. v4.0 removed it. The Threat group in v4.0 contains Exploit Maturity and that's it — is there working exploit code, is anyone using it. Mitigation credit moved entirely into Environmental, and if you carried a v3.1 mental model across, that's a gap you didn't notice you had.
Label what you actually computed
v4.0 introduced nomenclature that solves a surprising amount of this, and hardly anyone uses it.
- CVSS-B — Base only
- CVSS-BT — Base plus Threat
- CVSS-BE — Base plus Environmental
- CVSS-BTE — everything
What NVD hands you is CVSS-B. Say so. When your team has done environmental scoring, say CVSS-BE and the conversation changes shape immediately, because now the number carries a claim about your estate rather than a generic one. Two people arguing about whether a vulnerability is a 9.8 or a 6.1 are usually not disagreeing about the vulnerability at all. They're comparing a CVSS-B to a CVSS-BE without either of them saying which they've got.
The labels are free. Use them.
The bit that stops this from scaling
Full environmental scoring is per-vulnerability, per-asset effort. Nobody sustains it across ten thousand findings, and I'd be lying if I said we did.
What works in practice is approximating it: asset criticality tiers driving the Security Requirements, exposure data from your asset inventory driving Modified Attack Vector, and hand-scoring reserved for the handful of findings where the argument is actually live. Pair that with EPSS for exploitation likelihood and CISA's KEV catalogue for what's already being used against people, and you get something closer to a priority order than severity alone will ever give you.
CVSS measures severity. Risk is severity plus reachability plus what the asset is worth to you. The standard has always known that. It's just that most of us stopped reading after the Base score.
1 reactions · 4 comments
Comments
Zane A.: Solid breakdown. The gap between a CVSS-B 9.8 and actual risk in a well-segmented environment is something a lot of teams still struggle to communicate upward. I am curious to know how others here handle it in practice: Do you regularly re-score with Environmental metrics? Or do you mostly rely on exposure + asset criticality + KEV/EPSS as a practical shortcut? Would be useful to hear what’s actua
Liam R.: Zane Anderson I think the main issue is that organizations are not adopting CVSS 4.0. As much as possible I prefer to factor in environmental considerations and mitigating factors into reports. The main issue with that is that you often have quite a short period of time to produce reports in and working out the scoring takes time. For web application tests where the number of issues are generally
Zane A.: Liam Romanis Appreciate the detail. That matches what a lot of practitioners run into, environmental scoring is valuable, but the time cost scales badly once you move from web apps into large infrastructure assessments. The tooling gap doesn’t help either. Most scanners still hand you a base score and leave the rest as manual work.
Liam R.: Zane Anderson agreed, its a problem that we could all do with being solved..