The CVSS Deception: How We've Been Misled on Vulnerability Severity
This talk analyzes the operational limitations and systemic flaws of the Common Vulnerability Scoring System (CVSS) in accurately reflecting real-world risk. The speakers demonstrate how CVSS metrics often fail to account for environmental dependencies, exploit maturity, and privacy implications, leading to misprioritized remediation efforts. They propose a more nuanced approach to vulnerability management by incorporating threat intelligence and context-aware metrics. The presentation highlights the need for industry-wide improvements in how vulnerability severity is communicated and acted upon.
Why CVSS Scores Are Failing Your Vulnerability Management Program
TLDR: The Common Vulnerability Scoring System (CVSS) is fundamentally broken for risk prioritization because it ignores environmental context, exploit maturity, and privacy impact. By treating all components of the CIA triad with equal weight, CVSS often masks critical business risks while inflating the severity of less impactful bugs. Security teams must move beyond raw scores and adopt context-aware metrics like the Exploit Prediction Scoring System (EPSS) to focus on what actually matters.
Vulnerability management is currently drowning in noise. Every month, thousands of new CVEs hit the National Vulnerability Database (NVD), and most organizations default to a "fix everything with a score of 9.0 or higher" strategy. This approach is not just lazy; it is dangerous. It forces teams to waste limited engineering cycles on high-scoring vulnerabilities that are practically unexploitable in their specific environment, while ignoring lower-scoring bugs that could lead to full system compromise or massive data exfiltration.
The Aggregation Trap
The core issue with CVSS is its reliance on a rigid, aggregated scoring formula that treats Confidentiality, Integrity, and Availability as interchangeable parts of a single score. If a vulnerability impacts only one of these, the formula still caps the maximum possible score, often resulting in an artificially low rating for a bug that could be catastrophic for a specific business function.
Consider the Citrix NetScaler vulnerability (CVE-2020-8187). During the pandemic, this bug was a massive availability risk for remote work infrastructure. Because it didn't involve complex code execution or data theft, its CVSS score failed to reflect the true business impact. When you rely on a single number to dictate your patching schedule, you are essentially outsourcing your risk assessment to a formula that doesn't know your network architecture.
Exploit Maturity and the "Unknown" Variable
Another major blind spot is the "Exploit Code Maturity" metric. CVSS assumes that if an exploit isn't public, the risk is lower. In reality, sophisticated threat actors are often using private, weaponized exploits for months before a PoC hits GitHub.
The MOVEit Transfer SQL injection (CVE-2023-34362) is a perfect example of this disconnect. By the time the industry had a clear picture of the exploit maturity, the damage was already done. Relying on CVSS to tell you when to patch is like checking the weather report after you are already soaked in the rain. Pentesters and researchers should look toward EPSS, which provides a data-driven probability of exploitation in the wild, rather than a static, theoretical severity score.
The Privacy Blind Spot
Privacy is arguably the most critical concern for modern enterprises, yet it is entirely absent from the CVSS framework. A vulnerability that leaks a user's PII is a nightmare for compliance and reputation, but if that same vulnerability doesn't allow for remote code execution, it often gets a "Medium" rating.
Look at the Zoom information disclosure vulnerability (CVE-2019-13450). It allowed websites to force users into a call with their camera active. From a pure technical perspective, this might not look like a "Critical" RCE, but from a privacy and legal perspective, it was a disaster. CVSS lacks the nuance to distinguish between a bug that crashes a service and a bug that violates the fundamental privacy of your users.
Moving Toward Context-Aware Prioritization
If you are a pentester or a researcher, stop reporting vulnerabilities based solely on their CVSS score. Your clients don't care about the score; they care about the risk to their specific assets. When you find a bug, map it to the MITRE ATT&CK framework to show exactly how it fits into an adversary's kill chain.
For those building internal tools, stop using the raw CVSS vector as your primary sort key. Instead, build a scoring model that incorporates:
- Asset Criticality: Is the affected system public-facing or internal?
- Data Sensitivity: Does the system handle PII, credentials, or proprietary code?
- Exploitability: Is there a known, weaponized exploit available in the wild?
Defenders should focus on OWASP Top 10 categories to understand the type of risk, rather than just the severity of the risk. If you are dealing with Broken Access Control (A01:2021), no amount of CVSS "Low" or "Medium" ratings should make you feel comfortable.
The industry is moving toward a more mature model of risk management, but we are still held back by the legacy of CVSS. Stop letting a static, outdated formula dictate your security strategy. Start looking at the actual threat landscape, the specific data at risk, and the reality of how your systems are deployed. If you aren't doing this, you aren't managing risk; you're just managing a spreadsheet.
Vulnerability Classes
Target Technologies
Attack Techniques
OWASP Categories
Up Next From This Conference

BestFit: Unveiling Hidden Transformers in Windows ANSI

Wi-Fi Calling: Revealing Downgrade Attacks and Not-so-private Private Keys

The CVSS Deception: How We've Been Misled on Vulnerability Severity
Similar Talks

Kill List: Hacking an Assassination Site on the Dark Web

Counter Deception: Defending Yourself in a World Full of Lies

