A standard postmortem template covers impact, timeline, causes and actions. For supply chain incidents, add five sections: dependency path, exposure window, artifact recall, credential rotation, and external sources. Each one captures something a general incident template tends to miss, and each is quick to fill in with the right links ready.
Why extend the template
A general template asks what broke and for how long. A supply chain incident asks a different question: what did we bring in, where did it run, and what did it reach? The details are spread across repositories, build systems and registries, so a template prompt keeps them from being forgotten.
The five additions
1. Dependency path. How the bad component reached you: direct or transitive, through which parent, via which manifest. Without it, the fix is guesswork.
2. Exposure window. From the first moment the bad version could have been resolved, to the moment it was blocked, per environment. Use UTC and state your sources.
3. Artifact recall. A table of images, packages and releases that contained the component, where they are now and how they were replaced. SLSA's provenance model describes recording resolved dependencies alongside build outputs, which is the data this table relies on.
4. Credential rotation. For each environment the code ran in, the secrets it could read, whether each was rotated, when and by whom.
5. External sources. Every advisory, registry notice or write up you relied on, with a link and the date you read it. Pages change, so the date matters.
Layout
| Section | Question | Evidence |
|---|---|---|
| Dependency path | How did it get in? | Manifest, lockfile, inventory |
| Exposure window | When was it live? | Registry timing, build logs |
| Artifact recall | What did it ship in? | Build records, image inventories |
| Credential rotation | What could it read? | Job configuration, rotation log |
| External sources | What do we rely on? | Linked pages with dates |
Keep the standard sections too
Retain the usual ones: summary, impact, detection, response timeline, causes, what went well, where we got lucky, and actions with owners, dates and verification. The additions go between impact and causes.
Make it fill in quickly
Pre-fill what you can. Link the inventory query, the CI log export step and the rotation log template. A template that takes an hour of setup will be skipped. One that opens with the right links gets used.
Keep the template short
Each prompt should be a question, not an essay. If a section does not apply, write "not applicable" and a reason, rather than deleting it, so reviewers can see it was considered.
Review the template
After each incident, ask what was missing from the template and update it. Treat the template as a living document with a named owner.
Try it yourself
Click through it at your own pace, or open it full screen. See how a new advisory is matched against what you run, which is the front end of the dependency path section.
Where Safeguard fits
Safeguard's SBOM and dependency scanning plus zero-day discovery give you the inventory and early signal that these sections draw on. Try the free scan on one repository.
Quick check
Do we need a separate template for supply chain incidents?
One template with optional supply chain sections is usually enough. Add the five sections when a dependency or build input is involved.
Why record the date we read each source?
Advisories and registry pages change. The date shows what you knew at the time.
Sources
Last reviewed: 19 October 2026.
