On this page
- A published contact and coordinated-disclosure policy are baseline expectations.
- Triage records exploitability decisions against shipped components and versions.
- Fixes need distribution evidence: signed updates reaching affected customers.
- Actively exploited cases start the Article 14 reporting clock.
Build the front door
The process starts before any report exists: a published contact, a coordinated-disclosure policy aligned with ENISA guidance, and internal targets for acknowledgement, triage, and resolution. A SECURITY.md that promises a response nobody owns is worse than a short policy the team honours.
Annex I, Part II, points (5) and (6) requires a coordinated vulnerability disclosure policy and a contact address. The policy is evidence of process design; acknowledgement, investigation and remediation records show whether the process operates.
Triage against the release, not the repository head
An advisory match is an input, not a final conclusion. Compare affected versions with the release SBOM, then investigate whether the component and vulnerable path ship and are reachable in intended and reasonably foreseeable use. Record the evidence, uncertainty, owner and review trigger. A not-affected decision for one release must not silently close the advisory for every version.
Fix, ship, and say so
A completed fix needs test evidence, secure distribution and customer information. Annex I, Part II, points (2), (4), (7) and (8) connects remediation, disclosure and updates. Once an update is available, disclose the fixed vulnerability, affected products, impact, severity and remediation clearly. A justified delay is permitted where publication risks outweigh the security benefits until users have had an opportunity to patch.
Under Article 14, awareness of an actively exploited vulnerability contained in the product starts a separate reporting process. Severe incidents affecting product security are a distinct trigger. Do not wait for a patch or completed root-cause analysis before assessing the duty. The reporting timeline distinguishes the 24-hour and 72-hour stages and the different final-report deadlines.
Frequently asked questions
Do we have to disclose every vulnerability publicly?
Annex I, Part II, point (4) requires information about fixed vulnerabilities to be disclosed once a security update is available. A justified delay is possible where disclosure risks outweigh the security benefits until users have had an opportunity to patch. This is separate from Article 14 reporting to authorities.
What if the vulnerable component is transitive?
It is still in your product, so it is still yours to handle: confirm it ships, assess reachability, fix or upgrade where possible, and escalate upstream in parallel. This is exactly the case the SBOM and monitoring exist to catch.