VERA Vendor Risk Signals Library

CISA KEV in Vendor Assessment

The CISA Known Exploited Vulnerabilities Catalog helps distinguish vulnerabilities that are theoretically serious from vulnerabilities that have actually been exploited in the wild. In a vendor assessment, that distinction can materially change how an externally exposed vulnerability should be prioritized.

What is the CISA KEV Catalog?

The Known Exploited Vulnerabilities Catalog, commonly called CISA KEV, is maintained by the U.S. Cybersecurity and Infrastructure Security Agency as an authoritative source of vulnerabilities known to have been exploited in the wild. CISA recommends that organizations use the catalog as an input to vulnerability-management prioritization.

Each KEV entry identifies a specific CVE that meets CISA’s criteria for known exploitation. The catalog also includes information such as the affected vendor or product, the date the vulnerability was added, required remediation action, and a due date used for applicable federal remediation requirements.

The important distinction is simple:

A CVE identifies a known vulnerability. A KEV match adds evidence that attackers have actually exploited that vulnerability.

That does not mean every system affected by that CVE has been compromised. It does mean the vulnerability deserves additional attention.

Why does CISA KEV matter in vendor risk?

Vendor assessments can surface a large number of potential vulnerabilities.

Treating every CVE as equally important quickly creates noise.

A vulnerability may have a high severity score but limited evidence of real-world exploitation. Another vulnerability may have a similar or even lower score while already being actively used by attackers.

KEV helps add that missing context.

CISA explicitly recommends using the KEV Catalog as an input to vulnerability-management prioritization and strongly encourages organizations to address KEV vulnerabilities as part of their vulnerability-management programs.

From a third-party risk perspective, this means a vendor exposing technology associated with a KEV-listed vulnerability may deserve more immediate review than a vendor with a larger number of lower-priority CVEs.

For example:

Vendor A: 20 potentially applicable CVEs, none known to be exploited.

Vendor B: 3 potentially applicable CVEs, one listed in CISA KEV.

The vulnerability count alone would make Vendor A look worse.

The KEV information may make Vendor B the more urgent assessment target.

What can VERA observe?

VERA can correlate externally observable technologies and vulnerability evidence with the CISA KEV Catalog.

Depending on the available evidence, VERA can identify:

externally reachable services or technologies;
product or version information that can be established from external evidence;
CVEs associated with the observed technology;
whether an identified CVE appears in the current CISA KEV Catalog;
the date the vulnerability was added to KEV;
CISA’s required remediation action;
relevant remediation or due-date information published with the KEV entry; and
other vulnerability or exposure signals associated with the same internet-facing asset.

The key word is correlate.

Finding a KEV-listed CVE in vulnerability intelligence does not automatically prove that a vendor is running the vulnerable version of the affected software.

VERA must first have evidence connecting the vendor’s externally observable infrastructure to the relevant technology or vulnerability.

The more useful question is:

“How strong is the evidence that this vendor has an externally reachable system associated with a vulnerability known to be exploited?”

What does this signal not prove?

A KEV match does not prove that the vendor has been compromised.

It also does not prove that:

attackers have exploited the vulnerability in the vendor’s environment;
the identified system is definitely running the vulnerable version;
the vulnerability remains unpatched;
the exposed service is exploitable from the internet;
compensating controls are absent;
the affected system contains sensitive information; or
the vendor has a weak cybersecurity program overall.

There is an important chain of evidence involved:

Observed technology → applicable vulnerability → known exploitation

Confidence in each step matters.

An externally visible service may expose enough information to identify a product but not its exact patch level. A CVE may apply only to particular versions or configurations. Network controls or compensating protections may also affect exploitability.

For that reason, “technology associated with a KEV vulnerability” and “confirmed exploitable KEV vulnerability” should not be treated as equivalent statements.

Likewise, absence from the KEV Catalog does not mean a vulnerability is harmless.

KEV identifies vulnerabilities with evidence of known exploitation. It is a prioritization signal, not a complete list of vulnerabilities that could be exploited.

How VERA uses this signal

VERA uses CISA KEV as a prioritization and context signal within its broader vulnerability-exposure analysis.

An externally observable CVE can become more significant when there is credible evidence that the vulnerability has been exploited in real-world attacks.

VERA therefore evaluates the relationship between:

external exposure + technology identification + CVE applicability + known exploitation

rather than relying on CVE counts or severity scores alone.

A KEV match may increase the importance of a finding, but the strength of the conclusion still depends on the evidence connecting the vulnerability to the vendor’s observable environment.

This reflects VERA’s broader approach to vendor risk:

prioritize evidence that changes the decision, while preserving the difference between what is observed, what is inferred, and what has actually been proven.

Related Vendor Risk Signals

No single external signal tells the whole story. These related signals can provide additional context when evaluating this finding as part of a broader third-party risk assessment.