A one-page SBOM-driven runbook has six parts: a trigger, named roles, a search procedure, a verdict rule, a communication step and a follow-up schedule. It should fit on a single page so people read it under pressure. Copy the outline below and fill in your own names, tools and locations.
1. Trigger
Start the runbook when an advisory names a component that appears in any product you build, ship or run, or when a supplier reports being affected. Name who may start it, such as any security engineer, and what they do first: open an incident record with the time and advisory reference.
2. Roles
| Role | Duty |
|---|---|
| Lead | Owns decisions and the clock |
| Scribe | Keeps the timeline and the evidence list |
| Searcher | Runs the SBOM queries and produces the hit list |
| Product owners | Give verdicts for their products |
| Communicator | Drafts notices, after approval from a named approver |
On a small team one person holds several roles. Write down who covers when someone is away.
3. Search procedure
- Record the component identity from the advisory: ecosystem, namespace, name and affected range.
- Search all stored SBOMs by package URL, including transitive components (see finding every product that ships a vulnerable component).
- Produce three lists: hits, hits removed with a reason, and products with no usable SBOM.
4. Verdict rule
Each product gets one status for the vulnerability, using the four values defined in the CISA minimum requirements for VEX: not affected, affected, fixed or under investigation. Not affected needs a justification or impact statement, and affected needs an action statement. Anything without evidence stays under investigation.
5. Communication
- Decide the approver before an incident and write it here.
- Draft the notice from verified facts only (see what a customer notice should say).
- Tier recipients by exposure.
- State the time of the next update inside the notice.
6. Follow-up
- Update verdicts and VEX statements as investigations conclude, incrementing the document version.
- Track remediation per product with an owner and a date.
- Hold a blameless review within a stated number of days, and file tickets for the gaps found.
Keeping it usable
Print or pin it where the team works. Check contacts and tool links quarterly. After each drill or real incident, edit the runbook and note the change date at the bottom. A runbook nobody has updated in a year tends to point at systems that no longer exist.
Quick check
Should the runbook name specific tools?
Yes, with links, but keep the steps tool neutral enough that a tool change does not break them.
Is one page enough?
For the procedure, yes. Keep templates, contact lists and background in linked pages.
Safeguard's vulnerability management, SBOM scanning and policy gates can support steps 3 to 6 of a runbook like this.
Sources
Last reviewed: 19 October 2026.
