In the first 24 hours after a component advisory, a vendor should confirm the advisory is credible, search release SBOMs for the component, assign a status to every product, send a short holding statement, and notify the most exposed customers. A full fix and VEX can follow, but the first answer cannot wait.
The runbook
| Window | Goal | Output |
|---|---|---|
| Hour 0 to 1 | Assign an owner and read the advisory | Named lead, a log started |
| Hour 1 to 3 | Match the component across release SBOMs | List of products and versions with the component |
| Hour 3 to 6 | Triage each hit | A status per product: affected, not affected, under investigation |
| Hour 6 to 8 | Draft the holding statement | Internal approval of the wording |
| Hour 8 to 12 | Notify tier 1 customers | Direct messages with a mitigation |
| Hour 12 to 18 | Mitigate or begin the fix | Workaround tested, fix in progress |
| Hour 18 to 24 | Publish an interim advisory and VEX | Public page, machine readable record |
These are targets, not promises. A small team may be slower, and a severe issue with known exploitation should be faster.
Hour by hour
- Lead and log. One person owns communication, one owns technical work. Keep a timestamped log, because you will reuse it for the post incident review.
- Check the source. Is the advisory from the maintainer, a database or a news story? Treat a rumour as under investigation, not as confirmed.
- Match. Query your component index by package identifier. If you have no index, this is the step that will hurt, and the lesson to act on afterwards.
- Triage. For each hit, ask: is the component actually shipped, in what version, and is the vulnerable code reachable?
- Holding statement. Say what you know, what you are checking and when the next update comes. Honesty beats a late perfect answer.
- Notify. Start with customers running exposed, affected releases. See who to notify first.
- Mitigate. Prefer a workaround you can describe in one paragraph.
- Publish. Under investigation is a valid status. Update it later.
If the flaw is being exploited
For products in scope of the EU Cyber Resilience Act, Article 14 asks for an early warning within 24 hours of becoming aware of an active exploit, a notification within 72 hours, and a final report within 14 days of a fix or mitigation. Article 14 applies from 11 September 2026. Have the contact and template ready before the day.
What to skip in the first day
- Perfect root cause analysis.
- A rescored CVSS for your product.
- Naming individuals or suppliers.
- Promising a fix date you cannot meet.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how an advisory becomes a list of products to check.
Quick check
Is "under investigation" an acceptable first answer?
Yes. It is a recognised VEX status, and it tells customers you have started.
Who should send the customer message?
One accountable communicator, using wording reviewed by the technical lead.
Safeguard's zero-day discovery, SBOM and dependency scanning and reachability analysis are built for the match and triage steps. A free scan shows how a project's components are listed.
Sources
- Regulation (EU) 2024/2847, EUR-Lex, Article 14 and Article 71
- OpenVEX specification
Last reviewed: 19 October 2026.
