A detection section answers four things: who or what noticed first, which signal they saw, how long the gap was between the bad code arriving and someone noticing, and what would have shortened it. Write it as a description of the system, not of the person who spotted it.
Why detection is its own section
Google's SRE guidance lists a monitoring failure, which usually means someone found the problem by hand, as a common postmortem trigger. In supply chain incidents, detection is often external: a researcher blog post, a registry notice, a social media thread. That is useful information. It tells you your own signals did not fire first.
What to write
Give a short factual account in this order.
- First signal. The earliest evidence that anything was wrong, with a timestamp and where it came from.
- First human awareness. When a person on your team understood it might affect you.
- First confirmation. When you matched the bad package to your own systems.
- Gap. The time between the bad version arriving in your environment and each of the above.
Three timestamps are enough. Resist adding more unless they change a decision.
Classify the detection source
| Source | Example | Question to ask |
|---|---|---|
| Internal automated | Scanner finding, alert | Why was it not earlier? Was the feed slow or the rule missing? |
| Internal human | Engineer noticed odd behaviour | Could this be turned into an alert? |
| External public | Advisory, blog, registry notice | Do we subscribe to the right sources? |
| External private | Vendor or researcher email | Who receives mail to our security address, and who reads it? |
| Customer | Support ticket | What did they see that we did not? |
If the source was external, ask the uncomfortable follow up: if nobody outside had written about it, would we ever have known?
The detection gap is a system finding
Do not write "the team was slow to react". Write what information was missing or hard to reach. Could someone not answer "do we use this package?" quickly because the inventory was out of date? Was the advisory in a feed nobody watched? Those are fixable. Reaction speed alone is not.
Also record what went right. If a policy check, an alert or a careful reviewer caught it, say which one, so you can protect it.
Close with detection actions
End the section with one to three actions that shorten the gap, each with an owner and a date. Examples of the type of action: subscribe a named mailbox to a named advisory source, add an inventory query to the on-call runbook, or schedule a regular rescan of stored build records.
Quick check
What if we only found out from a public blog post?
Say so plainly and treat it as a finding. Then list the sources you will watch so the next signal reaches you first.
How many timestamps do we need?
First signal, first awareness and confirmation are usually enough, plus when the bad code arrived.
Sources
Last reviewed: 19 October 2026.
