Published 2026-04-28 — v1.1

KEV matching methodology

CipherCue cross-references observed vendor and product fingerprints against the CISA Known Exploited Vulnerabilities (KEV) catalogue. This page specifies how the match is performed, the version-required rule introduced in v1.1, how vendor-level KEV history is surfaced separately, and what a customer sees in each case.

Source

CISA Known Exploited Vulnerabilities catalogue: cisa.gov/known-exploited-vulnerabilities-catalog. CipherCue ingests the published JSON feed. Every match CipherCue records carries:

• cve_id
• vendor and product (as listed by CISA)
• kev_date_added — the date the entry was added to the CISA catalogue
• known_ransomware_use — the flag as set by CISA
• authority_source = "CISA KEV", authority_url = the catalogue entry
• detected_version — the version string observed on the entity component (required as of v1.1)

Matching rule (v1.1)

A kev_match fact is written when all three of the following hold:

1. An observed component on the entity has a non-empty detected_version.
2. The component's lowercased (vendor, product) equals — directly or via the published alias map — the lowercased (vendor, product) of a CISA KEV entry.
3. The component is from a host the entity is publicly identified with (apex, listed website, or canonical subdomain).

v1.1 deliberately suppresses the version-less match case. Modern web stacks frequently strip version banners (CDN-fronted origins, managed SaaS, hardened load balancers). Without a version, the vendor+product equality alone produces matches that are technically correct ("we did observe vendor X; KEV does list vendor X") but practically unsafe — they would surface very old CVEs against entities running modern releases of the same vendor's software.

Why version-required

1. KEV entries do not publish structured affected-version ranges, but a customer can verify a match against their own deployment far more reliably when CipherCue publishes which version it observed.
2. Vendor+product-only matches against version-less observations were producing implausible matches to CVEs with disclosure dates earlier than the entity's likely deployment.
3. The version-less signal is still valuable in aggregate — see "Vendor KEV history" below — but it is not an assertion-grade per-CVE match.

Vendor KEV history (introduced v1.1)

Where v1.0 conflated "vendor present in KEV" with "this entity has a CVE match", v1.1 separates the two. Vendor-level KEV history is computed on demand from the same CISA catalogue and surfaced alongside each observed component as plain context — not as a match.

For each observed (vendor, product) pair, CipherCue counts CISA KEV entries against that pair within the last 365 days and records the date of the most recent entry. The user-facing string reads, for example:

CISA KEV catalogue: vendor has 3 entries in last 12 months, most recent 2026-02-14. cisa.gov/kev →

This is a factual statement about the catalogue, not a vulnerability claim about the observed entity. It is computed from the CISA feed at request time and is not stored as an EntityFact.

Vendor alias handling

Vendor names drift between CISA, fingerprint-rule catalogues, and the vendor's own marketing. CipherCue maintains a hand-curated alias map (config/ciphercue/vendor_aliases.php in the open codebase). Aliases are additive — removing one would be a methodology change and would require a version bump.

What the customer sees

Per-CVE match (when version is observed):

Matches CISA KEV #CVE-2024-21887, added 2024-01-10. Vendor: Ivanti. Product: Connect Secure. Detected version: 22.4. Source: cisa.gov/kev entry for CVE-2024-21887.

Vendor KEV history (always, when the vendor appears in KEV — independent of version observation):

CISA KEV catalogue: vendor has 14 entries in last 12 months, most recent 2026-04-12. Source: cisa.gov/kev.

Pre-disclosure handling

New per-CVE matches are held silent for 48 hours per /disclosure-policy. Vendor KEV history is a derived view over public catalogue data and is not subject to the disclosure window — no per-entity claim is being made.

Correction

If a match or vendor history line is spurious (e.g. vendor alias mis-mapped, detected product is not a deployed instance, false-positive fingerprint), email corrections@ciphercue.com. We investigate within 7 days.

Changelog
v1.1 — 2026-04-28 — Require non-empty detected_version for kev_match facts. Introduce vendor KEV history as a separately-computed context view. Earlier vendor+product-only matches written under v1.0 are retained in the historical record but no longer produced; they are flagged in customer-facing surfaces as "v1.0 method".
v1.0 — Initial publication. Vendor+product matching; version-range matching deferred.