Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

My problem is that, in the JS ecosystem, every single time you go through a CI/CD pipeline, you redownload everything. We should only download the first time and with the versions that are known to work. When we make a manual update to version, than only that should be downloaded once more.

I just checked one of our repos right now and it has a 981 packages. It's not even realistic to vet the packages or to know which one is compromised. 99% of them are dependencies of dependencies. Where do we even get started?

Redownloading everything isn’t a risk when the lock file contains a hash of the download on first update.

Isn't that what lockfiles are for? By default `npm i` downloads exactly the versions specified in your lockfile, and only resolves the latest versions matching the ranges specified in package.json if no lockfile exists. But CI/CD pipelines should definitely be using `npm ci` instead, which will only install packages from a lockfile and throws an error if it doesn't exist.

Generate builder images and reuse them. It shaves minutes off each CI job with projects I'm working on and is non-optional because we're far from all major datacenters.

Or setup a caching proxy, whatever is easier for your org. I've had good experience with nexus previously, it's pretty heavy but very configurable, can introduce delays for new versions and check public vulnerability databases for you.

It's purely an efficiency problem though, nothing to do with security, which is covered by lock files.

That and pin that damn version!

It’s still ridiculous to me that version pinning isn’t the default for npm.

The first thing I do for all of my projects is adding a .npmrc with save-exact=true

save-exact is mostly useless against such attacks because it only works on direct dependencies.

Why, though?