When you are the upstream, the questions flip: who can publish, how do you stop more bad versions, and how do you warn the people who depend on you? This 60 minute script rehearses a stolen publish token for a fictional package, acme-sdk, with four injects.
Why upstream drills matter
Most supply chain exercises assume you are the victim of someone else's package. If you publish a library, an SDK or a container image, you are also someone's dependency. A stolen token, a compromised maintainer account or a poisoned build can put a bad release in front of your users. The npm worm response advice from CISA included requiring phishing resistant MFA on developer accounts and rotating credentials, which are the same levers you will pull here.
Setup
- Facilitator, scribe, a maintainer, a release engineer, a security lead, a communications contact.
- Handout: your actual list of who can publish and where. If this does not exist, that is finding number one.
Injects
Inject 1, minute 5. A user opens an issue: version 3.2.1 of acme-sdk contains a network call you did not write. Your release log shows no 3.2.1.
Ask:
- How do you confirm which versions are genuine?
- Who has publish rights and which tokens exist?
- What is the first containment move?
Inject 2, minute 15. You revoke the token and remove access. The registry still serves the version.
Ask:
- How long does revocation take? npm documents a delay of up to an hour for token revocation.
- What can you do to the bad version: deprecate, unpublish or publish a fixed version? Check each registry's rules.
- Who can talk to the registry's security team?
Inject 3, minute 30. Downloads show the bad version was pulled thousands of times.
Ask:
- How do you notify users: advisory, release notes, mailing list, social posts?
- What do you tell them to do, concretely?
- Who approves wording, and how fast?
Inject 4, minute 48. Your build system logs show an unfamiliar login two weeks ago.
Ask:
- Was the build compromised, or only the token?
- What do you rebuild from a clean environment?
- How will users verify the next release?
Message checklist for users
- Affected versions, stated plainly.
- The fixed version.
- What the bad code did, only as far as you have confirmed.
- What to rotate if they installed it.
- How to verify the new release.
Our guide to writing a security release note and how to write we do not know yet help here.
Debrief
Typical fixes: short lived publish credentials, two person release approval, publishing from CI only, and a documented incident contact on each registry. Put them in an after-action report.
Safeguard provides SBOM generation and policies that help downstream users check what they ship, and a free scan for your own repositories.
Try it yourself
Click through it at your own pace, or open it full screen. See how a fixed version is surfaced to a consumer, which is what your advisory must make easy.
Quick check
Can we just unpublish the bad version?
Registries have their own rules and time limits, and unpublishing can break builds. Check the registry's policy, and publish a fixed version and an advisory regardless.
What if we do not know yet what the code did?
Say so plainly, state what is confirmed, and give an update time. Do not guess about impact.
Sources
- CISA alert on the widespread npm supply chain compromise
- npm documentation on revoking access tokens
Last reviewed: 19 October 2026.
