Record the exact package name and ecosystem, every bad version, file hashes, the registry it came from, when it was published and when it was removed, and how it reached your systems. Without those facts, nobody can check your conclusions or search for the same package later.
Why an artifact record belongs in the postmortem
A postmortem is, in Google's SRE wording, a written record of an incident, its impact, the actions taken, the root causes and the follow-up actions. In a supply chain incident the record is only as good as the identifiers in it. "A bad logging library" cannot be searched. "name@1.2.3, sha256 of the tarball, from this registry" can.
The package page often changes after the incident. Versions get removed, descriptions get edited, maintainers post updates. Copy the facts while they are visible and note the time you copied them.
The record to capture
| Field | What to write | Why it matters |
|---|---|---|
| Ecosystem and name | Registry, scope or namespace, exact spelling | Lookalike names are common, so spelling is evidence |
| Bad versions | Each version, not a range | A range hides which builds were really exposed |
| Hashes | Digest of each downloaded archive | Confirms what you actually installed |
| Source | Registry URL, mirror or proxy used | A mirror may serve a version after the registry removes it |
| Timeline of the package | Published, reported, removed, advisory issued | Sets the outer edge of your exposure window |
| Behaviour | What the code did, with the source you rely on | Separates confirmed facts from guesses |
| Path in | Direct or transitive, and through which parent | Tells you where to fix it |
If you keep a copy of the malicious archive, store it in a restricted location and label it clearly. Do not attach it to a shared page where someone might run it.
Record how it reached you
The path in matters as much as the package. Write down which manifest or lockfile pulled it, which parent dependency required it, and which build or developer machine first resolved it. Your dependency inventory should answer this in minutes. If it did not, that is a finding for the postmortem itself.
Also note what stopped it, if anything. A cached mirror, a pinned lockfile or a release age delay may be the reason an incident was small. That belongs under what went well.
Separate facts from claims
Mark each line as one of three kinds: observed in your own logs, stated by a named source, or inferred. Link the source for the second kind. A postmortem that mixes them becomes folklore within a quarter. If a detail is unconfirmed, say so and add it to an open questions list with an owner.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how one package maps to the projects that include it, directly or through a parent.
Where Safeguard fits
Safeguard's SBOM and dependency scanning keeps a per project inventory you can query by package and version, which shortens the path in step. The free scan shows what an inventory looks like for your own repository.
Quick check
Should the postmortem list a version range or each version?
List each version. A range implies exposure you may not have had, or hides builds you did.
Is it safe to attach the malicious file to the postmortem?
No. Record the hash and keep any sample in restricted storage, clearly labelled.
Sources
Last reviewed: 19 October 2026.
