A count of your open vulnerabilities that appear on a known exploited list is one of the sharper security metrics, because each item has evidence of real exploitation. It does not measure total risk, unknown flaws or unlisted exploitation. Report it with time open, asset exposure and a defined response window.
What the list is
CISA maintains the Known Exploited Vulnerabilities Catalog and describes it as an authoritative source of vulnerabilities that have been exploited in the wild, intended to help organisations manage vulnerabilities and keep pace with threat activity. The catalog page lets you filter by date added, vendor and CVE, and shows due dates.
Because membership implies observed exploitation, a match changes how a finding should be treated compared with an equally scored one with no such evidence.
Why it works as a metric
- Clear definition. An item is on the list or it is not.
- Hard to argue. Severity labels can be debated. Evidence of exploitation is harder to dispute.
- Small and actionable. The number is usually far smaller than the full backlog, which makes a response window realistic.
- Hard to game cheaply. Reclassifying severity does not remove an item from the list.
What it does not tell you
| Limit | Meaning |
|---|---|
| Lagging evidence | A flaw can be exploited before it is listed |
| Coverage of the list | It is not every exploited vulnerability anywhere |
| Your own code | Custom flaws never appear |
| Context | Listed does not mean exposed in your environment |
| Zero is not safe | An empty count says nothing about unlisted risk |
So treat it as a priority signal. It does not summarise your posture.
What to report
- Count of open items on the list, by asset exposure: internet facing or internal.
- Age of the oldest listed item still open.
- Share closed within the window you set.
- Count of items with an exception, with owner and expiry.
- Time from listing to detection in your environment, which shows how fast your inventory sees new entries.
The last item is underused. It measures your visibility more than your patching.
Steps to operationalise
- Pull the catalog on a schedule and match entries to your inventory of packages and products.
- Add the match as a field on findings, with the date added.
- Set a response window that is shorter for exposed assets.
- Alert owners on a new match, not on a weekly digest.
- Track exceptions to expiry.
Match accuracy depends on inventory quality. If you cannot list what you run, the count understates exposure. Asset discovery and an SBOM raise confidence in the match.
Pairing with other signals
Combine with exploitation probability scores and reachability. A listed item that is not reachable in your application, or not deployed, may deserve a different action than one that is live and exposed. Record that reasoning with evidence.
Safeguard offers SBOM and dependency scanning, reachability analysis and policy gates. You can run a free scan at gold.safeguard.sh/scan.
Quick check
Does zero known exploited items mean we are safe?
No. It means none of your known assets match the list. Unlisted and custom flaws are outside it.
How fast should we respond to a match?
Set a written window, shorter for internet facing assets, and track performance against it.
Sources
Last reviewed: 19 October 2026.
