Lessons from npm's Security Failures - OneUptime

## The Current State: A Security Disaster Waiting to Happen Let's be honest about what we're dealing with. Today's package ecosystems operate on a foundation of trust that's fundamentally incompatible with the reality of modern software supply chains: - **Anyone can publish anything** with minimal verification - **Updates can be instant** with no cooling-off period for review - **Dependencies nest infinitely** creating attack surfaces developers never see - **Maintainer accounts are single points of failure** protected only by traditional 2FA … ### 3. Phishing-Resistant Authentication **Stop using TOTP codes.** They're fundamentally phishable and inadequate for critical infrastructure. - **Passkeys/WebAuthn only** for package publishing - **Hardware security keys** for npm accounts - **Domain-bound authentication** that can't be proxied Passkeys are unphishable by design because they're cryptographically bound to the correct domain. An attacker can create a perfect replica of npmjs.com, but they can't make passkeys work on npmjs.help. … ### 5. Transparent Build Processes **Source code should match published packages.** The disconnect between GitHub repositories and npm packages is a massive security hole. - **Provenance attestation** linking packages to source commits - **Reproducible builds** that can be verified by third parties - **Automated scanning** of source-to-package differences