The KEV exposure metric is the number of open findings in your estate whose CVE appears in CISA's Known Exploited Vulnerabilities catalog, reported with how long each has been open. It is useful to executives because the list is small, evidence based, and tied to real attacker activity, so a rising count is a clear signal.
What the catalog actually is
CISA's Binding Operational Directive 22-01 created the catalog. CISA states that it adds a vulnerability when there is reliable evidence of active exploitation, and that entries also need a clear remediation action such as a vendor update. The directive sets default due dates for US federal agencies: two weeks for most entries, and six months for CVEs assigned before 2021. Those dates bind agencies. Private companies are not bound by them, but many borrow the two week figure as a reference point.
CISA also says that fewer than 4% of known vulnerabilities have been used by attackers in the wild, which is why it argues for treating exploited entries as the top priority. That is the reason this metric stays short even when your total backlog is huge.
How to compute it
- Export your open findings with CVE identifiers and the affected asset.
- Join them against the current KEV catalog, which CISA publishes on its site.
- Count unique CVE and asset pairs, not unique CVEs. One CVE on 40 hosts is 40 exposures.
- Record the day the CVE was added to the catalog and the day you first saw it open.
- Report the count, the oldest item, and the number past your internal target.
Keep the join date explicit. A CVE can join the catalog long after you first found it, so the useful clock for this metric usually starts at the catalog addition date, not the scan date. State your choice on the slide.
What to show executives
| Number | Why it matters |
|---|---|
| Open KEV exposures | The size of the problem |
| Oldest open KEV exposure, in days | The tail that causes incidents |
| Added to the catalog this month, still open | Whether new entries are caught quickly |
| Closed this month | Whether capacity matches inflow |
Avoid showing only a percent. A percent hides the case where one internet-facing system carries the whole risk.
Common mistakes
- Counting CVEs in the catalog that you do not run. Only count what is present and reachable in your assets.
- Treating a mitigation as a fix without noting it. CISA's FAQ notes that actions listed in the catalog are the required response, and that unfixable assets may need to be removed from the network. Track mitigated items separately.
- Ignoring dependencies. Many KEV entries are in products, but libraries appear too. Include software composition results, not only host scans.
Where Safeguard fits
Safeguard can help with the inputs behind this. It runs SBOM and dependency scanning, reachability analysis to separate reachable findings from the rest, and policies and gates that you set. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Click into a finding and look at how severity, exploit status, and fix availability sit next to each other. Those are the columns this metric needs.
Quick check
Do we have to fix KEV items in two weeks?
The two week and six month dates in BOD 22-01 apply to US federal civilian agencies. For other organizations they are a useful reference, and your own policy sets the real target.
Is a CVE not in the catalog safe to ignore?
No. The catalog lists confirmed exploitation, not all risk. A vulnerability can matter before it is listed, so keep it in your normal prioritization.
Sources
Last reviewed: 19 October 2026.
