Articles 3(40)–(42) and 14(1) — three steps, one that files
Article 3(40) defines a vulnerability as a weakness, susceptibility or flaw of a product with digital elements that can be exploited by a cyber threat. Article 3(41) defines an exploitable vulnerability as one that has the potential to be effectively used by an adversary under practical operational conditions. Article 3(42) defines an actively exploited vulnerability as a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner.
Only the third triggers the mandatory Article 14(1) chain: the manufacturer shall notify any actively exploited vulnerability contained in the product with digital elements that it becomes aware of, via the Article 16 Single Reporting Platform, to the coordinating CSIRT and ENISA. An OSV or GHSA for a flaw that is exploitable but not actively exploited in the Article 3(42) sense is a handling problem (and may be Article 15 voluntary later) — not an automatic 24-hour early warning. Related traps: CVE / NVD ≠ automatic AEV, EUVD ≠ automatic AEV, CISA KEV ≠ automatic AEV, CVSS / EPSS ≠ automatic AEV, SBOM / CVE-in-SBOM ≠ automatic AEV, VEX / CSAF ≠ automatic AEV, public PoC / exploit code ≠ automatic AEV, zero-days / FAQ 5.2, and AEV vs severe incident.
What OSV and GHSA actually are
OSV (Open Source Vulnerabilities) is a schema and aggregator for ecosystem vulnerability records. A GitHub Security Advisory (GHSA) is GitHub’s advisory identifier and review process for open-source packages — often the ID Dependabot and GitHub Advanced Security surface in pull requests. Neither catalogue appears in Articles 3 or 14. Publication of an OSV or GHSA means someone described a disclosed open-source flaw — not that every product containing an affected package has reliable evidence of malicious exploitation under Article 3(42), and not that your SKU is in an affected configuration.
For third-party components, guidance point 218 (not binding) addresses not-reachable / not-exploited-in-your-product shapes — see Article 14 for third-party components. Manufacturers who integrate FOSS are usually on the manufacturer clock today, not the later steward path — see Article 14 for open-source stewards. Score-driven dashboards that sit next to the advisory (CVSS, EPSS) are covered on the CVSS / EPSS guide.
Advisory IDs are not the SRP decision
When you do file an actively exploited vulnerability, ENISA’s platform and glossary ask for a CVE ID and EUVD ID where available. That is identification metadata for the notification stages — see the SRP fields checklist. An OSV ID or GHSA ID may map to those fields when a CVE exists; inventing a duty because Dependabot showed a new GHSA badge is not. Walk the report shape in the vulnerability notification template. CVE/NVD and EUVD traps sit beside this one — see Article 14 and CVE / NVD and Article 14 and EUVD.
When the 24-hour clock starts
Article 14(2)(a) runs the early warning from the manufacturer becoming aware. The Regulation does not define awareness. Guidance point 213: assess suspicious events or third-party alerts immediately; awareness is when, after that initial assessment, you have a reasonable degree of certainty that a vulnerability contained in your product is being actively exploited. Point 214: circumstances vary, but the emphasis is prompt assessment — not waiting for a perfect patch or a board memo. A new OSV/GHSA match is a reason to start that clock-starting assessment, not a reason to treat the advisory publication timestamp as awareness without product confirmation. Walkthrough: becoming aware; clocks in reporting deadlines.
The trap: OSV / GHSA as the reporting rule
Two failure modes. First: playbooks say “new GHSA → file CRA” and burn the 24-hour clock on every Dependabot hit before version match, reachability and exploitation evidence are checked — flooding the SRP. Second: teams treat “no OSV/GHSA yet” as a holiday even after reliable exploitation evidence arrives for a vulnerability contained in the product — exactly when Article 14(1)–(2) expect the AEV chain (final timed from corrective or mitigating measure available + 14 days under Article 14(2)(c); see corrective or mitigating measure). Record the assessment in the evidence log: OSV/GHSA identifier (or “none yet”), package/version match, reachability call, exploitation evidence relied on, and when reasonable certainty was reached.
Decision table
| Fact pattern | Article 14 AEV? |
|---|---|
| OSV / GHSA on a package; not in your lockfile / affected version | No Art 14(1) for that product (still watch other SKUs) |
| OSV / GHSA + package in product, but vulnerable code not reachable (point 218 shape) | Usually not mandatory Art 14; assess + handle / upstream |
| New GHSA published; assessment has not reached reasonable certainty of active exploitation | Triage signal only — not automatic 24h early warning |
| Contained + reachable + assessment reaches reasonable certainty of active exploitation (OSV/GHSA or not) | Yes — start 24h / 72h AEV chain from awareness |
| Reliable exploitation evidence; no OSV/GHSA assigned yet (or never) | Can still be Art 14(1) — advisory absence ≠ safe harbour |
| KEV / Critical CVSS / high EPSS / CVE / EUVD only (see KEV, CVSS / EPSS, CVE / NVD, EUVD) | Same product test — catalogue/score ≠ automatic Art 3(42) |
Questions people ask
- Is every OSV or GHSA hit in our Dependabot / SBOM feed reportable under Article 14?
- No. Article 14(1) requires notification of an actively exploited vulnerability contained in the product with digital elements. Article 3(42) defines that as a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner. An OSV or GHSA record identifies a disclosed open-source flaw; it does not by itself prove the package is in your product at an affected version, that the code is reachable, or that you have reached reasonable certainty of active exploitation in your product.
- Does the CRA mention OSV or GHSA?
- No. Regulation (EU) 2024/2847 never names OSV (Open Source Vulnerabilities) or GitHub Security Advisories. The legal ladder is Article 3(40) (vulnerability), Article 3(41) (exploitable vulnerability — potential under practical operational conditions), Article 3(42) (actively exploited), and Article 14(1) (contained in the product). OSV and GHSA are industry databases and advisory identifiers used in dependency triage — not substitute decision rules.
- Our lockfile shows a GHSA with a Critical severity. Must we file within 24 hours?
- Not from the GHSA alone. Severity labels and CVSS-style scores describe impact potential; they are closer to an Article 3(41) exploitability signal than to Article 3(42) reliable evidence of malicious exploitation. Run the immediate initial assessment (guidance points 213–214): version match, reachability, and whether you have reasonable certainty of active exploitation contained in your product. Score-driven traps are also covered on our CVSS / EPSS guide.
- What should a new OSV / GHSA match on our components trigger?
- Immediate initial assessment, not an automatic SRP early warning. Commission guidance C(2026) 5252 point 213 (not binding) says that when a third party or other signal brings a potential vulnerability to your attention, you should assess immediately; you are regarded as aware when, after that assessment, you have a reasonable degree of certainty that a vulnerability contained in your product is being actively exploited. Point 214 stresses prompt action.
- Our dependency has an OSV / GHSA but the vulnerable code is not reachable in our product. Still mandatory?
- Guidance point 218 (not binding) addresses third-party components: if you are aware that a component vulnerability cannot be exploited in your product (for example the vulnerable code is not reachable) or has not been exploited in your product, it does not qualify as an actively exploited vulnerability contained in that product for mandatory Article 14. You may still owe Annex I Part II handling (mostly from 11 December 2027) and Article 13(6) upstream notice once that package applies — see our third-party components and Article 13 vs Article 14 guides.
- Absence from OSV / no GHSA means we never have to report?
- No. Many actively exploited product flaws are reported before an OSV or GHSA record exists, or never receive one. Customer telemetry, researcher reports, your own detection, a CISA KEV listing, a CVE/NVD or EUVD entry, or other reliable exploitation evidence can meet Article 3(42) with no OSV/GHSA row. Absence of an advisory ID is not evidence of non-exploitation.
- When did this duty start?
- Article 14 has applied from 11 September 2026 (Article 71(2)), including for in-scope products already on the market (Article 69(3)). OSV/GHSA-driven triage is part of that live reporting duty — it is not postponed to the December 2027 Annex I conformity package or to open-source steward reporting under Article 24(3).