The single maintainer problem is that many npm and PyPI packages depend on one person's time and one account's security. If that person burns out or their account is taken over, every downstream project inherits the result. You cannot fix that for the ecosystem, but you can find where you depend on one person and prepare.
Why is one maintainer a risk?
Two documented patterns show it. In the xz case, a timeline compiled by Russ Cox describes sustained pressure on an overloaded maintainer, and says the attacker then gained commit access. That was a Linux library, not npm or PyPI, but the human factor is the same everywhere.
The second pattern is account takeover. CISA's September 2025 alert describes a self-replicating worm on npm, publicly called Shai-Hulud, that compromised over 500 packages. After initial access, it hunted for credentials such as GitHub tokens and cloud keys, sent them to the attacker, then logged into npm as the compromised developer, injected code into other packages and published malicious versions. CISA's alert does not say how initial access was gained.
Both show that the trust you place in a package is trust in a person and their credentials.
What do the registries offer?
npm provenance. npm documents provenance statements that link a package to its source and build instructions, signed through Sigstore and recorded in a public log. It requires building on a supported cloud CI provider, and npm is clear that provenance does not guarantee a package is free of malicious code. Trusted publishing generates provenance automatically and removes the need for access tokens in CI. Consumers can run npm audit signatures to check registry signatures and attestations of downloaded packages.
PyPI. PyPI has required two-factor authentication for all users since 1 January 2024. Trusted Publishing lets a CI service publish through OpenID Connect without a manually created token. PyPI issues a short-lived, project-scoped token valid for 15 minutes, so a stolen token is far less useful than a long-lived one.
These reduce risk for packages whose maintainers use them. They do not tell you which of your dependencies lack them.
What does CISA recommend after a worm like that?
The alert advises reviewing lockfiles including nested dependencies, searching artifact repositories for cached copies, pinning to known safe versions released before 16 September 2025, rotating developer credentials immediately, requiring phishing-resistant multifactor authentication for developer accounts, and enabling branch protection, secret scanning and security updates. Those apply to your own publishing too.
Preparedness checklist
Find the concentration
- Generate a full dependency inventory with transitive packages.
- For your top fifty, note the number of maintainers, last release date and whether releases carry provenance.
- Flag packages with a single maintainer that sit in a critical path.
Reduce exposure 4. Use lockfiles and pin versions. Upgrade on a schedule, not automatically on release. 5. Add a short waiting period before adopting brand-new versions of critical packages, so the community can spot a bad release. 6. Replace or vendor a tiny package you could write in an hour.
Protect your own publishing 7. Turn on two-factor authentication everywhere, preferably phishing resistant. 8. Publish through trusted publishing, with no long-lived tokens.
Prepare to respond 9. Know how to search every repository and image for a package name and version in minutes. 10. Keep a credential rotation runbook.
Safeguard's free scan at gold.safeguard.sh/scan checks up to 100 dependencies in the browser, and the CLI generates an inventory across many package managers. Both help with steps 1 to 3.
What to do
- Build the inventory this week.
- Mark single-maintainer, critical-path packages and pick a plan for each.
- Switch your own packages to trusted publishing.
- Add a version waiting period for critical packages.
- Rehearse the "find a bad package everywhere" search.
Quick check
Does npm provenance prove a package is safe?
No. npm says it provides a verifiable link to the source and build, which you can audit. It does not guarantee the code is free of malicious content.
Is two-factor authentication required on PyPI?
Yes. PyPI has required it for all users since 1 January 2024.
Sources
- CISA: Widespread supply chain compromise impacting npm ecosystem
- npm Docs: Generating provenance statements
- PyPI Docs: Trusted Publishers
- PyPI Blog: 2FA enforced for all users
- Russ Cox: Timeline of the xz open source attack
Last reviewed: 18 October 2026.
