What counts as “actively exploited”?
Article 14’s reporting trigger is active exploitation and severe incidents, not the mere existence of a vulnerability. A Critical CVE with no evidence of exploitation is something you track. A vulnerability with real evidence of exploitation is something you report. Severity and exploitation are different questions, and only one of them starts the clock.
No tool makes this determination with legal certainty, and this isn’t legal advice. What follows is the practical distinction: the signals that establish exploitation, and where OSPulse draws the Reportable-vs-Track line.
Not sure a given product is even in scope? Run the scope check first: it’s free and takes a minute.
CVSS score is not the trigger. Evidence of use is.
It’s tempting to read Article 14 as “report your Critical and High CVEs.” That’s not what it says. The duty is to report actively exploited vulnerabilities and severe incidents affecting the security of a product with digital elements: two things a severity score cannot tell you on its own. A CVSS 9.8 sitting unexploited in a dependency you use is a real risk worth patching, but on its own it isn’t a reporting trigger.
What flips a finding from track to report is evidence that someone is actually using it, and that evidence shows up as specific, checkable signals, not a feeling about how dangerous a CVE sounds.
Three signals that establish exploitation.
None of these require you to guess. Each is a checkable, category-level signal you can map against your own component inventory.
CISA KEV: the Known Exploited Vulnerabilities catalogue.
A vulnerability that CISA has listed as known to be exploited is about as clear a signal as exists: someone, somewhere, is using it against real systems. A dependency landing on KEV is the single strongest trigger to check against your own inventory: it turns a hypothetical into an actual.
In-the-wild exploit signals.
Exploitation evidence also shows up before or without a KEV listing: public proof-of-concept code being used in attacks, threat-intel reporting of active campaigns, or vendor advisories that state exploitation has been observed. The common thread is evidence of use, not just evidence that exploitation is theoretically possible.
Supply-chain compromise detection.
A severe incident does not need a CVE at all. A compromised build pipeline, a malicious package published under a trusted name, or a tampered release artefact can each be a severe incident affecting the security of your product, reportable in its own right, on the same clocks.
Reportable, or Track. Every finding is one or the other.
Track is a real vulnerability in something you ship, with no evidence yet that anyone is exploiting it. It belongs on your normal patching backlog, prioritised however you already prioritise vulnerabilities. Reportable is a vulnerability (or a severe incident, with or without a CVE) where one of the exploitation signals above has fired. That’s what starts the awareness clock: early warning within 24 hours, notification within 72, and a final report within 14 days of a corrective measure (one month for a severe incident).
OSPulse maps every component in your SBOM against exploitation intelligence (CISA KEV, in-the-wild exploit signals, and supply-chain compromise detection) and classifies each finding as Reportable or Track, with a timestamped record of when the signal arrived. You act on the findings that matter, not the whole CVE list. See how OSPulse builds the pack.
Frequently asked
What exactly does 'actively exploited' mean under Article 14?
It means there is evidence the vulnerability is being used in real attacks, not that it scores high on CVSS, not that a patch exists, and not that it looks dangerous. The evidence takes the form of signals: a CISA KEV listing, in-the-wild exploit activity, or a detected supply-chain compromise. Severe incidents affecting a product's security are reportable on the same basis even without a CVE attached.
So a Critical CVE is not automatically reportable?
Correct, and this is the distinction that trips teams up. Severity tells you how bad exploitation would be. It says nothing about whether exploitation is happening. A Critical CVE with no evidence of active exploitation is something you track and patch on your own schedule. The moment evidence of active exploitation appears, it moves to reportable, and the clocks start.
Where does OSPulse draw that line?
OSPulse maps every component in your SBOM against exploitation intelligence (CISA KEV, in-the-wild exploit signals, and supply-chain compromise detection) and classifies each finding as Reportable or Track. Reportable is what starts the awareness clock; Track is what stays on your normal patching backlog. No tool makes this call with legal certainty, and this isn't legal advice: it's a classification built from public exploitation signals, kept as an evidenced, timestamped record.
What if a low-severity CVE turns out to be actively exploited?
Then it's reportable, regardless of its CVSS score. Severity and exploitation are different axes. A Low-severity component with a working exploit circulating in the wild carries the reporting trigger. A Critical one sitting unexploited on a shelf does not. Watching exploitation signals, not just severity feeds, is the only way to catch that.
Know which findings actually matter.
Evidence and classification when a finding fires, not a claim that a tool discharges the obligation.