top of page
background_1.jpg

Stop Chasing CVSS Scores: Why Attack Path Analysis Is the Future of Vulnerability Management

  • Foto van schrijver: Paul Veenstra
    Paul Veenstra
  • 5 dagen geleden
  • 7 minuten om te lezen

Picture this: Your vulnerability scanner just finished its weekly run and flagged 347 critical vulnerabilities across your environment. Your patch management process kicks in. Tickets get created. Change requests get filed. Maintenance windows get scheduled. Your team starts the long slog of patching, testing, and deploying updates.


Three months later, you're still working through that list. And this week's scan just found 289 new critical vulnerabilities.


You're running on a treadmill that's only getting faster. And here's the uncomfortable question: are you actually getting more secure, or just more exhausted?


The Traditional Approach Is Broken


Let's be honest about how most organizations still handle vulnerability management. A scanner finds vulnerabilities, assigns them CVSS scores, and everything rated 9.0 or above becomes "critical" and needs to be patched immediately. Everything else gets prioritized by score and age.


It's a numbers game. Reduce the count of critical vulnerabilities. Show progress in your metrics. Report improvement to leadership.


The problem? CVSS scores don't tell you what actually matters in your environment.


That critical SQL injection vulnerability in your internet-facing web application? Absolutely needs immediate attention. But what about that equally "critical" vulnerability in a legacy system that's segmented behind three layers of network controls, requires domain admin credentials to exploit, and has no path to any sensitive data?


Under traditional vulnerability management, both get the same priority. Both burn the same amount of your team's limited time and political capital to patch. Both require the same change management overhead.


But one of them actually puts your organization at risk. The other is theoretical.


Enter Continuous Threat Exposure Management


Continuous Threat Exposure Management—or CTEM—represents a fundamental shift in how we think about vulnerabilities. Instead of asking "what's vulnerable?", it asks "what can an attacker actually do?"


The difference is enormous.


CTEM focuses on attack paths. It maps how an attacker could move from an initial foothold to your critical assets. It understands your network topology, your access controls, your privileged accounts, and how they all interconnect. It considers not just individual vulnerabilities, but how they could be chained together in a realistic attack scenario.


Most importantly, it helps you answer the question that actually matters: What vulnerabilities, if exploited, create a realistic path to compromising our critical systems and data?


Those are the vulnerabilities that deserve your immediate attention. Everything else can wait.


Why This Changes Everything


Let's walk through a real-world example to see the difference in practice.


Traditional Approach: Your scanner identifies 100 critical vulnerabilities this month. You file 100 change requests. You schedule patches across 100 systems. Your change advisory board reviews 100 changes. You spend weeks coordinating maintenance windows. You deploy patches. You test. Some break things and need rollback. You start over.


Meanwhile, vulnerability #47 on that list—a critical RCE in an internet-facing portal that has a direct connection to your financial systems—sits unpatched for six weeks because it's caught in the same queue as 99 other "critical" items.


CTEM Approach: Your exposure management platform maps attack paths to critical assets. It identifies that same internet-facing portal vulnerability and flags it as high-risk because it's externally accessible, leads to systems with sensitive data, and has known exploitation in the wild. That gets patched within 48 hours.


The other 99 vulnerabilities? The platform shows that 73 of them have no realistic attack path to critical systems given your current security controls. They get deprioritized. The remaining 26 get prioritized based on actual risk, not just CVSS scores.


Your team patches 27 things that actually matter instead of spinning wheels on 100 things that mostly don't.


The Attack Path Perspective


Here's what makes attack path analysis so powerful: it considers your environment as an interconnected system, not a collection of isolated vulnerabilities.


It asks questions like:


  • Can this vulnerable system be reached from the internet, or from an already-compromised internal system?

  • If exploited, what credentials or access would an attacker gain?

  • From there, what systems could they pivot to?

  • How many steps to your crown jewels—your financial data, customer information, intellectual property, production systems?

  • What compensating controls exist along that path?

  • Are there alternative paths if this one gets blocked?


When you map these attack paths, a clear picture emerges. Some vulnerabilities are critical because they're on a short, realistic path to high-value targets. Others, despite scary CVSS scores, are dead ends that lead nowhere interesting.


This is how attackers actually think. They don't care about your CVSS scores. They care about paths to profit.


Risk-Based Prioritization in Practice


Moving to risk-based prioritization doesn't mean ignoring vulnerabilities. It means being smart about which ones you tackle first.


External Exposure + Critical Asset Access = Top Priority Anything internet-facing that has a path to critical systems goes to the front of the line. These are the vulnerabilities attackers will find and exploit first.


High-Value Targets = High Priority Vulnerabilities in systems that directly house or process your most sensitive data get prioritized, even if they're not externally exposed. If an attacker is already inside your network, these are their targets.


Privilege Escalation Paths = Medium-High Priority Vulnerabilities that could allow lateral movement or privilege escalation along attack paths to critical assets need attention, even if they're not in critical systems themselves. They're stepping stones.


Dead Ends = Lower Priority Vulnerabilities in isolated systems with no path to sensitive data or critical operations can be addressed in normal patch cycles. They're not zero risk, but they're not emergency-level risk either.


Breaking Free from Patch Management Theater


Let's call it what it often is: patch management theater. We patch frantically to reduce vulnerability counts and improve metrics, creating the appearance of security without necessarily reducing actual risk.


It's security theater because we're optimizing for the wrong thing. We're trying to achieve an impossible goal—zero critical vulnerabilities—instead of the achievable and meaningful goal of protecting our critical assets from realistic attack scenarios.


This approach burns out teams, wastes resources, and creates organizational friction. How many times have you had to go to battle with application owners to patch something that, deep down, you know doesn't actually matter that much? How much political capital gets spent on change requests that don't meaningfully improve security posture?


CTEM lets you focus your energy where it counts. When you go to your application owners or your change advisory board, you're not saying "the scanner says this is critical." You're saying "if this doesn't get patched, here's the specific path an attacker could take to compromise our financial systems."


That's a conversation people understand. That gets things done.


The Old Guard Pushback


We hear objections to this approach, usually from people invested in traditional processes:


"But what if we miss something?" You're already missing things. When you're drowning in a backlog of hundreds of critical vulnerabilities, you're missing the ones that actually matter. CTEM helps you find the signal in the noise.


"Our compliance framework requires us to patch all critical vulnerabilities within 30 days." Most mature compliance frameworks are moving toward risk-based approaches. And if yours hasn't yet, the conversation about realistic risk is one worth having. Compliance should support security, not undermine it.


"We don't have the tools to do attack path analysis." This is legitimate, but it's changing fast. Modern CTEM platforms are becoming more accessible, and the ROI is significant when you consider the time saved on low-value patching efforts.


"This sounds like an excuse to patch less." Actually, it's a strategy to patch smarter. Teams using CTEM approaches often patch the things that matter faster than traditional programs, precisely because they're not bogged down in low-value work.


What This Means for Your Security Program


Adopting a CTEM mindset requires some significant shifts:


From Reactive to Continuous Traditional vulnerability management is cyclical—scan, patch, repeat. CTEM is continuous. You're constantly monitoring your attack surface, understanding how it changes, and adapting your priorities in real-time.


From Isolated to Contextual Vulnerabilities don't exist in isolation. CTEM requires understanding your entire environment—network topology, access controls, security tool coverage, asset criticality—and how it all connects.


From Compliance-Driven to Risk-Driven The goal shifts from "patch everything critical" to "eliminate realistic attack paths to critical assets." Compliance follows from good security, not the other way around.


From Manual to Automated You can't do this at scale with spreadsheets and manual analysis. CTEM requires automation to map your environment, identify attack paths, and continuously reprioritize as things change.


The Skills Your Team Needs


This shift also requires different skills from your security team. You need people who can:


  • Think like attackers and understand realistic attack scenarios

  • Interpret attack path analysis and make prioritization decisions

  • Communicate risk in business terms, not just technical metrics

  • Work with asset owners to understand what's actually critical to the business

  • Operate CTEM platforms and interpret their output


These are different skills than traditional vulnerability management requires. And that's another reason many organizations struggle with the transition—it's not just about new tools, it's about new ways of thinking.


The Bottom Line


Traditional vulnerability management made sense in a simpler time. But today's threat landscape moves too fast, environments are too complex, and vulnerability volumes are too high for the old approach to work.


You can't patch everything. You never could. The question is: are you patching the things that actually protect your critical assets, or are you just chasing scores?


CTEM gives you a framework to answer that question. It lets you focus your limited time, budget, and political capital on the vulnerabilities that create real risk. It turns vulnerability management from an exhausting treadmill into a strategic security program.


The vulnerabilities that matter aren't the ones with the highest CVSS scores. They're the ones on the path to what you can't afford to lose.


How does your organization prioritize vulnerabilities today? Are you focused on scores, or on real risk? What would it take to make the shift?

Moving from traditional vulnerability management to a risk-based, CTEM approach requires the right strategy, tools, and expertise. At Perceptive Security, we help organizations implement Continuous Threat Exposure Management programs that focus security efforts where they matter most. Let's discuss how to make your vulnerability management program more effective and less exhausting.

Opmerkingen


© 2025 by Perceptive Security. All rights reserved.

Disclaimer: We are independent consultants specializing in the Elastic Stack, including Elasticsearch, Logstash, Kibana, and Elastic Security. Elastic and related marks are trademarks of Elastic N.V. in the U.S. and other countries. This website is not affiliated with, endorsed, or sponsored by Elastic N.V.
bottom of page