Your scanner found a Critical vulnerability. CVSS 8.8. The security team is panicking. Slack is blowing up. Someone is already drafting a remediation plan.
But here’s the thing. That score might be completely irrelevant to your product.
The Problem With Scores in a Vacuum
CVSS scores tell you how bad a vulnerability could be in a theoretical worst case. They don’t tell you whether it actually matters for your specific device, in your specific architecture, with your specific controls in place.
I see this constantly in my work with medical device manufacturers. A scan comes back with 200 CVEs. The team looks at the CVSS scores, sorts by severity, and starts working from the top. They spend weeks investigating vulnerabilities that were never exploitable in their product in the first place.
That’s not security. That’s busywork.
A Real Example
Take CVE-2024-6345. Remote code execution in setuptools. CVSS 8.8. Every scanner on the planet flags this as High severity and tells you to patch immediately.
Now look at it in context. The affected component sits on a medical imaging device running a locked down Windows OS. The environment is DISA STIG hardened with BitLocker, AppLocker, and TPM backed Secure Boot. The vulnerable function in package_index is deprecated. The device doesn’t accept user controlled package URLs. There is no pathway for an attacker to reach the vulnerable code.
The CVSS score is 8.8. But the exploitability in this product is near zero. The vulnerability exists in the codebase, but the controls in place make it effectively unreachable. A proper residual risk assessment would score this at a 2.1, not an 8.8.
A security engineer who knows this product would spend about 10 minutes figuring that out. But they have to do that analysis for all 200 CVEs. Multiply that across 5 or 10 products and you’re looking at hundreds of hours of manual work every quarter.
Same CVE, Different Product, Different Answer
Here’s where it gets interesting. That same CVE on a different device might absolutely matter.
Put setuptools on a cloud connected patient monitoring system where the component actively downloads packages from external sources. No application whitelisting. Standard OS configuration. Now that 8.8 is real. The vulnerable function is in the execute path and an attacker has a viable route to exploit it.
Same vulnerability. Same CVSS score. Completely different risk decisions. The score didn’t change. The product context did.
This is the fundamental problem with relying on CVSS as your prioritization mechanism. The score describes the vulnerability. It says nothing about your product.
What Actually Matters
The real question isn’t “how bad is this CVE?” It’s “how bad is this CVE for this product?”
Answering that question requires context that no scanner has. You need to know the product architecture. You need to know which components are exposed and which sit behind trust boundaries. You need to know what hardening is in place. You need to know whether the vulnerable function is actually used. You need to know the threat model.
Most manufacturers have this information. It lives in threat models, architecture documents, design reviews, and the heads of senior engineers. The problem is that none of it is connected to the vulnerability data. The SBOM lives in one place. The threat model lives in another. The scan results live in a third. And some poor engineer is manually cross referencing all of it for every single CVE.
Where This Is Going
The industry is waking up to this. CISA’s BOD 26-04 moves away from CVSS based prioritization toward SSVC, which considers things like asset exposure and exploit automation alongside the technical severity. The VEX standard exists specifically to communicate whether a vulnerability actually affects a product. The conversation is shifting from “what’s the score” to “what’s the actual risk.”
But the tooling hasn’t caught up yet. Most platforms still dump a list of CVEs sorted by CVSS and leave the contextual analysis to the human. That’s the gap.
We’ve been building Product Security Hub to close this gap. When your threat model, architecture, trust boundaries, requirements, and SBOMs all live in the same platform, you can evaluate every new vulnerability against the actual product design. Not just the score. The product.
We just finished building context aware AI triage that does exactly this. When new CVEs are identified, the system evaluates each one against the product’s architecture, components, threats, and controls. It generates a detailed assessment with reasoning, not just a pass/fail. An engineer reviews and approves the output. The whole thing takes minutes instead of days.
I’ll write more about how this works in a future post. For now, the takeaway is simple: if you’re prioritizing vulnerabilities based solely on CVSS scores, you’re spending most of your time on things that don’t matter and potentially missing things that do.
Your product context is the missing piece. Without it, every CVSS score is just a number on a screen.