You can test your readiness with a 30 minute drill: choose a real, common component, then try to list every product and release that contains it, with versions, using only your stored SBOMs. Score the result, note where you got stuck, and fix those gaps before a real advisory arrives.
Why drill at all
The CISA review of the Log4j event described vulnerability response teams that often could not identify where vulnerable code could be found in their systems. A written plan does not tell you whether your own inventory can answer that question quickly. A drill does.
Set it up
- Pick a component that appears in many products, such as a logging, JSON or HTTP library. Use a real one so the search is realistic, and do not tie it to any live incident.
- Pick a version range to treat as affected. The range can be invented for the drill.
- Name one lead, one scribe and one timekeeper.
- Start the clock. No prior preparation.
What to do in the 30 minutes
- Minutes 0 to 5: agree the exact package identity and build the package URL.
- Minutes 5 to 15: search all stored SBOMs, direct and transitive.
- Minutes 15 to 25: map hits to products and releases, and list products with no SBOM.
- Minutes 25 to 30: write the answer in three groups: affected, not affected, unknown.
Scoring
| Question | Good sign | Warning sign |
|---|---|---|
| Could you search all SBOMs from one place? | Yes | SBOMs scattered across drives and tickets |
| Did every product have an SBOM for its current release? | Yes | Several products had none |
| Were transitive dependencies visible? | Yes | Only direct dependencies listed |
| Did versions parse cleanly? | Yes | Missing or odd version strings |
| Could you map a hit to a customer-facing release? | Yes | Mapping needed guesswork |
| Finished inside 30 minutes? | Yes | Ran out of time |
The scoring is a self assessment, not a benchmark. Compare against your own earlier drills rather than other companies.
After the drill
Write the three biggest delays as tickets with owners. Typical fixes are generating SBOMs for the products that lack them, switching to full depth output, standardising on purls, and storing the SBOM beside the release. Repeat the drill with a different component in a few months and see whether the time falls.
Keep it low stakes
Make the drill blameless. The point is to find friction while nothing is on fire. The related post on running a tabletop exercise covers a wider discussion format, and this drill is a hands-on complement to it.
Try it yourself
Click through it at your own pace, or open it full screen. Try finding one component and see which parents bring it in.
Quick check
How often should we run the drill?
A few times a year is a reasonable start, and after any large change to how you build or store SBOMs.
Should we use a real vulnerable version?
Use a real component but an invented affected range, so the drill never looks like a live incident.
Safeguard's SBOM and dependency scanning can serve as the searchable inventory, and the free scan at gold.safeguard.sh/scan is a way to see the output.
Sources
Last reviewed: 19 October 2026.
