After an incident involving a dependency, ask whether your SBOM data helped you answer quickly and correctly: how long it took to find affected products, whether the list was accurate, what was missing, and what you will change. Keep the review blameless and end with owned actions.
Why review the data, not just the response
Post-incident reviews usually cover who did what and when. For supply chain incidents, a second layer matters: was the information you needed available at all? If the first hour went to finding out where a library lived, the gap is in inventory, and that is fixable before the next event.
Ten questions
- How long from the advisory to a confirmed list of affected products? Write the actual time.
- Where did the list come from? Stored SBOMs, repository searches, or memory?
- Was it right? Were there products on the list that were not affected, or affected ones that were missed?
- Which products had no SBOM, or a stale one? Name them.
- Did the SBOM show transitive components? If not, how did you find indirect use?
- Could you tell what was deployed? Source SBOMs and deployed reality can differ. See SBOM drift between build and production.
- Who was asked, and how many hand offs? Count the messages.
- Did customers ask for information, and how fast could you give it? Compare with your commitments.
- What did the fix and verification look like? Did a fresh SBOM confirm the change?
- What decision would have been easier with better data?
Capture the findings
| Finding | Cause | Action | Owner | Date |
|---|---|---|---|---|
| Two services had no SBOM | Not in the pipeline | Add generation to CI | Platform team | Set it |
| Search took hours | SBOMs kept in repos | Store them centrally | Security | Set it |
Keep it blameless
Focus on the system, not individuals. If someone could not find the SBOM, ask why it was hard to find. If a service was missing, ask why the pipeline allowed that.
Measure the change
Pick two or three numbers and track them across incidents: time to a confirmed affected list, share of products with a current SBOM, and time to verify a fix. Our post on metrics that show SBOM incident readiness suggests more. Practice helps too: a small drill, such as finding a component in 30 minutes, tests the fixes without waiting for the next advisory.
Share the lessons
Write a short summary for engineering leadership. Include what worked, what did not, and the actions with dates. A review that ends without owned actions is a story, not an improvement.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how quickly a new advisory can be tied to your components.
Safeguard's SBOM and dependency scanning, with zero-day discovery, help shorten the step from advisory to affected list. A free scan shows what a repository contains.
Quick check
Is this review only for big incidents?
No. A near miss or a drill teaches the same lessons at lower cost.
What is the most useful single number?
Time from advisory to a confirmed list of affected products, tracked over time.
Last reviewed: 19 October 2026.
