Use the CISA Known Exploited Vulnerabilities flag as a boolean plus a date: whether a vulnerability is listed and when it was added. It signals exploitation in the wild, not exposure in your environment, so combine it with asset data and track how quickly your own data picks up new entries.
What the catalog provides
CISA describes the catalog as the authoritative source of vulnerabilities that have been exploited in the wild, and it offers a nomination form for ones not yet listed. Entries show a Date Added, a Due Date for remediation, and a field stating whether the vulnerability is known to be used in ransomware campaigns, with values such as Unknown. The page also links a JSON feed and schema. Check the feed documentation for exact field names before building an import.
Fields to store
- A KEV flag, true or false.
- The date added to the catalog.
- The catalog's due date, if you want to display it.
- The ransomware use field, as given.
- The time your system last synchronised the catalog.
Store the date added as a date, and keep your own first seen date as well, so you can compute how quickly you reacted.
Two lags to measure
| Lag | Definition | What it reveals |
|---|---|---|
| Intake lag | Catalog date added to the day your dashboard flagged it | Health of your data sync |
| Response lag | Day flagged to day fixed or mitigated | Engineering and triage speed |
Intake lag should be small and steady. If you sync weekly, a vulnerability can be exploited and listed several days before it is flagged in your tool. Sync daily at least, and show the sync time on the dashboard.
Pitfalls
- Treating KEV as exposure. A listing says exploitation was seen somewhere. It does not say you run the affected product in a reachable way. Pair the flag with asset and version evidence.
- Treating absence as safety. Not being listed does not mean not exploited. The catalog has a defined scope and process.
- Cached lists. An offline copy of the catalog goes stale silently. Record the synchronisation time.
- Matching errors. The match between a catalog entry and your asset depends on the quality of your component data, so check a few matches by hand.
Using the flag in policy
A common design is a stricter handling rule for items on the catalog, with a shorter target than for other findings of the same severity. Whatever you choose, write the target down and measure compliance with it. Avoid saying that any outside rule requires your targets, unless you have read the specific obligations that apply to you.
Audit step
Pick five entries added to the catalog in the last month. Check whether each appears flagged in your data, on what date, and whether any affected assets were identified. Gaps tell you where the pipeline needs work.
Safeguard does this kind of counting in one place: SBOM and dependency scanning, asset discovery and reachability analysis feed the same inventory, so each number can be traced back to its source. The exploitability check demo shows how exploit evidence and reachability combine into one decision. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Open the demo and follow one finding from detection to resolution, noting which number on screen changes and which stays put.
Click through it at your own pace, or open it full screen.
Quick check
Does a KEV listing mean I am vulnerable?
No. It means exploitation in the wild was observed. You are exposed only if an affected product and version run in your environment in a reachable way.
How often should the catalog sync?
At least daily, and show the last sync time so readers know how current the flag is.
Sources
Last reviewed: 19 October 2026.
