Common Vulnerability Scoring System (CVSS) vs. Risk: Why are we still having this conversation?

When I joined Red Hat in 2019, one of the first blogs that I read was titled “Why CVSS does not equal risk: How to think about risk in your environment”. In summary, it explains why CVSS ≠ Risk: Common Vulnerability Scoring System (CVSS) scores measure the severity of vulnerabilities but don’t capture the unique risks they pose to specific environments. Risk is context-dependent, and organizations must consider factors like exploitability, impact and mitigation to tailor vulnerability management to their needs.

Today, many organizations are still measuring the security of their environments by CVSS scores alone. While CVSS is an important tool for understanding the severity of a vulnerability, equating it directly to risk is a mistake.

Risk ≠ Severity

The CVSS score is designed to evaluate the technical severity of a vulnerability, but the risk is about much more than that. Assessing risk also includes:

• Exposure: Is the vulnerable component accessible in your environment?
• Business Impact: What’s at stake if this vulnerability is exploited?
• Likelihood: How feasible is it for an attacker to exploit this specific issue in your setup?

For example, a high CVSS vulnerability in a component that isn’t exposed to the internet and is rarely used in your infrastructure may not pose any risk. On the other hand, a high CVSS issue in an application directly exposed to customers could have serious consequences.

Moving the needle on risk awareness

At Red Hat, we’ve been working to help organizations think about risk more holistically. As my colleague Jeremy West pointed out in his recent article, Do software security features matter in the world of vulnerability remediation?, CVSS is a valuable tool, but it’s just one part of the puzzle. We need to elevate the conversation to address the broader picture. This means going beyond the CVSS score and considering the following factors:

1. Context: Understanding where and how the vulnerability exists in your environment
2. Mitigations: Are there existing measures that reduce the likelihood or impact of an exploit?
   1. Mitigation examples:
      1. Firewalls to block suspicious IPs attempting unauthorized access
      2. IDS/IPS to monitor network traffic and stop unusual patterns
      3. Automated monitoring tools to identify vulnerabilities, such as unpatched software, and trigger alerts for remediation
3. Prioritization: Allocating resources to address issues that pose the most significant risks to the business

Risk-based security

Risk-based security involves assessing potential threats, vulnerabilities, and their impact, then focusing resources on the most critical risks. To better understand this, let’s use a home security analogy:

1. Identifying risks
   • Threats: Burglars, natural disasters, or accidents, such as fires
   • Vulnerabilities: Unlocked doors, windows without locks, or a lack of fire detectors
   • Impact: Loss of valuables, damage to property, or harm to residents
2. Risk assessment
   1. Likelihood: How likely is a burglary? A home in a high-crime area has a greater risk compared to one in a gated community
   2. Severity: A break-in might result in stolen items, while a fire could lead to complete property loss or injuries
3. Risk mitigation
   1. High-risk focus: Address vulnerabilities with the highest impact and likelihood first.
      1. Install a sturdy lock on the front door
      2. Add smoke detectors in key areas like the kitchen and bedrooms
   2. Low-risk items: A backyard shed may not need advanced security if it only contains garden tools
4. Ongoing monitoring and adaptation
   1. Regularly review and adapt your approach, for example, if you purchase a new, expensive television, consider adding window sensors or upgrading to a security camera system
   2. Emerging threats: If a neighbour reports a break-in, adjust your strategy with motion-detecting lights

Key takeaway

Risk-based security prioritizes efforts where they matter most. At Red Hat, we allocate resources to address the most likely and impactful risks rather than trying to eliminate every possible vulnerability.

The way forward

Shifting to a risk-based mindset requires:

• Collaboration between security and operations teams to identify the real-world impact of vulnerabilities
• Improved tooling and processes to bring better visibility to risk
• Ongoing education to move past CVSS as the sole measure of importance

A call to action

As we look ahead, the goal remains clear: making risk, not severity, the driving factor in vulnerability management. 2025 is the year we need to finally move past outdated thinking to focus our resources on what truly matters: reducing real-world risk, not just chasing scores.