CVE-Based Attack Surface Management: 2025 Maturity

Actualizado: 2026-05-03

CVE-based attack surface management has changed more in the last three years than in the previous fifteen. Until 2022, most teams lived with a spreadsheet of vulnerabilities, a scanner that refilled it weekly, and an endless discussion about who should patch what. Today that snapshot has mutated: EPSS brings exploitation probability, the KEV catalog flags what is already being used against real companies, and exposure context weighs more than the raw CVSS score. This article covers what has changed, what still hurts, and what a mature practice looks like.

Key takeaways

• CVSS alone measures theoretical severity, not real exploitation probability: using CVSS as the only filter generates thousands of false criticals.
• EPSS (Exploit Prediction Scoring System) assigns daily probability of exploitation within 30 days; filtering by EPSS > 0.1 cuts the critical inventory by 70-80%.
• CISA’s KEV catalog (~1,300 entries) marks CVEs confirmed as actively exploited: absolute urgency, not statistical.
• Exposure context (internet vs. internal network, authentication, WAF) is the multiplier that converts score into real risk.
• SBOMs (SPDX, CycloneDX) allow cross-referencing new CVEs against deployed components in seconds, without waiting for the next scan cycle.

The CVSS-only problem

For years CVSS was the common language to talk about CVE severity. A 9.8 was critical, a 4.3 was medium, and teams tried to close the highest first. The issue is that CVSS measures theoretical severity under ideal exploitation conditions, not real probability or impact in your concrete environment.

A CVSS 9.8 vulnerability requiring local access to an unexposed internal service is vastly less urgent than a CVSS 7.5 with a public exploit circulating against an internet-facing service.

The consequence of using CVSS as the only filter was predictable:

• Thousands of criticals.
• Teams drowning while trying to close everything.
• Real exploitation rate of the inventory that did not match the order the scanner suggested.

Several studies between 2021 and 2023 showed that fewer than 5% of CVEs published each year are exploited in practice, and that base CVSS correlates poorly with that probability.

EPSS as a probability layer

The piece that changed the conversation most is the Exploit Prediction Scoring System (EPSS), maintained by FIRST since 2021 and stabilized around its version 3 by mid-2023. EPSS assigns each CVE a probability between 0 and 1 of being exploited in the next thirty days, based on public signals like:

• GitHub mentions.
• Appearance in exploit databases.
• Scanning traffic.
• Several hundred additional features.

Updates are daily.

The practical effect of looking at EPSS together with CVSS is immediate. In projects I have worked on, filtering by EPSS greater than 0.1 reduces the critical inventory by 70-80% without losing risk realism, and frees the team to handle the rest with breathing room.

The valid criticism of EPSS is that its signals are biased toward what is discussed publicly. A vulnerability exploited by a quiet group against specific targets can stay low-EPSS for a long time. EPSS is a good statistical signal, not an individual guarantee.

CISA’s KEV catalog

The second indispensable piece is CISA’s Known Exploited Vulnerabilities catalog, publishing CVEs confirmed as exploited against organizations since November 2021. It contains around 1,300 cumulative entries with updates several times a week when active campaigns appear.

The usage logic is simple: if a CVE appears in KEV, the case for patching quickly is conclusive. It is not probability, it is evidence of use.

Combining KEV with EPSS and CVSS gives a useful matrix:

This stratification is what I call a mature practice: not a single-score ordered list, but three distinct queues with distinct deadlines.

Exposure context as multiplier

The third component is where most teams still fail: contextualizing the vulnerability in the local environment. An OpenSSL CVE on an internet-exposed server is not the same as the same CVE on an internal service behind three network layers. Traditional scanners weigh both the same, and that distorts prioritization.

The answer is enriching each detected CVE with exposure signals:

• Is the affected asset internet-exposed or only internal?
• Is there additional segmentation?
• Does the service require authentication?
• Does the process run as root or with limited privileges?
• Is there a WAF or bouncer in front?

In one environment I manage, cross-referencing detected CVEs with real exposure dropped the maximum-priority inventory from more than four hundred to around thirty. Not because the others did not exist, but because they lived in contexts where practical impact was minimal.

The role of SBOM

Having SBOMs generated in the build chain, in SPDX or CycloneDX format, allows cross-referencing new CVEs against already-deployed components without rescanning binaries at runtime. The operational benefit is enormous: when a CVE hits a widely used library, a query against the SBOM store answers in seconds which artifacts contain it and at which version, instead of waiting for the next scan cycle.

My recommendation for teams new to this: do not fight about format in the first iteration. SPDX, CycloneDX, JSON, whatever the build chain produces most easily. What matters is having SBOMs for everything deployed and being able to query them fast.

What still hurts

Three problems persist and will not be solved soon:

• Inventory fragmentation. Most large companies have several teams with several scanners and several output formats. Unifying them is a perpetual project; each tooling change implies redoing integration with EPSS, KEV, and SBOMs.
• Window between CVE publication and patch availability. In many open source components, especially those maintained by small teams, weeks can pass between announcement and official patch. During that window, teams are defensive: configuration mitigations, WAF rules, segmentation.
• False-positive noise. Version-based scanners produce wrong alerts when a Linux distribution has backported the patch without changing the public package version.

Conclusion

Mature CVE-based attack surface management runs through three layers: EPSS for probability, KEV for evidence of active use, and exposure context for real impact. Teams that have adopted this practice have fewer critical alerts but handle better the ones that appear. The concrete advice for someone starting: integrate EPSS and KEV first — they are public data, free, and easy to integrate into any existing system. Exposure context and SBOM work comes later, when the first layer already functions.