Somehow it is missing the "read the code of your dependency" step … :)
Even occasionally having a glance (e.g. when reading the docs) might be super helpful in discovering strange things going on.
Show HN: Tips to stay safe from NPM supply chain attacks
41–50 of 56 posts
Re: Show HN: Tips to stay safe from NPM supply chain attacks
#42Also, don't use npx.
With the colors incident back in 2022, random stuff started to break not when people updated their dependencies, but immediately, because npx would resolve dependencies when the command is executed.
This means it's not really possible to reason about what code is going to execute, and forensics is going to have a really hard time figuring out what a computer has executed.
If your software uses npx in any capacity, you've auto-failed the SBOM compliance checkbox.
Re: Show HN: Tips to stay safe from NPM supply chain attacks
#43Somehow it is missing the "read the code of your dependency" step … :) Even occasionally having a glance (e.g. when reading the docs) might be super helpful in discovering strange things going on.
Or maybe just read the commits between now and a reasonable date far enough in the past so that if there is some hostile code injected before that point in time, then at least you will share the walk of shame with a lot of people and you can play the sound of "who could have guessed?"
Re: Show HN: Tips to stay safe from NPM supply chain attacks
#44Somehow it is missing the "read the code of your dependency" step … :) Even occasionally having a glance (e.g. when reading the docs) might be super helpful in discovering strange things going on.
Or maybe just read the commits between now and a reasonable date far enough in the past so that if there is some hostile code injected before that point in time, then at least you will share the walk of shame with a lot of people and you can play the sound of "who could have guessed?"
There's no point in reading the code in the Git repository or its commit history because that's not the code that you're actually executing. You have to read what's in your node_modules, everything else is irrelevant.
Re: Show HN: Tips to stay safe from NPM supply chain attacks
#45Earlier quoted context omitted.
Or maybe just read the commits between now and a reasonable date far enough in the past so that if there is some hostile code injected before that point in time, then at least you will share the walk of shame with a lot of people and you can play the sound of "who could have guessed?"
There's no point in reading the code in the Git repository or its commit history because that's not the code that you're actually executing. You have to read what's in your node_modules, everything else is irrelevant.
This is often overlooked, to the point I created a website focusing on "the code we actually put into our computers":
It doesn't index all of npm, only if the package was reference by a Linux distribution somehow (e.g. package-lock.json in a tar file used in an Arch Linux PKGBUILD).
Re: Show HN: Tips to stay safe from NPM supply chain attacks
#46Earlier quoted context omitted.
Not sure that's possible with JS.
You could theoretically overwrite the public functions of a module, inject some logging code, then execute the originally intended function when it's called with ".apply()" and passing the original arguments in. That might get you part of the way there.
I'm thinking eval's and prototype overloading would make this a permanent cat and mouse game.
Frankly, I don't see how the node ecosystem can ever be secure. It's random-libraries all the way down. With half of them being useless frippery.
Imho, WASM compiled from languages that have strong standard libraries are the way forward for security. And, maybe node will get fixed in 5-10 years.
A good example of a language going "this shouldn't be a library."- Net used to only have a third party json parser (newtonsoft) but microsoft created a first party json parser and deprecated newtonsoft from their examples and templates
Re: Show HN: Tips to stay safe from NPM supply chain attacks
#47Also, don't use npx. With the colors incident back in 2022, random stuff started to break not when people updated their dependencies, but immediately, because npx would resolve dependencies when the command is executed. This means it's not really possible to reason about what code is going to execute, and forensics is going to have a really hard time figuring out what a computer has executed. If your software uses np…
> npx would resolve dependencies when the command is executed
I hate that this is becoming a thing. I was pretty miffed some time back when I realized go build just went ahead and installed a whole new version of golang on my machine. These are devtools ffs, why so much mollycoddling! And what happened to half a century of good conventions where the default is always to prompt?
Re: Show HN: Tips to stay safe from NPM supply chain attacks
#48Earlier quoted context omitted.
To be honest, NPM is a complete shitshow when it comes to this, and I wish each and every single person who had a hand in developing it have their keyboards taken away, and never be allowed to touch any developer tooling ever again. See this Stackoverflow thread: https://stackoverflow.com/questions/45022048/why-does-npm-in... The top answer has 3 updates to it, and links to 2 github issues, with conflicting informati…
Figuring out what is true for npm v5 is quite the waste of time, given that we are currently at v11. And that's what this ancient stackoverflow thread is about. npm certainly has a troubled past, otherwise we wouldn't have yarn and pnpm and whatnot. But _today_, npm install works very reasonably with lockfiles.
You are right, but starting with an insane default (there is a lock file, but installing overrides and updates it), then introducing another command that does the expected behavior (npm ci), and then finally making that the default is at least confusing.
Re: Show HN: Tips to stay safe from NPM supply chain attacks
#49One thing I haven't seen talked about at all is the local development setup. I was thinking of putting node/js projects fully into docker containers (and mounting the project directory as a volume for hot reloading). While this doesn't fix the CI attack vector, it should mitigate risk for personal/work machines. I'd be interested in hearing the setup other people have for their dev envs, also are you using separate b…
I actually posted about my own Docker setup this morning: https://ryansouthgate.com/secure-node-in-docker/
I use this on all my front end projects and it protects my "host" machine from malicious packages, it's not a silver bullet though; other practices, e.g. good secret management, will help harden your dev environment from these attacks
Re: Show HN: Tips to stay safe from NPM supply chain attacks
#50I created https://github.com/JamieMason/shrinkpack in 2015 to try and help with this problem, by creating an offline mirror of decompressed tarballs from the npm registry that you'd check into your repository.
I thought it might have some merit at the time, but it never really took off as an idea.