How Vexta's CISA KEV Coverage Tracker Works

Vexta's CISA KEV coverage tracker is a dashboard widget that shows what percentage of the CISA Known Exploited Vulnerabilities catalog Vexta currently has a way to detect. CISA KEV is the U.S. Cybersecurity and Infrastructure Security Agency's list of vulnerabilities confirmed to have been exploited in the wild; Vexta, VITI Security's agentless, AI-augmented vulnerability scanner and pentest platform, keeps a widget at the top of the dashboard tracking its own coverage of that list so a hunter never has to wonder whether a scan even had a chance of catching a given KEV entry.

What counts as coverage for a KEV entry?

Vexta counts a CVE from the KEV catalog as covered when any one of four conditions is true. First, a bundled or on-disk Nuclei-style template exists that fires specifically for that CVE. Second, one of Vexta's built-in detectors hard-codes that exact CVE ID as something it checks for. Third, the CVE has a CPE-match row, meaning NVD (the National Vulnerability Database) has mapped it to a specific vendor and product, and Vexta's asset enricher is able to fingerprint that matching vendor or product on the target. Fourth, and this is the one that closes a real gap, the KEV catalog entry itself always carries a vendorProject and product field, so even when NVD's own data hasn't caught up yet, Vexta's asset enricher can still fire against any matching technology fingerprint using the KEV catalog's own vendor and product fields.

That fourth path exists because NVD's public API is known to lag or go quiet at times, which used to leave customers looking at a coverage widget that read as blank or stale until NVD's data caught back up. Since the KEV catalog itself always populates vendor and product information regardless of NVD's state, Vexta can keep the coverage number current even during an NVD outage.

The distinction between these four coverage paths also tells you something about depth versus breadth. A CVE covered through a bundled template targeting one exact vulnerability, or a hard-coded detector, generally means Vexta can confirm that exact CVE with a fairly specific check. Coverage through the CPE-match or vendor and product paths means Vexta can recognize the technology involved and flag exposure through its broader detector set, which is a slightly different kind of coverage than a purpose-built check for that one CVE ID. Both count toward the widget's percentage, but knowing which path applies to a given entry is useful context when you're deciding how much confidence to put in a specific KEV result.

How current is the number on the widget?

The KEV catalog auto-syncs daily, and the coverage widget invalidates its cache on every sync, so the percentage you see reflects the catalog as of the most recent daily pull rather than a stale snapshot from install day. CISA's KEV feed is served behind a CDN that occasionally returns a 403 to requests that don't look like they're coming from a browser, which is a known annoyance for any tool that tries to pull the feed automatically. Vexta works around that with a fall-through mirror list: it tries the CISA source first, falls back to a GitHub mirror of the same catalog if that fails, and sends browser-shaped request headers on both to avoid tripping the CDN's bot filtering.

The practical effect is that the widget's number should track the real KEV catalog closely, without a hunter needing to manually check whether today's sync actually completed or silently failed against a flaky upstream.

Why coverage against KEV matters more than coverage against CVE volume alone

There are tens of thousands of published CVEs and only a few thousand entries in the KEV catalog, but that smaller list represents vulnerabilities CISA has confirmed are being actively exploited, not just theoretically exploitable. A scanner's raw CVE template count is a much less useful number on its own; what a hunter or a security lead actually wants to know is whether the tool in front of them can catch the specific bugs attackers are currently using. The KEV coverage tracker exists to answer exactly that question at a glance, rather than asking you to cross-reference a template list against CISA's feed by hand.

This also plugs into Vexta's broader risk scoring. CISA KEV status is one of the six inputs to the Vexta Confidence Score, alongside severity, detector confidence, proof status, reachability, and EPSS probability (EPSS, the Exploit Prediction Scoring System, estimates the probability a vulnerability will be exploited). A known-exploited CVE gets a 1.5x multiplier in that formula, so a finding tied to a KEV entry surfaces higher in a findings list sorted by confidence score, on top of just being flagged as covered on the dashboard widget.

Using the tracker in practice

For a hunter working an engagement where the client or program cares specifically about exposure to actively exploited vulnerabilities, the KEV coverage widget is a fast way to sanity-check the toolset before committing scan time to a target. If coverage is high for the technology stack in play, a KEV-focused pass is worth prioritizing. If a particular vendor or product isn't well represented yet, that's useful to know going in rather than discovering it after the report is already written.

It's also a fair question to ask about any scanner, not just Vexta: how much of the actively-exploited landscape does it actually check for, and how does that number stay current when upstream data sources aren't reliable. The mirror fallback and vendor and product fallback path exist specifically so the answer to that second half doesn't depend on NVD's API being in a good mood that day.

Key takeaways