Wes
@notwes.bsky.social
ATX - he/him - 🥂Humans are more important than code - I work at an entertainment company and volunteer my time making art on github
https://github.com/wesleytodd
https://github.com/wesleytodd
The obvious exceptions are the advice about OIDC publish and provenance. OIDC is not ready yet (especially since it contradicts the other advice about enabling 2FA on your npm account) and provenance is pointless (on top of it only being available in likely insecure CI publishing setups).
November 25, 2025 at 1:50 PM
The obvious exceptions are the advice about OIDC publish and provenance. OIDC is not ready yet (especially since it contradicts the other advice about enabling 2FA on your npm account) and provenance is pointless (on top of it only being available in likely insecure CI publishing setups).
Nothing is ever perfect, but this is pretty good advice.
You all should be starring this repo and following up on every npm security best practice: github.com/lirantal/npm...
GitHub - lirantal/npm-security-best-practices: Collection of npm package manager Security Best Practices
Collection of npm package manager Security Best Practices - lirantal/npm-security-best-practices
github.com
November 25, 2025 at 1:48 PM
Nothing is ever perfect, but this is pretty good advice.
And there are also good ways to prevent something dumb locally before publish. But the killer for real secure systems is usually complexity making it hard to avoid doing something dumb on accident. And if you can automate it, it means anything dumb you can do an attacker might also be able to do.
November 24, 2025 at 11:47 PM
And there are also good ways to prevent something dumb locally before publish. But the killer for real secure systems is usually complexity making it hard to avoid doing something dumb on accident. And if you can automate it, it means anything dumb you can do an attacker might also be able to do.
That said, this is like saying "well the browser told me they passed the auth checks and are who they say they are" because npm auth and GH auth are two separate systems. GHA is the client in this analogy, and as these attacks have shown we can absolutely not "trust the client".
November 24, 2025 at 11:45 PM
That said, this is like saying "well the browser told me they passed the auth checks and are who they say they are" because npm auth and GH auth are two separate systems. GHA is the client in this analogy, and as these attacks have shown we can absolutely not "trust the client".
This exists. It is what we have been saying is a *requirement* for secure CI publish even before TP was introduced.
openjsf.org/blog/publish...
See the example repos and instructions in their readme on setup.
openjsf.org/blog/publish...
See the example repos and instructions in their readme on setup.
Publishing More Securely on npm: Guidance from the OpenJS Security Collaboration Space | OpenJS Foundation
The OpenJS Security Collaboration Space has been working closely with GitHub’s npm team to understand how new security features affect projects and maintainers, especially as threats and tools keep ev...
openjsf.org
November 24, 2025 at 11:45 PM
This exists. It is what we have been saying is a *requirement* for secure CI publish even before TP was introduced.
openjsf.org/blog/publish...
See the example repos and instructions in their readme on setup.
openjsf.org/blog/publish...
See the example repos and instructions in their readme on setup.
Having been deep in this the past months, I can say with 100% certainty that a clever malicious user could compromise *every single* current CI publish I have seen in the wild.
It is always a spectrum, but there is a reason we require MFA for things that are important.
It is always a spectrum, but there is a reason we require MFA for things that are important.
November 24, 2025 at 11:41 PM
Having been deep in this the past months, I can say with 100% certainty that a clever malicious user could compromise *every single* current CI publish I have seen in the wild.
It is always a spectrum, but there is a reason we require MFA for things that are important.
It is always a spectrum, but there is a reason we require MFA for things that are important.
And nothing they are doing in these changes addresses that. In fact, TP introduced a new and worse version of this attack.
November 24, 2025 at 11:39 PM
And nothing they are doing in these changes addresses that. In fact, TP introduced a new and worse version of this attack.
The attack was caused by a compromised CI system. That CI system was able to publish, and the token was entirely besides the point.
November 24, 2025 at 11:26 PM
The attack was caused by a compromised CI system. That CI system was able to publish, and the token was entirely besides the point.
Any enforced form of MFA is reasonable. The key is to remember to do three settings:
- 2fa for all writes on the account
- require 2fa for each package
- manage access via an org where you also require 2fa for all contributors
You have to have all three settings or you can easily have a gap.
- 2fa for all writes on the account
- require 2fa for each package
- manage access via an org where you also require 2fa for all contributors
You have to have all three settings or you can easily have a gap.
November 24, 2025 at 11:23 PM
Any enforced form of MFA is reasonable. The key is to remember to do three settings:
- 2fa for all writes on the account
- require 2fa for each package
- manage access via an org where you also require 2fa for all contributors
You have to have all three settings or you can easily have a gap.
- 2fa for all writes on the account
- require 2fa for each package
- manage access via an org where you also require 2fa for all contributors
You have to have all three settings or you can easily have a gap.
Reposted by Wes
Developers, please, enable passkey MFA on your npm account. It's extremely easy, and makes this category of attack impossible. At this point, I feel like it's negligent of GitHub not to require this of all publishers.
no way to prevent this says only package manager where this regularly happens
Shai-Hulud malware infects 500 npm packages, leaks secrets on GitHub
Hundreds of trojanized versions of well-known packages such as Zapier, ENS Domains, PostHog, and Postman have been planted in the npm registry in a new Shai-Hulud supply-chain campaign.
www.bleepingcomputer.com
November 24, 2025 at 11:10 PM
Developers, please, enable passkey MFA on your npm account. It's extremely easy, and makes this category of attack impossible. At this point, I feel like it's negligent of GitHub not to require this of all publishers.
Reposted by Wes
🤯 The number of affected packages in the Shai-Hulud npm attack has now reached 770. We’re continuing to investigate and will keep the blog post updated:
socket.dev/blog/shai-hu...
socket.dev/blog/shai-hu...
🚨 A new wave of the Shai-Hulud supply chain attack has hit npm, impacting packages across widely used projects from AsyncAPI, ENS, Postman, PostHog, and Zapier. Attackers added a malicious preinstall script following account compromise. The investigation is ongoing:
socket.dev/blog/shai-hu...
socket.dev/blog/shai-hu...
Shai Hulud Strikes Again (v2) - Socket
Another wave of Shai-Hulud campaign hits npm.
socket.dev
November 24, 2025 at 11:19 PM
🤯 The number of affected packages in the Shai-Hulud npm attack has now reached 770. We’re continuing to investigate and will keep the blog post updated:
socket.dev/blog/shai-hu...
socket.dev/blog/shai-hu...
"the news" knows the dynamic and plays into it, its still a low context take to say this only happens to npm.
Look, I am not every going to say the choices that led us all here were all roses. But this is 100% an "all software" problem not just an npm/js one.
Look, I am not every going to say the choices that led us all here were all roses. But this is 100% an "all software" problem not just an npm/js one.
November 24, 2025 at 10:42 PM
"the news" knows the dynamic and plays into it, its still a low context take to say this only happens to npm.
Look, I am not every going to say the choices that led us all here were all roses. But this is 100% an "all software" problem not just an npm/js one.
Look, I am not every going to say the choices that led us all here were all roses. But this is 100% an "all software" problem not just an npm/js one.
It is exactly the same argument and it is true in both cases. I agree (and was not intending to say) that "everyone doing it" is the point, I was saying the joke is based off a false premise as @thisismissem.social pointed out.
November 24, 2025 at 10:42 PM
It is exactly the same argument and it is true in both cases. I agree (and was not intending to say) that "everyone doing it" is the point, I was saying the joke is based off a false premise as @thisismissem.social pointed out.
We are also be best target because we have the most *new* developers and that is a *strength* of the language ecosystem.
I am not downplaying the technical decisions that led us here (that we also need to address), but folks like @bossett.social are always going to exist and post this stuff.
I am not downplaying the technical decisions that led us here (that we also need to address), but folks like @bossett.social are always going to exist and post this stuff.
November 24, 2025 at 10:21 PM
We are also be best target because we have the most *new* developers and that is a *strength* of the language ecosystem.
I am not downplaying the technical decisions that led us here (that we also need to address), but folks like @bossett.social are always going to exist and post this stuff.
I am not downplaying the technical decisions that led us here (that we also need to address), but folks like @bossett.social are always going to exist and post this stuff.
People love to make low context jokes bashing on JS any time they can. Then are happy to just ignore that every software ecosystem is susceptible to supply chain attacks without ever even ceding the point that it happens more on npm because it is the largest registry by an order of magnitude.
November 24, 2025 at 10:21 PM
People love to make low context jokes bashing on JS any time they can. Then are happy to just ignore that every software ecosystem is susceptible to supply chain attacks without ever even ceding the point that it happens more on npm because it is the largest registry by an order of magnitude.
Sent a DM to get things started.
November 24, 2025 at 9:49 PM
Sent a DM to get things started.
Also, happy to have you on our Security Collab Space call to share that directly or in whatever other form you would prefer to give the feedback. Some of this stuff we just are not talking about publicly until things are settled down, but we can share them in other forums with trusted folks.
November 24, 2025 at 9:34 PM
Also, happy to have you on our Security Collab Space call to share that directly or in whatever other form you would prefer to give the feedback. Some of this stuff we just are not talking about publicly until things are settled down, but we can share them in other forums with trusted folks.
Happy to take feedback!
November 24, 2025 at 9:32 PM
Happy to take feedback!
And as a maintainer, go read up on how you can prevent your package from being in the next list on a Socket blog post.
> Follow OpenJS' guidance and understand the pros and cons to the different approaches to publishing to npm.
openjsf.org/blog/publish...
> Follow OpenJS' guidance and understand the pros and cons to the different approaches to publishing to npm.
openjsf.org/blog/publish...
Publishing More Securely on npm: Guidance from the OpenJS Security Collaboration Space | OpenJS Foundation
The OpenJS Security Collaboration Space has been working closely with GitHub’s npm team to understand how new security features affect projects and maintainers, especially as threats and tools keep ev...
openjsf.org
November 24, 2025 at 9:27 PM
And as a maintainer, go read up on how you can prevent your package from being in the next list on a Socket blog post.
> Follow OpenJS' guidance and understand the pros and cons to the different approaches to publishing to npm.
openjsf.org/blog/publish...
> Follow OpenJS' guidance and understand the pros and cons to the different approaches to publishing to npm.
openjsf.org/blog/publish...
> as in its current state it wouldn’t prevent attacks such as Shai-Hulud and other recent ones.
From our blog, almost like we knew. 🔮
openjsf.org/blog/publish...
From our blog, almost like we knew. 🔮
openjsf.org/blog/publish...
Publishing More Securely on npm: Guidance from the OpenJS Security Collaboration Space | OpenJS Foundation
The OpenJS Security Collaboration Space has been working closely with GitHub’s npm team to understand how new security features affect projects and maintainers, especially as threats and tools keep ev...
openjsf.org
November 24, 2025 at 7:58 PM
> as in its current state it wouldn’t prevent attacks such as Shai-Hulud and other recent ones.
From our blog, almost like we knew. 🔮
openjsf.org/blog/publish...
From our blog, almost like we knew. 🔮
openjsf.org/blog/publish...
For ones like mime-db, it has been particularly rough IMO and I think we are probably better off taking it a bit more aggressive. That said, I have been fully on other work the past few months so have not been able to keep up with these discussions.
November 24, 2025 at 6:16 PM
For ones like mime-db, it has been particularly rough IMO and I think we are probably better off taking it a bit more aggressive. That said, I have been fully on other work the past few months so have not been able to keep up with these discussions.
This is more of a policy thing for express than anything else. We had a bunch of releases go out where there was confusion on if the engines should be bumped and if not if there should have been a major cut.
We figured it was better to couple majors to *actual meaningfully breaking* reasons.
We figured it was better to couple majors to *actual meaningfully breaking* reasons.
November 24, 2025 at 6:15 PM
This is more of a policy thing for express than anything else. We had a bunch of releases go out where there was confusion on if the engines should be bumped and if not if there should have been a major cut.
We figured it was better to couple majors to *actual meaningfully breaking* reasons.
We figured it was better to couple majors to *actual meaningfully breaking* reasons.
This is not a hygiene problem though. This is a "the security model is failing us" problem. We *can* have secure CI and publishing systems, instead GH keeps listening to the wrong people and building the wrong things.
November 24, 2025 at 6:09 PM
This is not a hygiene problem though. This is a "the security model is failing us" problem. We *can* have secure CI and publishing systems, instead GH keeps listening to the wrong people and building the wrong things.
Another week, another CI compromise leading to malware. This time it might even delete your home directory if it can't find any secrets to steal.
What was that again about trusted publishing? You need to trust your CI for it's threat model to apply? Guess maybe that's a bad place to put our trust.
What was that again about trusted publishing? You need to trust your CI for it's threat model to apply? Guess maybe that's a bad place to put our trust.
November 24, 2025 at 6:06 PM
Another week, another CI compromise leading to malware. This time it might even delete your home directory if it can't find any secrets to steal.
What was that again about trusted publishing? You need to trust your CI for it's threat model to apply? Guess maybe that's a bad place to put our trust.
What was that again about trusted publishing? You need to trust your CI for it's threat model to apply? Guess maybe that's a bad place to put our trust.
I have not had Oakland tacos to compare, but I totally agree that there are many great styles. The differences are the strength of the genre as a whole honestly.
November 21, 2025 at 9:51 PM
I have not had Oakland tacos to compare, but I totally agree that there are many great styles. The differences are the strength of the genre as a whole honestly.