Why CVSS alone produces the wrong queue
Most vulnerability backlogs are sorted by CVSS base score, and most teams know the result: a long list of 9.8s, many of which may never be attacked, and no signal for which three to fix this week. That is not a misuse of CVSS so much as asking it a question it was not designed to answer. The CVSS v4.0 specification is explicit that the base score describes the intrinsic severity of a vulnerability, and that consumers should enrich it with threat and environmental information "to produce a score that provides a more comprehensive input to risk assessment."
Two things are missing from a base score: whether exploitation is actually happening, and whether the vulnerable thing is reachable by an attacker. KEV and EPSS answer the first. Your external attack surface answers the second.
CISA KEV: exploitation that has been observed
The Known Exploited Vulnerabilities catalog is maintained by the US Cybersecurity and Infrastructure Security Agency. A CVE is added when three conditions hold: it has a CVE ID, there is reliable evidence it has been actively exploited in the wild, and there is a clear remediation action such as a vendor update. That third criterion matters in practice: every KEV entry comes with something you can do about it.
KEV started as a federal patching mandate and remains one. In June 2026 CISA issued BOD 26-04, "Prioritizing Security Updates Based on Risk", which revoked BOD 22-01 and BOD 19-02, carried the KEV criteria forward, and set remediation urgency for federal agencies from four factors: whether the asset is publicly exposed, whether the CVE is on KEV, whether exploitation can be automated, and the technical impact. You are probably not a federal agency, but the model transfers well: exposure and known exploitation are the first two questions for anyone.
What KEV is not: a complete list of exploited vulnerabilities. It is conservative by design (evidence plus a fix), so absence from KEV is not evidence of safety.
EPSS: exploitation that is likely
The Exploit Prediction Scoring System is published by FIRST, the same organization that maintains CVSS. For every published CVE it gives a probability, between 0 and 1, that the vulnerability will be exploited in the wild in the next 30 days, recomputed daily.
EPSS is useful precisely where KEV is silent: new CVEs that have not yet accumulated the evidence KEV requires, and older CVEs that were never added. FIRST is also clear about its limits. EPSS "does not measure how much damage successful exploitation would cause, or whether it affects your environment", and FIRST warns that multiplying EPSS by a CVSS score "is never a good idea", because one is a calibrated probability and the other an ordinal expert judgment. Use them side by side, not blended into one number.
A practical order for internet-facing hosts
- Exposed and on KEV. Someone is exploiting this, and your copy is reachable from the internet. Treat it as an incident-grade change: patch or mitigate now, and check the host for signs it was already hit, since exploitation may have started before you patched (BOD 26-04 pairs some of its remediation timelines with forensic triage for this reason).
- Exposed with high EPSS. Not yet confirmed as exploited, but the model says it is likely soon. Schedule it this week.
- Exposed, end-of-life software. There may be no CVE today, but the next one will not be fixed. Plan the upgrade.
- Everything else by CVSS, with backlog hygiene: accept the risk with a review date where a fix is already in place, rather than letting the list grow.
If you are writing this into policy, the free vulnerability management policy generator produces a starting document with remediation timelines you can adapt.
How external CVE matching works
An external scanner does not log in and does not run an agent, so it can only work from what a
host tells the internet about itself. In Attack Surface Scan that evidence is the
Server and X-Powered-By headers, the page's generator meta tag,
versioned script and stylesheet URLs, the greeting that services such as SSH, FTP and SMTP send on
connect, and a few ordinary requests to open admin web ports. Detected software is normalized to
a curated catalog of 45 products, from web servers and mail servers to VPN appliances and
front-end JavaScript libraries.
Those product and version pairs are matched against the affected-version ranges in the
NVD CVE API 2.0, plus the retire.js repository for JavaScript libraries.
Base severity follows CVSS, then is raised one step when the CVE is on KEV or
its EPSS score is 0.5 or higher. Each finding is tagged CISA-KEV,
EPSS:<score> and CWE-<n>, so the KEV-first queue above
is one filter away in the app, the CSV export, or the REST API
(GET /v1/findings?kev=true on Growth and above).
KEV and EPSS are refreshed nightly. That is the part that makes continuous monitoring different from a quarterly scan: when CISA adds a CVE tonight, the next scan of any host already running the affected version raises it, and because a new KEV match is a critical change, it goes to your alert channels immediately rather than into a weekly digest. The full rules are on Vulnerability matching.
Potential matches: when the version is hidden
Hiding version banners is common advice, and it does make a host a less obvious target. It also means a scanner cannot confirm which CVEs apply. The honest options are to say nothing, or to say something narrow.
Attack Surface Scan does the narrow thing. When a product is detected without a version,
potential findings are raised only for internet-edge products where exploitation
is common (GitLab, Confluence, FortiOS, NetScaler, Ivanti, GlobalProtect and Exchange), only for
CVEs on the KEV catalog, at most 10 per product, capped at medium severity and tagged
potential. Each one explains how to check the real version. The logic: if you run a
VPN appliance on the internet and a KEV entry exists for that product line, you want to be told
to go and check, even when the banner is silent.
Backports, Exchange and other traps
- Distribution backports. Linux distributions often patch a CVE without changing the upstream version string. When a version looks like a distribution package, the finding carries a backport warning. Severity is not lowered automatically: confirm against the distribution's security tracker, then accept the risk with a note and a review date.
- Exchange and ASP.NET. Their public version strings do not identify the patch level, so only presence is reported.
- Volume. Old software can match hundreds of CVEs. At most 25 are raised per product, highest risk first (exploited, then severity, then EPSS); the rest are counted in the evidence so nothing is silently dropped.
What an external scan cannot see
Being precise about this is what keeps a KEV-first queue trustworthy:
- Matches, not exploits. Nothing is exploited or payload-tested. A finding means the announced product and version is in a vulnerable range.
- Hidden or rewritten versions. Software that suppresses its version, or sits behind a proxy that rewrites headers, is invisible beyond the potential-match rules above.
- Anything behind a login, and anything not internet-facing. Internal servers, endpoints and authenticated application paths need an authenticated scanner or agent.
- Only hosts you have verified. We do not sweep IP ranges; matching runs on hosts under domains you have proven you control, including subdomains discovery finds.
External matching complements authenticated vulnerability scanning and penetration testing. What it adds is the exposure half of the equation: a KEV-listed version on a host the whole internet can reach, found the night the catalog changes.
Frequently asked questions
What is the difference between CISA KEV and EPSS?
KEV is a list of CVEs with reliable evidence of exploitation in the wild and a clear remediation, maintained by CISA. EPSS is a daily probability, from FIRST, that a CVE will be exploited in the next 30 days. KEV tells you what is being exploited; EPSS estimates what is likely to be. Use KEV first, then EPSS, then CVSS.
Should I multiply EPSS by CVSS to get a risk score?
No. FIRST's own guidance says multiplying EPSS by a CVSS score is never a good idea, because EPSS is a calibrated probability and CVSS base is an ordinal ranking. Keep them as separate inputs and sort by exploitation evidence first.
Can an external scanner confirm a CVE is exploitable on my host?
Not a passive one. It matches the product and version a host announces against published affected ranges. Backported fixes, hidden versions and compensating controls can all make a match inaccurate, which is why findings should be confirmed against the vendor or distribution advisory before being closed or accepted.
How quickly does a newly added KEV entry show up?
In Attack Surface Scan, KEV and EPSS data are refreshed nightly, and the next scan of a host running an affected version raises the match. Scheduled scans run weekly on Starter and daily on Growth and above, and a new KEV match is sent to alert channels immediately.