What is npm doing to protect the JavaScript ecosystem – and is it enough?

I've been trying to write about how npm is trying to protect the massive JavaScript ecosystem for a while now which was difficult in the midst of alternating attacks and registry changes (and busy maintainers/anyone at npm/GitHub having time to talk to me; here's a really deep into what npm is doing

The shift away from exactly the kind of long-lived, over-permissioned tokens that attackers are compromising packages to get their hands on was always going to be painful; partly because as @aeagle.bsky.social points out to me, as an industry we've been much to casual about those identity tokens

I spent a lot of time reading npm and github issues where developers both want npm to protect them from supply chain attacks but also not make their lives harder by, say, deprecating TOTP because *they* have never been compromised using it and I think that tension is part of what makes this so hard

other package managers take a different stance on defaults and I asked @patak.cat to tell me about @npmx.dev; npm kept the attitudes of when it started for a very long time but that's changing, especially with the new defaults in npm 12 to make developers do the work of approving install scripts

it isn't just npm getting attacked; some of the attacks on npm packages target other registries *at the same time* and the defence of trusted publishing is the same for all the registries; npm has added a new twist forcing staging of releases that have to be approved that @nodeland.dev rates highly

not everyone thinks trusted publishing on npm is ready for major projects @humanwhocodes.com points out some of the missing pieces for me. when attackers with nation state resources and sophistication spend weeks going after maintainers, they can end up with control of every step of the pipeline

in the end this might be about shared responsibility: npm has to support maintainers and give developers more ways to protect themselves against supply chain attacks, developers have to turn on protections, look more at dependencies and actually verify what third party code they're going to run does

but defending npm packages also encapsulates one of the recurring issues of open source: what I call 'free as in night off'. if we don't fund and support maintainers, they're not going to have the time and energy to do all the hard work of keeping their project pipeline secure. npm can't fix that.