In the first hour: confirm the report from a primary source, identify which attack class it is, search your inventory for the affected component, contain by blocking or rolling back, and start a log. The specific containment step differs by class, as the table below shows.
Start the same way every time
- Name an incident lead and open a log with timestamps.
- Find the primary source: the registry, the vendor or a government advisory. CISA's guidance on the xz library, for example, gave the affected versions and a known good downgrade target.
- Search the inventory for the component and version.
- Decide whether it ran anywhere, and where.
Then branch by class
| Class | Likely first move | Also check |
|---|---|---|
| Dependency confusion | Stop builds resolving from the public source, fix registry or scope config | Which builds pulled the wrong package, and what ran during install |
| Compromised maintainer | Block the bad version, roll back to the last known good one | Lockfile history, caches, internal mirrors |
| Build system compromise | Isolate affected installs, restrict network egress, follow the vendor and national agency guidance | Credentials the software could reach, identity systems |
| Malicious update | Pause the rollout, roll back, hunt for post install behavior | Staging and pilot machines |
For the build compromise row, CISA's SolarWinds guidance went further: networks were categorised by evidence, affected instances were disconnected, and where administrative or SAML credentials were involved, the whole identity trust store was treated as compromised. Match your response to evidence, not to the label.
What to avoid in hour one
- Guessing at attribution or cause in public.
- Deleting evidence by wiping machines before imaging them.
- Updating to "latest" without checking that the new version is clean.
- Announcing "not affected" before you have checked deployed artifacts.
Communication
Send a short internal note: what is reported, what you checked, what you are doing, next update time. Keep customer statements factual and approved by the right owner.
Hours two to six
Rotate credentials reachable from affected systems, rebuild from trusted sources, and expand the search to the toolchain. Then plan the review of what let it in.
Practice it before you need it
Run a short tabletop for each class. Pick a real package from your inventory, pretend a bad version was reported this morning, and time how long it takes to answer three questions: do we run it, where, and who owns the fix. The gaps you find, usually in transitive dependencies and in build tooling, are the work to do before a real report arrives. Keep the exercise to an hour so it actually happens.
Quick check
Should I wipe affected machines immediately?
Image them first where you can, so evidence survives, then rebuild from trusted sources.
Is rolling back always safe?
Only to a version confirmed clean by a primary source. Check before you deploy it.
Where Safeguard fits
Safeguard offers zero-day discovery, SBOM and dependency scanning, and asset discovery, which support the search step. The free scan shows one project's inventory.
Sources
Last reviewed: 19 October 2026.
