Use the CISA Known Exploited Vulnerabilities catalog by matching its entries against your component inventory, finding every deployment of the matching components, and fixing exposed ones first. CISA describes the catalog as an authoritative list of vulnerabilities exploited in the wild, meant as an input to prioritisation.
What the catalog gives you
Per CISA, each entry lists the CVE, the date added, a due date and a required action, and the catalog is available as CSV and JSON. The machine readable formats are the useful part: you can pull them on a schedule and join them to your data.
CISA also invites nominations of actively exploited vulnerabilities, so outside reports can feed the list. A flaw not on the list is not proven safe, only not listed.
A weekly routine
- Pull the catalog. Download the JSON file and note entries added since last week.
- Match to components. Compare the vendor and product fields with your component inventory. Matching is imperfect, so expect to review candidates by hand.
- Expand to deployments. For each real match, list artifacts and environments from your inventory.
- Rank by exposure. Internet reachable first, then systems with sensitive data, then the rest.
- Assign and track. One ticket per owning team with the deployment list attached, then verify closure.
Matching pitfalls
| Pitfall | Why it happens | Fix |
|---|---|---|
| Product names differ | Catalog names are vendor style, inventories use package names | Keep an alias list |
| Version ranges unclear | Entry names a product, not always your version | Check the advisory for affected versions |
| Embedded copies | The product is vendored inside another | Use SBOM data to find nested components |
| Appliances | Not in your code inventory | Keep a separate list of third party products |
Why many environments make it harder
The catalog does not know that your payment service runs in three accounts and a data centre. The join to inventory is what turns a public list into a private to do list. If your inventory covers only one environment, matches in the others stay invisible.
Try it yourself
Open the demo and watch how a newly disclosed issue is surfaced and traced to affected projects. Think about what your weekly catalog check would add.
Click through it at your own pace, or open it full screen.
An example of a match
A new entry names a widely used web framework. Your inventory shows three services using it, two of which are internet reachable, plus a vendored copy inside an older tool. Version checks show one service is already on a fixed release. The remaining two services and the vendored copy become tickets, with the exposed ones first.
Quick check
Do private companies have to follow the due dates?
The catalog page states the due dates and required actions per entry; check CISA's directive text for who is bound by them. Whether a due date binds you depends on that text, so check it before quoting it to a customer.
Is a flaw absent from the catalog safe to defer?
Not automatically. It only means CISA has not listed it. Use exposure and reachability as well.
Safeguard's zero-day discovery, reachability analysis and dependency scanning support this routine, and you can run a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
