Write impact as a list of what the bad dependency actually touched: builds, shipped artifacts, environments, credentials and data. Mark each line as confirmed affected, ruled out with evidence, or unknown. Never write "no impact" unless you can name the evidence behind it.
Why this section goes wrong
In an outage, impact is easy to describe: minutes of downtime, users affected. In a supply chain incident, impact is about reach, and reach is hard to see. A malicious package may have run on one laptop, in a hundred builds, or inside a container image still running in production.
SRE review guidance asks whether impact assessments are complete. For supply chain incidents, completeness means you looked at every place the code could have run, not only the place you found it first.
Five questions that structure the section
- Where did it run? Developer machines, CI runners, build caches, staging, production.
- What did it ship in? Container images, packages you publish, mobile or desktop releases, internal tools.
- What could it read? Environment variables, tokens, cloud credentials, source code, customer data.
- When was it live? First install to last removal, per environment.
- What did it do? Only what you can show from logs or from a named, fetched source.
Give each question its own short paragraph or table row. If you cannot answer one, write "unknown" and name who will find out and by when.
A simple status vocabulary
| Status | Meaning | Needs |
|---|---|---|
| Confirmed affected | Bad version resolved and executed | Log, lockfile or build record |
| Exposed, no sign of misuse | Code ran, no evidence of action | Logs checked, scope of the check stated |
| Ruled out | Never resolved the bad version | Lockfile history or inventory evidence |
| Unknown | Not yet checked | Owner and date |
"Exposed, no sign of misuse" is the honest middle. It tells readers that credentials in reach should still be rotated, even though nothing shows they were taken.
Credentials deserve their own line
For every confirmed or exposed environment, list the secrets that environment held. Then record whether each was rotated, when, and by whom. A postmortem that says "secrets were rotated" without a list will not satisfy a careful reader later.
Keep customer impact separate
Internal exposure and customer impact are different questions. Write the customer paragraph last, using only confirmed facts, and have your communications owner and, where relevant, your legal advisers review it before it leaves the team. This post is not legal advice.
Quick check
Can we write "no customer impact" if we found nothing?
Only if you can state what you checked and why that check would have shown impact. Otherwise write that no impact has been found so far and list what remains open.
Should impact include developer laptops?
Yes. Install scripts run wherever the package resolves, and laptops often hold broad credentials.
Sources
Last reviewed: 19 October 2026.
