Your preparation
0 of 0 safeguards readyMake the next decision with evidence
Stop unauthorized publishing, identify every affected package and consumer, and re-establish trusted releases with new credentials and provenance.
Capture before evidence disappears
- Preserve registry login, token, 2FA, owner, maintainer, package, version, dist-tag, deprecation, and download events.
- Download suspect archives safely and record cryptographic hashes, metadata, signatures, provenance, install scripts, and file differences.
- Map publishing tokens, CI jobs, OIDC identities, signing keys, maintainers, organizations, scopes, and recovery contacts.
- List internal and external consumers by lockfile, SBOM, cache, image, artifact, and deployment digest.
Decisions that change the response
| Question | Act when | Action |
|---|---|---|
| Unpublish, deprecate, or supersede? | The registry's immutability and dependent-install behavior are understood. | Coordinate with the registry. Mark the affected version clearly and publish a verified replacement when safe. |
| Pause all releases? | Publisher identity, CI, signing, source, or organization ownership is not trustworthy. | Freeze publishing until a clean path and reviewed artifacts exist. |
| Notify consumers? | A malicious package was downloadable or a legitimate package was altered. | Publish exact versions, hashes, dates, indicators, remediation, and a verified communication channel. |
Proof that recovery worked
- Only approved maintainers and short-lived publishing identities remain; old tokens fail.
- Affected versions, tags, owners, README links, and package metadata match the incident record.
- A clean source commit produces the replacement archive and expected provenance.
- Internal deployments and caches no longer contain affected package digests.
Controls to put in place
- Require secure MFA, two maintainers, and registry-supported trusted publishing with short-lived identity.
- Separate install, test, sign, and publish jobs; protect release environments with review.
- Monitor owner, token, tag, version, and download anomalies for critical packages.
- Generate provenance and SBOMs, then verify the published archive from a fresh consumer.
In a private test package, change a dist-tag and add an unauthorized maintainer. Recover ownership, freeze publishing, compare the archive to source, rotate a token, and send a mock consumer advisory.
Contact the registry and incident responders immediately when a malicious public version exists, namespace ownership is lost, signing keys were exposed, or downstream customer systems may have executed the package.
What this means
A compromised npm, PyPI, container, or other registry identity can turn a single account takeover into a software supply-chain incident affecting every downstream installer.
Warning signs
- An unknown version, tag, owner, token, or automation publisher appears.
- Downloads or install behavior change after an unexplained release.
- Registry security alerts or login emails are unfamiliar.
- Customers report suspicious package behavior.
Recover now
First 15 minutes
- Secure a known-good registry owner account and its email.
- Revoke publisher tokens and pause automated publishing.
- Preserve package metadata, logs, artifacts, hashes, and release times.
- Mark or remove malicious releases using the registry’s supported process.
Today
- Compare published artifacts with reproducible output from trusted source.
- Rotate CI, signing, repository, and registry credentials in scope.
- Notify affected users with exact versions, indicators, and safe upgrade or removal steps.
- Review connected source and build systems for the initial access path.
Verify recovery
- Only recognized owners and publishers remain.
- Compromised tokens and versions can no longer be used.
- Trusted artifacts match source and expected hashes.
- Affected users can identify and remove the malicious version.
Prepare now
Access
- Registry owners use phishing-resistant MFA and separate named accounts.
- CI publishes with a restricted, short-lived identity where supported.
Backups and evidence
- Released artifacts, manifests, signatures, and hashes are retained independently.
Contacts and ownership
- Registry security contacts and package ownership proofs are recorded.
Practice
- Publishing can be paused and a test token revoked quickly.
Common mistakes
- Publishing a clean version without warning users about the malicious one.
- Rotating the registry token but ignoring compromised CI.
- Deleting evidence before comparing artifacts.
Sources
- OWASP: Software Supply Chain Security
- CISA: Guidance for customers on securing the software supply chain
Reported by the people who handled it
Lessons from real incidents
These are operator postmortems and official incident reports, condensed into one lesson you can reuse.npm operations incident of July 12, 2018
TL;DRAn attacker used a publisher's compromised npm account to release malicious package versions intended to steal more npm tokens. npm revoked every access token created before containment and began a forensic review for unauthorized publishing.
Learning to reuseContain both the publisher and the possible chain reaction. Revoke the full exposed token population, inspect every release made during the window, and require strong authentication for publishing.
Read the full report(opens in a new tab)