Published 2026-04-28 — v1.0

KEV matching methodology

CipherCue cross-references observed vendor and product fingerprints against the CISA Known Exploited Vulnerabilities (KEV) catalogue. This page specifies exactly how that match is performed, why we operate a conservative matching rule, and what a customer sees when a match is recorded.

A CISA KEV match is not an assertion that the observed organisation has been compromised or will be. It is a record that (a) CipherCue observed a product matching a vendor and product listed in the CISA KEV catalogue, and (b) CISA has catalogued a known-exploited vulnerability against that vendor and product.

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

Matching rule (v1)

v1 of the matcher matches on (vendor, product) only. CipherCue does not yet compare the detected product version against the affected-versions range of the KEV entry.

Why conservative

KEV entries do not publish structured affected-version ranges — the affected-versions field is free-form prose that does not machine-compare reliably across vendors.
Observed versions from external fingerprinting are often incomplete (e.g. a CDN masks the origin version string).
A false negative from version-strict matching is worse than a false positive from vendor/product matching: the customer can quickly verify by checking their own version; the false-negative case hides a real catalogue hit.

We publish the detected version alongside the match so the customer can perform their own version check against the CISA entry. We never claim the observed product "is vulnerable" — we record that the observed product matches the vendor and product of CISA KEV #{cveId}.

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

On an entity's Observations tab and on the filtered entity list ("CISA-listed software observed"), a match is rendered as:

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.

Pre-disclosure handling

New KEV matches are held silent for 48 hours per /disclosure-policy. We attempt responsible disclosure via (in order) the target's security.txt contact, WHOIS abuse contact, or security@{domain} before the match becomes visible to CipherCue customers.

Correction

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

Changelog
v1.0 — 2026-04-28 — Initial publication. Vendor+product matching; version-range matching deferred.