21–30 of 501 posts
Reminder to secure your npm environments. https://gajus.com/blog/3-pnpm-settings-to-protect-yourself-f... Just a handful of settings to save a whole lot of trouble.
Completely unforced fragmentation of the dependency manager space imo
Reminder to secure your npm environments. https://gajus.com/blog/3-pnpm-settings-to-protect-yourself-f... Just a handful of settings to save a whole lot of trouble.
If I see a package version dependency that looks like this: ^1.0.0 or even this: "*", then stop reading, pin it to a secure version immediately.
Going to Trusted Publishing / pipeline publishing removes the second factor that typically gates npm publish when working locally.
The story here, while it is evolving, seems to be that the attacker compromised the CI/CD pipeline, and because there is no second factor on the npm publish, they were able to steal the OIDC token and complete a publish.
Interesting, but unrelated I suppose, is that the publish job failed. So the payload that was in the malicious commit must have had a script that was able to publish itself w/ the OIDC token from the workflow.
What I want is CI publishing to still have a second factor outside of Github, while still relying on the long lived token-less Trusted Publisher model. AKA, what I want is staged publishing, so someone must go and use 2fa to promote an artifact to published on the npm side.
Otherwise, if a publish can happen only within the Github trust model, anyone who pwns either a repo admin token or gets malicious code into your pipeline can trivially complete a publish. With a true second factor outside the Github context, they can still do a lot of damage to your repo or plant malicious code, but at least they would not be able to publish without getting your second factor for the registry.
So when do we call out NPM as an easy supply chain vector and also Microsoft's ownership of NPM and their prioritisation of AI at any cost. NPM is the windows of package managers right now.
Now that npm supports --before, yarn supports npmMinimumAge, and pnpm supports minimumReleaseAge, it's quite possible to stay safe and avoid acciasional bleeding-edge upgrades. Stay a couple months into the past, give testers time to look at newer releases and vet their safety (or report an exploit attempt).
Reminder to secure your npm environments. https://gajus.com/blog/3-pnpm-settings-to-protect-yourself-f... Just a handful of settings to save a whole lot of trouble.
Isn't this article wrong about npm minumum release age. 1. The config is min-release-age. 2. For some reason they have chosen to make it days instead of minutes: https://docs.npmjs.com/cli/v11/using-npm/config#min-release-... Completely unforced fragmentation of the dependency manager space imo
On a related note, it seems to be impossible to find the documentation of min-release-age by googling it. Very annoying.
Earlier quoted context omitted.
Abandon NPM in exchange for what? Cargo? Go get? Pip install? Every package manager that does not analyze and run tests on the packages being uploaded (like Linux distros do) is vulnerable.
Cargo is spiritually based on NPM so it's not much better. Go Get is closer to always locking dependencies unless you explicitly upgrade them with a go get, so it's much much better in my view. Yes, you can lock deps in NPM/Cargo/etc. but that's not the default. It is the default in Go. In Go projects my policy for upgrading dependencies includes running full AI audit of all code changed across all dependencies, come…
BTW a curated mirror of packages, where every package is guaranteed to have been analyzed and tested, could be an easy sell now. Also relatively easy to create, with the help of AI. A $200 every time is less pleasant than, say, $100/mo for the entire org.
Docker does something vaguely similar for Docker images, for free though.
It is unfortunate, but this is evidence (IMO) that Trusted Publishing is still ~~not secure~~ not enough by itself to securely publish from CI, as an attacker inside your CI pipeline or with stolen repo admin creds can easily publish. This isnt new information, TP is not meant to guarantee against this, but migrating to TP away from local publish w/ 2fa introduces this class of attack via compomise of CI. (edit: chan…
Reminder to secure your npm environments. https://gajus.com/blog/3-pnpm-settings-to-protect-yourself-f... Just a handful of settings to save a whole lot of trouble.
And absolutely pin, pin, pin, ALL your dependencies. If I see a package version dependency that looks like this: ^1.0.0 or even this: "*", then stop reading, pin it to a secure version immediately.
Reminder to secure your npm environments. https://gajus.com/blog/3-pnpm-settings-to-protect-yourself-f... Just a handful of settings to save a whole lot of trouble.
And absolutely pin, pin, pin, ALL your dependencies. If I see a package version dependency that looks like this: ^1.0.0 or even this: "*", then stop reading, pin it to a secure version immediately.
it used to be that projects that pinned deps were called out as being less secure due to not being able to receive updates without a publish.
different times, different threat model I suppose
Earlier quoted context omitted.
Abandon NPM in exchange for what? Cargo? Go get? Pip install? Every package manager that does not analyze and run tests on the packages being uploaded (like Linux distros do) is vulnerable.
Cargo is spiritually based on NPM so it's not much better. Go Get is closer to always locking dependencies unless you explicitly upgrade them with a go get, so it's much much better in my view. Yes, you can lock deps in NPM/Cargo/etc. but that's not the default. It is the default in Go. In Go projects my policy for upgrading dependencies includes running full AI audit of all code changed across all dependencies, come…