What makes node supply chain attacks so dangerous is the CI/CD pattern whereby all dependencies are downloaded from the internet every time a build is created. NPM attacks move fast.

I previously worked in an environment where our ci servers weren't internet-connected. One of the things we did get get node builds to work was we had 'node_modules' for our projects in a separate repository that got joined with our source code in CI to complete a build. When a developer added a dependency, they had to update this repo from their local version. It was annoying to have to synchronize two repositories, but this ended up being a forcing function for the development team to adopt several of the suggestions listed here. When you see a PR with a massive diff for a small dependency change, eyebrows raise and the team starts conversations about how to improve things.

▲

minitech 10 hours ago | parent [-]

Lockfiles are a more standard and probably better way to do this. (People do need to pay more attention to lockfile diffs.)

▲

DanHulton 7 hours ago | parent [-]

And if you want to get the same "we serve the code directly" benefit as well, you can set up an npm proxy and require its use. That way you're getting a very specific version, and downloading that version from a location you control.

(And then for the ultimate level of "slow your project to a crawl, but hey at least it's really secure", you can only allow versions that pass an internal security review to be added to the proxy and disable automatic fetching of un-cached versions. Ain't no sneaky code getting in unawares there!)

	▲	janstice 6 hours ago \| parent [-]
		A two week delay on including new versions would probably work more or less as well with a bunch less effort, but a local proxy looks like it’s going to be a lot more common very soon I’m guessing.