Beyond CVSS: Why Exploitability-Aware Vulnerability Scanning Is the Only Kind That Matters
Your scanner finds thousands of vulnerabilities, but your team can fix only a fraction each month. Exploitability-aware scanning combines severity, EPSS probability, KEV status, and business context to surface the findings that can actually lead to a breach.
Beyond CVSS: Why Exploitability-Aware Vulnerability Scanning Is the Only Kind That Matters
TL;DR
In 2024, more than 40,000 new CVEs were added, roughly 135 per day, while most teams can remediate only 10–15% of their backlog per month. Only 2.3% of vulnerabilities scored CVSS 7 or above see actual exploitation attempts, and 28% of exploited CVEs carry scores most organizations would not consider urgent. Exploitability-aware scanning combines severity, EPSS probability, KEV status, and business context to surface the findings that can actually lead to a breach. It also covers the full stack, runs continuously, and closes the loop with remediation guidance, ticketing, and verification.
What this is
Exploitability-aware vulnerability scanning is a prioritization model that enriches every finding with data beyond the CVSS base score. It asks whether a vulnerability is listed in CISA's Known Exploited Vulnerabilities (KEV) catalog, what its EPSS score predicts for exploitation within 30 days, whether a public exploit exists, what asset is affected, and whether compensating controls reduce the risk. The result is a patch queue ordered by real-world exploitability and business impact rather than theoretical severity alone.
Why it matters
The vulnerability scanning problem in 2026 is not detection. Modern scanners are excellent at finding things. The problem is that they find too many things, rank them by the wrong criteria, and leave overwhelmed teams to sort out what actually matters. The volume of disclosed vulnerabilities has been growing at roughly 40% year over year, and there is no sign of that curve flattening. Traditional vulnerability management was designed for a world where a team might track a few hundred CVEs per quarter against a relatively stable set of internal servers. That world no longer exists. Today's security teams manage hybrid infrastructure that spans on-premises data centers, multiple cloud providers, web applications, APIs, databases, employee endpoints, and third-party integrations, all of which generate a continuous stream of findings. The result is vulnerability overload, a state where the sheer volume of findings exceeds remediation capacity so dramatically that prioritization becomes the entire game. You cannot patch everything. You cannot even investigate everything. The only question that matters is whether you are patching the right things.
How it works
CVSS has been the default language of vulnerability prioritization for over a decade. It assigns a numeric severity score from 0 to 10 based on a vulnerability's technical characteristics: attack vector, complexity, required privileges, and potential impact. Scores of 9.0 or higher are labeled critical, and scores between 7.0 and 8.9 are high. The problem is that CVSS measures theoretical severity under idealized conditions. It does not know whether the vulnerability exists in your environment, whether compensating controls such as firewall rules, network segmentation, EDR, or WAF already block the exploit path, or whether anyone is actually exploiting it in the wild. FIRST, the organization that maintains CVSS, explicitly states that base scores alone should not be used for prioritization. Yet that is exactly what most teams do, because it is the number their scanner produces and the number their compliance framework expects. The consequences are predictable. Teams spend limited remediation capacity on high-CVSS vulnerabilities that no attacker is targeting, while lower-scored but actively exploited flaws remain unpatched. CVE-2023-48795, a vulnerability in SSH implementations, carries a CVSS score of only 5.9, medium, yet its EPSS score indicated a high probability of real-world exploitation. Organizations that prioritized solely by CVSS would have treated it as a low-priority item.
EPSS, the Exploit Prediction Scoring System, also maintained by FIRST, predicts how likely a vulnerability is to be exploited in the real world within the next 30 days. It uses a machine learning model trained on observed exploit activity, threat intelligence feeds, and contextual data to produce a probability score between 0 and 1. A score of 0.85 means there is an 85% chance this vulnerability will see active exploitation within the month. A score of 0.02 means there is a 2% chance. But EPSS predicts global exploitation trends, not whether the exploit is relevant to your specific environment, whether your controls mitigate it, or whether the vulnerable asset is critical to your business. An EPSS score of 0.90 for a vulnerability that only affects software you do not run is still irrelevant to you. The right approach is both scores plus environmental context: severity, exploitability, asset criticality, compensating controls, and business impact combined into a unified prioritization model.
An exploitability-aware scanner does three things traditional scanners do not. It covers the full stack. Network security means scanning for open ports, unpatched services, weak protocols, and misconfigured network devices. Web application security means testing for OWASP Top 10 vulnerabilities such as SQL injection, cross-site scripting, authentication flaws, and insecure deserialization, as well as application-specific logic bugs that automated scans often miss. Authenticated scanning tests the application from the perspective of a logged-in user and catches vulnerabilities that unauthenticated scans never see. Cloud security means scanning AWS, Azure, and GCP configurations for misconfigurations, overly permissive IAM policies, public storage buckets, insecure defaults, and compliance gaps, and it must be continuous because cloud environments change constantly. Database security means checking for default credentials, misconfigured access controls, unencrypted connections, and overly broad permissions. Endpoint security means scanning employee devices for OS-level vulnerabilities, outdated software, missing patches, and configuration drift that creates entry points for lateral movement.
It prioritizes by exploitability and business context. An exploitability-aware scanner enriches every finding with data that drives real prioritization decisions: KEV listing, EPSS score, whether a public exploit exists and how reliable it is, how critical the affected asset is, and whether compensating controls are in place. This transforms a generic finding like "CVE-2023-27997, CVSS 9.8, Fortinet FortiOS" into a contextualized decision: "CVE-2023-27997 on your internet-facing VPN gateway, KEV-listed, EPSS 0.89, no compensating controls detected, affects production authentication, remediate immediately." The first version goes into a backlog. The second version gets fixed today.
It operates continuously, not periodically. Traditional vulnerability scanning happens on a schedule: weekly, monthly, or quarterly. Between scans, your environment changes. New services deploy, configurations shift, and new CVEs are disclosed and weaponized within hours. A scanner that runs once a month is operating on a cycle fundamentally mismatched with the speed at which both environments and threats evolve. If a new critical vulnerability is published on a Tuesday and your next scan runs the following Monday, you have given attackers a six-day head start. Always-on scanning means scans run daily at minimum, with additional checks triggered automatically when asset changes are detected, such as a new deployment, a configuration modification, or a certificate approaching expiration.
Detection and response
The hypothesis is that a finding with a high CVSS score but no exploitation activity is less urgent than a lower-scored finding that is actively exploited, and the evidence that confirms or rejects it comes from enrichment data attached to each finding: KEV catalog membership, EPSS probability, public exploit availability, asset criticality, and compensating controls. The two images below show the prioritization signals and the resulting patch queue.
What to do
- Stop sorting by CVSS score alone. Use CVSS as one input, not the ranking criterion, because FIRST explicitly states that base scores alone should not be used for prioritization.
- Enrich every finding with EPSS probability, KEV status, public exploit availability, asset criticality, and compensating controls.
- Cover the full stack: network, web applications, APIs, cloud accounts, databases, and endpoints, including authenticated scanning for web applications.
- Scan continuously. Run scans daily at minimum and trigger additional checks automatically when asset changes are detected.
- Attach actionable remediation guidance to every finding, with specific steps and target versions rather than a link to the CVE advisory.
- Integrate ticketing so findings above a defined severity threshold automatically generate tickets in Jira, ServiceNow, Slack, Teams, or email, with vulnerability details, affected asset, risk score, evidence, and remediation steps included.
- Verify every fix with automated re-testing. Re-scan the affected asset after remediation to confirm the vulnerability no longer exists.
- Measure mean time to remediate by severity tier, remediation rate against SLA, scan coverage of known and unknown assets, false positive rate, and risk reduction over time.
FAQ
Why is CVSS alone not enough for prioritization?
CVSS measures theoretical severity under idealized conditions. It does not know whether the vulnerability exists in your environment, whether compensating controls already block the exploit path, or whether anyone is exploiting it in the wild. FIRST, which maintains CVSS, explicitly states that base scores alone should not be used for prioritization.
What does EPSS add?
EPSS predicts how likely a vulnerability is to be exploited in the real world within the next 30 days, producing a probability between 0 and 1. A score of 0.85 means an 85% chance of active exploitation within the month. It predicts global trends, so it still needs environmental context to be actionable for your organization.
What is the KEV catalog?
CISA's Known Exploited Vulnerabilities catalog lists vulnerabilities with confirmed in-the-wild exploitation. Membership in KEV is one of the enrichment signals that turns a generic finding into an urgent one.
How often should scanning run?
Daily at minimum, with additional checks triggered automatically when asset changes are detected, such as a new deployment, a configuration modification, or a certificate approaching expiration. A monthly scan cycle gives attackers a head start of days or weeks.
What metrics show whether a vulnerability management program is working?
Mean time to remediate by severity tier, remediation rate against SLA, scan coverage of known and unknown assets, false positive rate, and risk reduction over time, including open critical and high findings and average exposure window.
Why does remediation verification matter?
Without automated re-testing, "fixed" is an assumption. With it, "fixed" is a fact backed by evidence. Re-scanning the affected asset after remediation confirms the vulnerability no longer exists and prevents it from reappearing in the next scan.