A CVE in a dependency I ship. Do I have to report it?

The trigger is “actively exploited,” not “vulnerable”

A red finding in Grype or Trivy is not, by itself, a filing. Article 14(1) of Regulation (EU) 2024/2847 (the Cyber Resilience Act) says a manufacturer “shall notify any actively exploited vulnerability contained in the product with digital elements that it becomes aware of.” The obligation is not “any vulnerability,” “any CVE,” or “any vulnerability with a public advisory.” It is specifically an actively exploited one.

The CRA separately defines “exploitable vulnerability” (Article 3(41)) as one that “has the potential to be effectively used by an adversary under practical operational conditions.” That is a theoretical-risk category. “Actively exploited vulnerability” (Article 3(42)) is a different, narrower category: “a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner.” A CVE identifier documents that a flaw exists in the underlying component, and, at most, that the CVE record or an associated advisory says it has been exploited somewhere. It does not by itself establish either half of the Article 14 test for your product: that the flaw is exploitable in your product, and that there is reliable evidence someone actually exploited it there.

Recital 68 reinforces this: an actively exploited vulnerability is established when “a manufacturer establishes that a security breach affecting its users or any other natural or legal persons has resulted from a malicious actor making use of a flaw in one of the products with digital elements made available on the market by the manufacturer.” The breach has to be tied to your product, not just to the underlying component in the abstract.

Dependencies and third-party components specifically

The European Commission’s CRA FAQ addresses this exact scenario directly, under a question asking whether all manufacturers integrating a component are required to notify a vulnerability found in it. It states: “If the manufacturer of a product with digital elements is aware that an integrated component contains a vulnerability, but that vulnerability cannot be exploited in its product with digital elements, that vulnerability is not actively exploited, and therefore it is not subject to mandatory reporting.” Manufacturers may still notify it voluntarily under Article 15, and are separately required to report the vulnerability to whoever maintains the component, under Article 13(6).

The flip side is also stated as a bright line: where the vulnerability in the integrated component genuinely is being actively exploited in your product, “the manufacturer of the product with digital elements is required to notify that vulnerability,” and the manufacturer of the component itself must also notify if that component was placed on the market separately. So a dependency’s CVE being exploited “in the wild” generally, with no path to exploitation in your product’s actual configuration, does not trigger your Article 14 clock; a dependency’s CVE being exploited through your product does.

What “evidence of exploitation” looks like

The same Commission FAQ gives non-exhaustive examples of what reliable evidence typically looks like: a customer or partner reporting unusual activity or compromise; threat-intelligence reports from researchers or security firms describing a zero-day being used in targeted attacks against your product; a government cybersecurity agency notifying you after detecting exploitation through its own monitoring; an ethical hacker reporting a vulnerability that is “already being exploited in the wild”; or your own telemetry, honeypots, or dark-web monitoring turning up evidence of successful exploitation. It explicitly adds that the CRA “does not specify how a manufacturer is to become aware,” and does not require you to run any particular monitoring or scanning program to satisfy Article 14.

The FAQ also gives a useful negative example that maps onto the CVE-in-a-dependency case: a zero-day found by ethical hackers or by a security lab testing on the manufacturer’s behalf, with no evidence of prior malicious exploitation, is “not an actively exploited vulnerability subject to mandatory reporting,” even though it is a real, disclosed, patchable vulnerability. The mere existence of a finding is not the trigger; evidence of actual malicious use is.

Unsettled: No source checked says whether a listing alone, in the EU’s own vulnerability database or in a catalog like CISA’s KEV, by itself satisfies or fails this test. Treat a database entry as a lead to investigate, not proof either way.

Bright line versus judgment call

What the sources state as close to a bright-line rule: reporting is mandatory only once you have reliable evidence of actual malicious exploitation, not mere exploitability, that plays out through your own product, and it is not mandatory when the flaw cannot be exploited in your product even if it can be exploited elsewhere.

What remains a manufacturer judgment call, because the primary sources deliberately leave it open: whether the evidence you have is “reliable,” whether the vulnerability is in fact reachable and exploitable in your product’s specific configuration, and when exactly you “became aware,” which starts the 24-hour early-warning clock. The Commission FAQ is explicit that the CRA does not prescribe a process for reaching that determination, so a manufacturer has to make and be able to defend its own assessment on the facts in front of it.

Timing once the duty is triggered

If you do conclude the dependency’s vulnerability is actively exploited in your product, Article 14(2) sets the same clock as for any other actively exploited vulnerability: an early warning within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure is available, all submitted through the single reporting platform to the CSIRT designated as coordinator and simultaneously to ENISA.