Skip to content

The 24-hour reporting duty is in force. Check whether it applies to you

KEV match ≠ reportable incident: how we tier alerts so you don't cry wolf

Declara4 min read
  • feeds
  • alerting
  • kev
  • epss
  • vex

Every product on your inventory that shares a dependency with the wider internet will, sooner or later, show up in some vulnerability catalogue. If every one of those hits generated an alert, the alert would stop meaning anything within a week — which is the exact failure mode a compliance tool can least afford, since the one alert that mattered gets read with the same shrug as the fifty that didn't.

The short answer

Declara sorts every matched vulnerability into one of three tiers, and only one of them interrupts anyone. Tier A — in the CISA Known Exploited Vulnerabilities catalogue, or an EPSS exploitation-probability score of 0.5 or higher — raises an "assess now" alert. Tier B — CVSS severity of 7 or higher combined with an EPSS score of at least 0.1 — appears in a weekly digest instead. Tier C, everything else with a match but no exploitation signal, sits in your inventory and generates nothing.

EPSS

The Exploiting Prediction Scoring System estimates the probability a given vulnerability will be exploited in the wild in the near term, as a number between 0 and 1. It's a probability, not a certainty, and it's one of two exploitation signals we weigh — the other being membership in CISA's own catalogue of vulnerabilities already confirmed to be under active exploitation.

Why KEV membership alone is enough for Tier A

Being in the KEV catalogue means someone, somewhere, is already exploiting this vulnerability — that's what the catalogue is for, and it's the strongest signal available before you've done any product-specific investigation. It earns Tier A on its own, with no severity threshold attached, because exploitation-in-the-wild already answers the question a CVSS score can only estimate: whether an attacker actually bothers to use this one. A CVSS 9.8 nobody has ever exploited and a CVSS 6.5 sitting in KEV are different risks, and treating the CVSS number as the primary signal gets that backwards.

Why Tier B exists at all

Tier B is the calibration tier — severe enough and plausible enough to be worth a human looking at it during the next digest cycle, but not urgent enough to justify breaking someone's focus immediately. A CVSS 7+ finding with no meaningful exploitation probability yet is exactly the kind of thing that, treated as Tier A, teaches people to stop reading alerts closely. Held back to a weekly digest instead, it still gets reviewed, just not at 2am.

What a KEV match still isn't

None of this tiering decides whether you owe a report under Article 14 — it decides whether a human needs to look at something, which is a separate and earlier question. A Tier A alert means "assess whether your product is actually affected and whether the vulnerable code is reachable," not "file a report." The reporting duty is triggered by exploitation of your product specifically, and getting from a tiered alert to a reportable event still requires the same triage every case goes through: is the flagged component actually shipped, is the vulnerable path reachable, is there evidence of exploitation against your deployment specifically, and is a fix available. Skipping straight from "it's in KEV" to "we must report this" either over-files or, worse, trains a team to treat every KEV hit as boilerplate and miss the one that's genuinely reportable.

Two things the tiering deliberately doesn't do

It doesn't drop an uncertain match. When our matcher can't determine version ordering with confidence — an unfamiliar ecosystem, an ambiguous version string — the match is kept and flagged uncertain rather than silently discarded, because a dropped uncertain match is a silent false negative, and a customer unaware of something they ship is worse than a customer asked to double-check one extra row.

It doesn't let a VEX statement erase an alert that's already been raised. not_affected and fixed suppress future matches from generating new alerts; under_investigation deliberately doesn't suppress anything, because it says an assessment is in progress, not that one has concluded. And none of the three suppress an alert that already fired — a VEX statement arriving after the fact doesn't retroactively un-ring the bell, because by then somebody is already looking at it, and a document that quietly retracts an open alert is how a real finding disappears.

See how many of your own components carry an active KEV listing with the SBOM check — nothing is stored, and you'll see the same tier a real workspace would assign.

Not sure whether this applies to you?

This produces evidence, timelines and drafts. It is not legal advice, and you remain the party responsible for reporting.