Open your software supply chain incident runbook. It almost certainly says something close to this:
- Obtain the list of affected packages and versions.
- Search lockfiles across all repositories for matches.
- Pin or upgrade to safe versions.
- Rotate any credentials that may have been exposed.
- Write it up.
That runbook works for a static compromise. It fails against a worm, and 4 August 2026 demonstrated the failure at scale when nine compromised npm packages became 444 package names across 2,234 versions within hours.
Step one assumes a list exists and is final. During a worm campaign it is neither.
The four assumptions that break
"The affected list is static." It grows for as long as the worm has working tokens. A remediation scoped to the 09:00 list is incomplete by 11:00, and a team that treats the first advisory as authoritative will declare victory early.
"We are a victim, not a source." If anyone in your organisation had a publish token in a compromised environment, your packages may be part of the propagation. This flips your obligations entirely — from remediation to disclosure.
"Install equals impact." Installing the package is the event. The impact is the credentials that were readable from that environment, which is usually a much larger and different set than the install list suggests.
"There is time to be thorough before acting." With active propagation, the containment decision has a short half-life. The token you have not revoked is publishing right now.
A runbook that survives propagation
Phase 1 — Contain before you scope (first 30 minutes)
Do these before you know the full picture. They are cheap and reversible.
Revoke publish tokens for the affected registry — all of them. Not the ones you suspect. All of them. Restoring publishing capability later is a minor inconvenience; being a propagation node is not. This is the single highest-value action and it is routinely delayed while people scope.
Freeze dependency updates. Pause automated dependency bots and block new installs from the registry in CI if you can. This stops you ingesting versions poisoned in the last hour.
Preserve evidence before it rotates. CI job logs, build records, and registry audit logs frequently have short retention. Export the window now; you will need it in phase three and it may not exist tomorrow.
Phase 2 — Scope continuously, not once (first 4 hours)
Query build records, not just lockfiles. A lockfile shows current state. The question is which builds executed an affected version between the malicious publish and the takedown — including branches that have since been deleted and PRs that were closed. Build-time SBOM records answer this; lockfile grep does not.
Re-run the scope query on a schedule. Every hour, against the current affected list. Automate it. This is the concrete adaptation to worm behaviour and it is the step most runbooks lack entirely.
Enumerate what each affected environment could reach, not what it installed. For each build that executed a payload: which cloud credentials, registry tokens, source repositories, signing keys, and CI secrets were present in that environment? That list is your actual exposure.
Check whether you published anything during the window. Compare your packages' publish history against expected releases. An unexpected publish means you were a source, and disclosure obligations start immediately.
Phase 3 — Rotate proportionately (first 24 hours)
The trap here is binary thinking. Rotating everything is enormously disruptive and often triggers its own outage; rotating nothing is negligent. Neither is the right answer.
Order by reachability and blast radius:
- Registry publish tokens — already done in phase one.
- Cloud credentials reachable from affected build environments — these enable the widest lateral movement.
- Source control tokens — repository access enables persistence through committed code.
- Signing keys — highest consequence if abused, and usually the hardest to rotate, so start the process early even if it completes last.
- Application secrets in affected environments — database credentials, third-party API keys.
For each, record why it was or was not rotated. That record is what makes the decision defensible later, and it is what auditors and customers will ask for.
Phase 4 — Verify and close
Confirm no affected version remains resolvable, including in transitive paths and in container images built during the window. Images are the most commonly missed artefact: a rebuilt lockfile does not fix an image already pushed to a registry.
Verify propagation stopped. Your packages' publish history should show nothing unexpected after your token revocation.
Close only when the affected list has been stable for a defined period. Not when you finish remediating the list you had. This is the closure criterion worth adding explicitly, because without it teams close on the last known list and reopen two days later.
Three prerequisites you cannot build during the incident
Build-time dependency records with timestamps. Without them, "which builds ran during the window" is unanswerable and the entire scoping phase degrades to guesswork. This is the most common reason these responses take a week.
A credential map per environment. Knowing what each build environment holds should not require asking around. Assemble it in advance.
A pre-authorised emergency revocation path. If revoking all publish tokens requires an approval chain, containment happens hours late. Agree the authority in advance, in writing.
The strategic point
Worm-class supply chain attacks are not going to be rare. The economics are too good: maintainer account takeover requires no vulnerability research, propagation is automated, and the credential yield funds the next campaign.
Runbooks written for a static compromise will keep producing responses that look complete and are not. The adaptation is small — continuous scoping, containment before scoping, and a closure criterion based on list stability — but it has to be written down before the day it is needed.
How Safeguard helps
Build-time SBOM with timestamps, which is the prerequisite for phase two. Safeguard's Supply Chain Core records exact resolved versions per build across packages, containers, and models, so scoping is a query rather than an archaeology project.
Continuous re-scoping against a changing advisory set. As the affected list grows, Safeguard re-evaluates your exposure automatically rather than waiting for someone to re-run a search.
Eagle for proportionate rotation. Eagle establishes which environments genuinely executed an affected version and which credentials were genuinely reachable from each — the evidence that makes a targeted rotation defensible instead of choosing between nothing and everything.
Griffin for the remediation volume. Pinning safe versions, rebuilding affected images, and migrating credentials across many repositories is the work that consumes the first day. Griffin authors and tests those changes as reviewable pull requests in parallel.
Lion so the next one is smaller. Just-in-time secret brokering means build environments hold nothing durable to steal, capability scoping bounds what a compromised step reaches, egress allowlists break exfiltration, and signed audit trails make the exposure window reconstructable. The best incident response for a credential-harvesting worm is having no resident credentials to harvest.
Take your current runbook and check whether it has a step that re-runs scoping. If it does not, it was written for a threat model that stopped being the common case this year.
Sources: Aikido — keyv compromise · Socket · Chainguard — Mini Shai-Hulud campaign · Cloudsmith · Wiz
