When severity scores mislead - the case against single-metric risk models

In late 2021, the Log4Shell vulnerability (CVE-2021-44228) shook the cybersecurity world.

Despite being a “perfect” 10 (in terms of CVSS score), what truly mattered was the speed and scale at which attackers exploited it globally. This made it impossible to ignore a critical, unsolved gap in cybersecurity: severity doesn't always reflect real-world risk.

Since the early 2000s, public vulnerability disclosures have fueled the need for standardized scoring systems. The Common Vulnerability Scoring System (CVSS), first introduced in 2005, offered a way to measure the theoretical severity of vulnerabilities. With each iteration, CVSS evolved to accommodate increasingly complex demands:

• CVSS 2.0 established baseline metrics

• CVSS 3.x added environmental and temporal dimensions

• CVSS 4.0 introduced grouped and supplemental metrics for finer-grained analysis.

Yet CVSS still primarily answers "how bad could this vulnerability be?", not "how likely is it that exploitation actually happens?" or "how urgent is it to mitigate this CVE in my environment?"

This gap between severity and actual exploitation has led to alert fatigue, misplaced priorities, and wasted resources.

This is why we wanted to unpack why relying on a single score for vulnerability classification and remediation is no longer sufficient. And because we’re sticklers for accuracy, we’re also looking at how integrating exploitability models like EPSS (Exploit Prediction Scoring System), asset exposure, and business impact analysis can create a multi-dimensional vulnerability view that reflects risk more realistically.

Whether you do security engineering work, penetration testing, or vulnerability management, you know that mastering multi-perspective scoring is now essential for doing your job well - without losing your mind. We’re here to contribute to that. 

The limitations of single-scoring systems: why one score is not enough

The problem with one-size-fits-all scoring: noisy outputs and misleading severity ratings

Relying solely on a single score - like CVSS - offers a false sense of simplicity.

It assumes that every vulnerability impacts every environment in the same way, which is dangerously misleading.

That’s why automated vulnerability scanners flood security teams with thousands of "critical" findings based only on CVSS thresholds (e.g., anything above 7.5).

Yet not all "critical" vulnerabilities are truly urgent in every environment.

Consider this: a tool flags a CVSS 9.8 vulnerability as a critical issue, but it’s buried in an outdated WordPress plugin on a secluded, intranet-only marketing site with no access to user data. The scanner raises a red flag - Critical - but the real-world risk is minimal.

Now compare that to a CVSS 6.5 vulnerability in a publicly exposed payment processing API. The scanner labels it Medium severity, yet if exploited, it could lead to serious financial loss and reputational damage.

Because many tools blindly prioritize based on CVSS, analysts waste time chasing non-issues - while real risks may remain under-prioritized.

The risk you don’t see: blind spots in asset context

Since CVSS scores are calculated independently of your organization's environment, they cannot answer critical questions like:

• Is the asset public-facing?

• Is it isolated by firewalls or zero-trust architecture?

• Is this a crown-jewel system or a low-value asset?

As you know from hard-earned experience, without this context, critical blind spots appear (and make your work much more difficult).

Take this real-world scenario: you find a CVSS 9.0 vulnerability on a forgotten staging server, still live on an old cloud subscription that was set up outside the IT or security team’s oversight. Since it’s not listed in any asset inventory, you can’t actively monitor it, and it’s directly exposed to the Internet.

This vulnerability that seems "internal and harmless" on paper becomes a public breach risk — simply because asset governance failed, as it so often does in complex, sprawling infrastructures.

Unmanaged assets, such as shadow IT, forgotten domains, or rogue SaaS applications, are often the attacker's favorite footholds — and CVSS cannot warn you about them.

Without accurate internal asset management and business mapping, scoring systems miss the real exposure that attackers see. And since neither of those processes can ever be perfect in real-world organizations, we need more dimensions to make sure we have the full picture of how a security issue can affect them.

Why we need to look beyond severity to prioritize real risk

Effective vulnerability management today requires answering 3 essential questions:

• Is it actively exploited? (e.g., CISA’s Known Exploited Vulnerabilities Catalog)

• How critical is the asset? (e.g., a revenue-generating system vs. a lab server)

• What’s the business impact if compromised? (e.g., regulatory fines, data loss, operational shutdown)

In the real world, we need to balance severity against:

• Exploitability (real-world likelihood)

• Asset criticality (value and sensitivity)

• Business context (operational impact, compliance obligations).
  
  

Take CVE-2021-44228 - Log4Shell - as an example. It received a “perfect” CVSS score of 10.0, but severity alone didn’t tell the full story. The vulnerability affected Log4j, a widely used library embedded in countless applications. It was remotely exploitable with minimal effort, found in critical public services and financial systems, and active exploitation began almost immediately after disclosure.

Prioritizing Log4Shell was about more than its CVSS score - it was about the combination of exposure, exploitability, being linked to critical assets, and business continuity.

The scoring systems that reveal what CVSS misses

Security teams still rely heavily on CVSS for assessing vulnerability severity, but today’s threat landscape demands a multi-dimensional approach.

Severity alone cannot answer key questions like "Will this vulnerability be exploited in my environment?" or "Does it impact my most critical assets?"

To close these gaps, cybersecurity professionals increasingly rely on complementary scoring systems that bring threat dynamics, asset relevance, and exploitation data into the decision-making process - like the one Willa Riggins describes.

I like to think of it as two different parts of how we measure risk and impact. One is kind of our technical risk. This is in a vacuum without all the modifiers for what industry we're in, what our compliance needs are. What is that finding in a vacuum? The CVSS score of a CVE that's out on the Internet. What is that score? What does it mean? 

And then kind of taking that and looking at what we call a residual risk, what does it look like for us? And that can be very different. Maybe there are mitigating factors like network security, firewalls, detections, web application firewalls. What are those mitigating technologies? 

And then is it on the perimeter? Is it all on the Internet or is it just an internal application or who uses it, how many users are on it, what data does it process? All those different things, kind of then modify that residual risk down to understand where does it actually land for us, what's most important?

So I think my ask of my testers is to keep reporting all the things. Don't let the environment affect how you feel about a vulnerability. Do your best to be objective, to measure it in a vacuum, and then apply kind of what the business thinks about that vulnerability. And we work really closely with our stakeholders in product security as well to kind of calibrate some of those, because we don't always know that. As pentesters, we're not experts on every domain and every business unit in a company. We only know what we are given and what we know from our experience of being there. So oftentimes partnering with other parts of an organization or even in a consulting environment, partnering with the customer to understand what are your needs and what makes the most sense for you. 

But I think my ask of testers is just keep doing what you do and do it well because we get into this kind of, we don't want to commoditize pentesting. We don't want to make it where it's just we're checking a box. We want to continue to do the high-level, in-depth work that we're supposed to do as part of our craft.

The Exploit Prediction Scoring System (EPSS)

EPSS provides a statistical estimate of the likelihood that a vulnerability will be exploited in the wild.

Unlike CVSS, which measures theoretical severity, EPSS focuses on real-world exploitation probability within 30 days of disclosure.

📊 EPSS evolution:

 Recent events (real CVEs):

EPSS enables more targeted mitigation and patching, especially when you have limited resources (and which security team doesn’t?).

Bridging the gap: vendor vulnerability scoring vs. internal risk models

Since the gap we’re looking at is a painful one, many security software vendors supplement public scores with proprietary severity ratings to highlight real-world risk signals more appropriately:

• Microsoft Security Updates distinguish between "Critical" and "Important" patches.

• Cisco publishes specific "exploitation detected" flags in PSIRTs (advisories for Product Security Incident Response Teams).

• SAP issues patch priorities based on business process impact.
  
  

Additionally, risk communication standards like VEX (Vulnerability Exploitability eXchange) allow vendors to formally state if a vulnerability actually impacts their products and reduce noise for security practitioners monitoring them.

VEX is a form of a security advisory, similar to those already issued by mature product security teams today. There are a few important improvements for the VEX model over ‘traditional’ security advisories. First, VEX documents are machine readable, built to support integration into existing and novel security management tools, as well as broader vulnerability tracking platforms. Second, VEX data can support more effective use of Software Bills of Materials (SBOM) data. The ultimate goal of this document is to support greater automation across the vulnerability ecosystem, including disclosure, vulnerability tracking, and remediation.

Source: CISA’s Vulnerability Exploitability eXchange (VEX) – Use Cases

Even if a vulnerability has a “critical” CVSS score, security teams might not prioritize it for emergency patching when internal mitigations are in place and a VEX statement confirms it isn’t exploitable in the current setup. Conversely, vendors often raise urgency after disclosure if they confirm active exploitation, regardless of the original CVSS rating.

Through our work, each of us contributes to this ever-changing perspective on risk that so many jobs and livelihoods depend on.

Risk models for real-world prioritization: what to use when CVSS isn’t enough

Relying on a single metric won’t cut it in real-world vulnerability management. To truly understand and prioritize risk, you need to combine multiple scoring models that reflect exploitability, business impact, and asset context.

And while all that sounds nice and necessary, bringing it into real-world practice is an entirely different beast. Let’s see how we can tame it. 

Complementary risk models

To move beyond the limitations of CVSS, security teams are turning to complementary scoring models that provide additional dimensions of risk. 

• The Exploit Prediction Scoring System (EPSS) helps predict the likelihood of a vulnerability being exploited in the wild, allowing teams to prioritize patching for CVEs that attackers actively target. 

• Stakeholder-Specific Vulnerability Categorization (SSVC) introduces decision trees that guide vulnerability handling based on mission or business criticality, enabling smarter prioritization aligned with organizational goals. 

• Meanwhile, the Known Exploited Vulnerabilities (KEV) Catalog, which CISA maintains, confirms exploitation activity in the wild - critical for compliance-driven environments where mandatory patching is required. 

• Finally, the Vulnerability Exploitability eXchange (VEX) model communicates whether a vulnerability is actually exploitable in a given product or deployment. This helps avoid unnecessary fixes by filtering out CVEs irrelevant to your environment. 

In an ideal scenario, using these models together equips teams to act with precision and reduce noise in vulnerability triage. However, while security teams strive for comprehensive coverage, we know there are plenty of challenges for them to do their best work.

How to build a multi-dimensional view of risk that works

When a single structural weakness - like CWE-787 (Out-of-Bounds Write) - consistently shows up in high-impact CVEs across critical systems, it’s a signal to dig deeper. Recognizing these patterns isn’t just helpful - it’s essential to managing real risk effectively.

For vulnerability analysts, penetration testers, and security engineers, relying on CVSS alone doesn’t cut it anymore. Prioritizing based on context - exploitability, asset value, and business impact - isn’t a nice-to-have. It’s how you make sure your effort goes where it matters most.

This section walks you through how to build a vulnerability view that reflects the full picture: technical threat, real-world context, and business relevance.

Linking vulnerabilities to what actually keeps the business running

Vulnerabilities don’t exist in a vacuum. 

To prioritize effectively, you need to consider more than just the technical details. The business process impacted, the sensitivity of the exposed data, and how critical the asset is to operations - all of these should guide your next move.

In offensive security work, understanding asset context is key to identifying which vulnerabilities truly matter. 

Start by categorizing each asset by its exposure level (public, internal, or semi-public), business function, data sensitivity, and potential business impact. 

For example, a public-facing e-commerce platform that processes payment data directly ties to revenue and compliance - so even a moderate vulnerability here demands immediate attention. 

In contrast, an internal development test server with no sensitive data likely poses minimal business risk, even if its CVSS score is high. 

Assets involved in handling regulated data (like GDPR or PCI-DSS) or those that drive revenue or enable external integrations should be prioritized higher in risk assessments. 

This mapping helps penetration testers and vulnerability analysts move beyond severity scores and triage findings based on real-world consequences to the business.

📊 Example: asset context mapping

How tracking recurring weaknesses (CWEs) reveals attack patterns

Looking beyond individual vulnerabilities, it’s just as important to track which types of weaknesses (CWEs) show up most often and get exploited in the wild. Some patterns are becoming more common across modern attack surfaces - and recognizing them helps you stay ahead of what attackers are targeting.

📊 Top emerging CWE patterns (2024–2025)

Tracking recurring weaknesses - like CWE-787 (Out-of-Bounds Write), CWE-918 (SSRF), and CWE-79 (XSS) - helps uncover patterns in how attackers exploit systems like the ones you work so hard to monitor and protect. 

These CWEs consistently show up across modern architectures, from IoT devices and cloud APIs to browser engines and mobile frontends. 

For example, CWE-787 remains a common root cause of remote code execution in embedded systems, while SSRF is gaining ground in cloud-native environments where internal metadata services are exposed. And XSS continues to affect even well-secured web apps. 

By identifying which weaknesses keep resurfacing, security teams can target training, code reviews, and hardening efforts more effectively - preventing entire classes of vulnerabilities from ever reaching production.

How entropy reveals hidden patterns in vulnerability risk

In vulnerability management, entropy describes how much the severity and exploitability of vulnerabilities linked to a specific weakness (CWE) can vary. The more unpredictable the behavior, the higher the entropy.

High entropy suggests inconsistent or erratic risk profiles, while low entropy indicates more predictable patterns. 

By calculating normalized entropy across CVSS and EPSS scores for all CVEs linked to a given CWE, security teams can gain deeper insights into how that weakness tends to manifest in the real world. 

This helps answer key questions: 

Does this weakness consistently lead to high-impact vulnerabilities, or is the risk profile all over the place? and 

Should defenders expect a narrow exploitation path or prepare for a wide range of attack scenarios? 

Understanding CWE-level entropy helps teams to make smarter prioritization decisions and proactively design more resilient defenses.

Example: normalized entropy by CWE

Normalized entropy by CWE gives security teams a way to measure how predictable - or unpredictable - a weakness is when it comes to real-world impact. By analyzing entropy across both CVSS and EPSS scores for related CVEs, you can spot which weaknesses tend to behave consistently and which ones carry more uncertainty. 

For example, CWE-89 (SQL Injection) shows low variability and high severity, meaning it’s a predictable, high-risk issue that demands immediate remediation if found. On the other hand, CWE-79 (XSS) has high entropy in both scoring systems, signaling that its impact can vary wildly - some instances are harmless, while others can be catastrophic. 

This insight helps teams not only prioritize more effectively, but also anticipate the level of effort needed to assess and respond to specific types of weaknesses.

Building a prioritization workflow that reflects real risk

Effective vulnerability management isn’t about chasing CVSS scores - it’s about making informed decisions based on multiple dimensions of risk. 

To build a meaningful prioritization workflow, combine key scoring systems and contextual signals:

• CVSS Base Score evaluates the theoretical technical severity of a vulnerability.

• EPSS estimates the real-world likelihood of exploitation based on live threat data.

• KEV listings (CISA) confirm whether threat actors are actively exploiting a vulnerability.

• Asset Business Criticality shows how much operational damage a compromise could cause to your organization.

• CPE (Official Common Platform Enumeration) exposure helps verify if the vulnerable system is publicly accessible.

Let’s look at how this works in practice:

• CVE-2024-21683 (Confluence RCE) has a high CVSS (8.8), very high EPSS (0.94), is actively exploited (KEV: Yes), and affects a public-facing customer portal. This combination justifies an immediate patch.

• CVE-2024-29824 (Ivanti SQLi) scores slightly higher on CVSS (9.6) and has a high EPSS (0.85), but impacts an internal HR system—still important, but not as urgent as a public-facing asset. It warrants a high-priority patch.

• CVE-2024-26082 (Adobe XSS) shows moderate CVSS (6.5), low EPSS (0.02), is not in CISA’s KEV list, and affects a low-impact marketing microsite. This one can be safely deferred to the next maintenance cycle.

When you factor in entropy - the predictability of risk within each CWE group - you also gain insight into how variable or consistent a vulnerability’s behavior might be. For instance, high entropy CWEs (like XSS) demand more context before patching decisions, while low entropy ones (like SQLi) almost always require immediate action.

Takeaway: Focus your resources on what’s actively being exploited and impacts business-critical, exposed assets. That’s how you turn vulnerability data into action - efficiently and with confidence.

Reality check: contextual scoring sounds great - but is it practical?

We get it. Most security teams don’t have endless time, staff, or perfect asset inventories. Sticking with CVSS-only workflows feels faster, simpler, and tool-friendly—especially when you’re racing to meet SLAs or satisfy audit checklists.

But here’s the truth:

• CVSS was never meant to be used in isolation.

• Ignoring exploitability, asset context, and business risk creates blind spots attackers exploit.

• False positives cost more than time—they cost trust and momentum.

You don’t need to rebuild your process overnight. Start small:

• Add EPSS or KEV data into your triage logic.

• Categorize your most exposed or revenue-critical assets.

• Reassess criticality weights once a quarter.

Contextual scoring isn’t about chasing perfection. It’s about making fewer wrong calls, faster - and doing work that actually reduces risk.

Continuous monitoring and improvement

Finding vulnerabilities and prioritizing them is just the starting point. 

To keep pace with unexpected evolutions in attacker tactics, security teams need to treat vulnerability management as a continuous, adaptive process - not a one-off task. While everyone knows this - practicing it is much more difficult than preaching it. 

Regularly scanning assets and monitoring them, adjusting priorities as the business context shifts, and refining workflows based on what actually works all hide a sometimes overwhelming degree of complexity. 

To keep things realistic, we need to remind ourselves that the goal isn’t perfection - it’s consistency, collaboration, and the ability to respond quickly with the right data at the right time.

Building a reliable vulnerability scanning workflow with automation

To keep your vulnerability management process consistent and scalable, automation needs to go beyond just running scans - it has to support comprehensive coverage, accurate prioritization, and real-world risk validation. 

A well-structured workflow includes four key components:

1. Continuous asset discovery: tools like Censys or internal scanners help keep your asset inventory accurate and up to date. In an ideal scenario, this ensures no exposed system is left out of the scan schedule. In real life, minimizing the number of systems that are unaccounted for is always a best effort in complex circumstances. 

2. Scheduled vulnerability scans: combining EPSS and KEV data with findings from scanning tools such as the ones on Pentest-Tools.com or Nessus or OpenVAS can help security teams detect real and relevant weaknesses, not just theoretical ones. It’s worth checking out network and web app scanners benchmarks to compare accuracy before you make your choice.  

3. EPSS + KEV integration: by combining vulnerability feeds with SIEM rules or enrichment scripts, security teams can prioritize threats attackers are actively exploiting, going beyond severity when focusing on mitigation.

4. External exposure validation: tools like Shodan or custom scripts confirm whether vulnerable services are actually exposed online - closing the gap between detection and real-world risk.
   
   

When done right, automation doesn’t just improve speed - it makes the entire process more reliable and repeatable. You reduce blind spots, cut down on manual overhead, and give analysts time to focus on what matters: triage, escalation, and incident prevention.

How to tell if your prioritization model works

Here are a few low-lift ways to validate that your model is improving—not just shifting the burden:

You can’t improve what you don’t measure. These metrics help you prove - not just claim - that your prioritization model works in your real environment.

Keeping risk models relevant through constant fine-tuning

In fast-changing environments, static prioritization doesn’t hold up. Threats shift, systems change, and attacker behavior evolves. That’s why security teams need to treat risk scoring as a living process - something they can adjust as conditions change.

To keep vulnerability management accurate and grounded in real-world exposure, teams should regularly:

• Reassess asset criticality as new apps go live or legacy systems are retired.

• Reweigh exploitability signals when EPSS models are updated or KEV listings expand.

• Incorporate emerging CWE trends, such as the rise of SSRF in cloud-native services.
  
  

In practice, this means checking for new IPs or assets monthly, validating business impact scores quarterly, adjusting for new threat patterns after major incidents, and fully reviewing prioritization logic at least once a year. These steps aren’t just checkboxes - they help ensure your risk model reflects today’s attack surface, not last year’s assumptions.

Security teams need workflows that are adaptable but also consistent and we know that’s no easy feat to achieve. The goal is to avoid “set-and-forget” logic and instead build in lightweight feedback loops that help your tools and processes evolve alongside the vulnerabilities and threats you’re defending against.

Takeaway: Teams that recalibrate often don’t just react faster - they prioritize better, avoid burnout, and deliver more focused remediation efforts.

Why vulnerability management only works when teams work together

Vulnerability management is highly dependent on the organization’s dynamic. Security teams can’t triage vulnerabilities effectively if IT teams don’t get looped in to do timely patching - or if business stakeholders aren’t involved in setting priorities based on real-world impact. 

To keep remediation efforts grounded, aligned, and achievable, organizations need tight collaboration across roles.

That means setting up regular feedback loops. Start by reporting key metrics like time to patch, SLA compliance, and open high-risk CVEs every month. Track incidents tied to unpatched vulnerabilities, and collect feedback from asset owners to understand operational impact. This helps ensure that the decisions the security team makes don’t clash with business or IT constraints - and that the right vulnerabilities get mitigated at the right time.

For example, aiming to patch critical vulnerabilities within 7 days or maintaining over 90% SLA compliance isn’t just about hitting a target - it’s about proving that your process works. A shared dashboard that tracks these indicators helps everyone stay aligned and builds trust between security and the business.

Takeaway: Feedback turns vulnerability data into action. When security, IT, and business teams close the loop together, they move faster, fix what matters most, and stay aligned with the real-world needs of the organization.

Real risk requires real context

Vulnerability management isn’t about chasing high CVSS scores or blindly following patch cycles anymore. In a threat landscape that evolves daily, static checklists fall short. 

What security teams need is a dynamic, risk-driven approach - one that reflects how attackers actually operate, and how businesses actually run.

Adopting a multi-dimensional strategy - combining CVSS severity, EPSS exploitability, asset criticality, CPE exposure, and structural weakness insights (like CWEs) - changes everything. It brings clarity, speed, and accuracy to a process that too often drowns in noise, which is why it’s worth the effort to build it.

This approach helps you:

• Build a shared language across security, IT, compliance, and leadership - improving collaboration and decision-making.

• Improve accuracy by factoring in real-world risk, not just theoretical severity.

• Prioritize what matters, based on actual exploitation potential and business impact.

• Cut through noise by using probabilistic models like EPSS, reducing false positives and saving valuable analyst time.

• Add context to each vulnerability, eliminating blind spots tied to unmanaged or misunderstood assets.

• Strengthen compliance with NIST, PCI-DSS, and SOC 2 by using evidence-backed prioritization.

• Tie technical issues to business risks - securing buy-in from executives and budget holders.

• Improve the effectiveness of remediation workflows through integrations with ticketing systems, SIEMs, and automation tools.

• Raise risk awareness across the organization, moving from reactive patching to proactive defense.

• Allocate resources more effectively, focusing effort where it actually reduces risk.

• Reflect your unique security posture, business priorities, and regulatory requirements.

• Increase stakeholder trust by showing exactly how and why decisions are made.

• Embed continuous improvement, using feedback loops and recalibration - not one-off fixes.

• Reduce security team burnout by giving them clarity, purpose, and control.
  
  

⚠️ Here’s the reality: attackers evolve daily - so if your security workflows stay static, you’re giving them the advantage.

Attackers adapt faster than most teams can react. If you’re standing still, you’re already behind. That’s why contextual, adaptive vulnerability management isn’t just a “nice-to-have.” It’s the only way forward.

What to do next

For security teams:

• Integrate asset criticality, EPSS, and CWE analysis into daily triage.

• Automate asset discovery and exposure validation to keep coverage complete.

• Recalibrate your risk models regularly - make adaptation a habit, not a reaction.

For security leaders:

• Build risk models that reflect both technical severity and business reality.

• Sponsor long-term initiatives: continuous monitoring, developer education, and feedback-driven improvement.

• Treat contextual prioritization as strategic - not overhead. It’s how sustainable security starts.
  

Final thought

If vulnerabilities are evolving faster than ever, reacting slower - or not at all - isn’t neutral. It’s falling behind.

Adapt, prioritize with purpose, and lead with context.

That’s how you stay ahead.