For years, the cybersecurity industry has treated vulnerability management like a mathematical problem. Scan the network, find software flaws, rank them by CVSS score, patch the highest numbers first. If you fix all the 9.0 and 10.0 critical vulnerabilities, your network should be secure. Except this approach is broken, and it’s making organizations less secure by misdirecting their efforts.

cover

Attackers do not care about CVSS scores. They do not sort their exploitation tools by severity, nor do they consult compliance dashboards before launching a campaign. They look for the path of least resistance. A ransomware group will often bypass a highly publicized zero-day, preferring to chain together a few low-severity misconfigurations that security teams ignored because they scored a 4.0 on the scanner.

Why does this keep happening? SOCs are drowning in alerts, and compliance mandates force them to chase metrics that look good on a report but offer little real-world protection. Analysts spend their days scanning and patching, trying to close gaps on vulnerabilities that might not even be reachable by an external threat actor, while ignoring the ones that are.

The math behind the illusion

CVSS scores were never designed to measure business risk. The score is a technical calculation of severity: does the vulnerability require authentication? Can it be exploited over the network? Does it need user interaction? But a high technical severity does not mean a high risk to a specific environment. A critical vulnerability on a legacy server, isolated from the internet, heavily firewalled, holding no sensitive data, is a 10.0 on paper but a low priority in practice.

A medium-severity flaw on an internet-facing machine with a direct network path to the domain controller? That’s a catastrophic risk. But scanners lack the context to understand this. They output a list of numbers, and security teams end up patching critical vulnerabilities that no attacker could ever reach, while ignoring lower-scored issues that serve as stepping stones for lateral movement.

The problem compounds with scale. Tens of thousands of new CVEs are assigned every year, and prioritization breaks down fast. Even a team that patches every critical flaw within days of release remains exposed to attackers who exploit the medium and low-severity gaps. A scanner identifies what exists; it takes architectural context to reveal what is actually exploitable, as recent analyses comparing attack path modeling versus traditional scanning have shown.

The patching paradox and operational fatigue

Chasing CVSS scores creates what I call the patching paradox. Companies pour time and money into patching cycles (system downtime, server reboots, frustrated end users) yet still fall victim to breaches. The focus is on the act of patching rather than on actual resilience. When metrics reward the number of patches applied or the speed of remediation, teams close easy tickets instead of addressing systemic risks that require architectural changes.

Operational fatigue follows. IT teams apply emergency patches for every vulnerability that hits the news, regardless of whether the flaw is being exploited in the wild. This reactive posture leaves no time for strategic improvements. When every alert is an emergency, nothing is a priority, and the team burns out chasing an impossible standard.

Some organizations have turned to the CISA Known Exploited Vulnerabilities (KEV) catalog to bridge the gap between theoretical risk and real-world threats. The KEV lists vulnerabilities that threat actors are actively using in ongoing campaigns. A step forward, but still a list-based, reactive approach. It tells you what is dangerous globally, but cannot tell you how an attacker might combine a known vulnerability with a misconfigured administrative feature to compromise your specific network.

Active Directory and the anatomy of a real breach

How do real breaches work? In most ransomware incidents, the initial access involves a known software flaw or a phishing email, but the real damage comes from abusing identities and misconfigurations. Active Directory, the identity backbone of most corporate networks, is rarely compromised through a zero-day. Attackers use features that work exactly as Microsoft intended, but that administrators configured insecurely.

Take Kerberoasting: an attacker requests a service ticket for a specific account and cracks the password offline. There is no CVE for Kerberoasting. There is no patch to apply. It is a feature of the Kerberos protocol. A vulnerability scanner will not flag it, yet it remains one of the most common ways attackers escalate from a compromised user to domain administrator.

Weak SMB signing or misconfigured Active Directory Certificate Services (AD CS) tell the same story. These issues barely register on a vulnerability report, typically at low or informational severity. But attackers build their playbooks around these blind spots, chaining configuration flaws and identity gaps to bypass patched perimeter defenses. Tools like BloodHound map identity relationships and find the shortest path to Domain Admin, ignoring the CVSS scores of every machine along the way. Defending against this means shifting focus from software flaws to identity behaviors and network relationships.

Cloud environments and the new vulnerability landscape

The problem gets worse in the cloud. In AWS, Azure, or Google Cloud, the concept of a vulnerability shifts. Unpatched virtual machines still pose a risk, but the most dangerous flaws are rarely about outdated software. They are about IAM misconfigurations, overly permissive service roles, and exposed storage buckets.

A scanner might give a cloud workload a clean bill of health: fully patched OS, up-to-date dependencies. But if that workload runs with an IAM role that can read every database in the environment, a single application logic flaw leads to a data breach. CVSS struggles to quantify the risk of a misconfigured IAM policy, and these flaws often fall outside the standard remediation workflow.

Cloud services are interconnected, and a minor vulnerability in one component can cascade into a full environment takeover. Attackers exploit trust relationships between services, pivoting from a low-value container to a privileged management console through SSRF attacks or metadata credential extraction. CVSS-driven teams miss these cloud-native vectors because they do not trigger traditional vulnerability alerts. Cloud posture management tools that understand identities and permissions are not optional. They replace the legacy approach of scanning IP addresses for missing patches.

Attack paths over individual scores

The alternative is to stop looking at vulnerabilities as isolated points of failure and start viewing them as links in a chain. Attack path management focuses on how assets, identities, and vulnerabilities connect to create viable routes toward critical data.

Map an attack path with graph theory and the right tools, and individual CVSS scores lose their weight. A critical-severity vulnerability on a dead-end server poses no real threat. But a low-severity flaw on a developer’s workstation that lets an attacker steal a session token, pivot to a cloud environment, and reach customer data: that’s the actual risk. Visualizing these relationships reveals chokepoints: nodes that appear in multiple attack paths.

Fixing a chokepoint delivers more impact than any amount of blind patching. A single configuration change, a revoked permission, one strategic patch: any of these can sever dozens of attack paths at once. This turns vulnerability management from a reactive exercise into a strategic effort to dismantle the infrastructure attackers depend on. The goal becomes making the network hostile to lateral movement, not achieving a clean scan report.

info

Rebuilding security around resilience

Breaking free from the CVSS treadmill requires a cultural shift, starting at the executive level. Leadership must stop measuring success by the number of patches applied or the absence of critical findings on a dashboard. The real metric is resilience: can the network absorb a localized compromise without letting it escalate into a full-scale incident?

This means adopting an assume-breach mentality. An attacker will get past the perimeter, whether through a zero-day, a phishing email, or a compromised supply chain. Once you accept that, the priority becomes limiting what they can do after gaining a foothold: strict network segmentation, least privilege for all identities (human and machine), and continuous monitoring for lateral movement.

No amount of expensive scanners will automate the problem away. As I wrote previously, incident response is a team sport that relies on human context and architectural understanding. Tools must support a strategy that prioritizes business risk over technical metrics. Look beyond the numbers, understand how attacks actually work, and defend what matters, not what the dashboard says.