Like the projects but not a Show HN, see the guidelines.
Show HN: Tips to stay safe from NPM supply chain attacks
11–20 of 56 posts
Re: Show HN: Tips to stay safe from NPM supply chain attacks
#12Here is the entire guide you need to protect yourself from supply chain attacks as a software engineer.
Pick whichever of these will consume the fewest resources over time:
1. review an existing library and all dependencies, and all security updates to them forever (or ensure someone capable does or did)
2. implement the minimal functions you require on top of the language standard library yourself
Yes, this is serious advice, and I have followed it while shipping web applications to millions of people at multiple companies, as a consultant for many more companies, and as a founder and security engineer.
Re: Show HN: Tips to stay safe from NPM supply chain attacks
#13Plug: I've been building a tool to detect software supply-chain cyberattacks: https://github.com/ossillate-inc/packj Packj uses static+dynamic code/behavioral analysis to scan for indicators of compromise (e.g., spawning of shell, use of SSH keys, network communication, use of decode+eval, etc). It also checks for several metadata attributes to detect impersonating packages (typo squatting).
Every decent malware author just adds tools like these to their test suites, and only release new malware that evades all detection.
That game of cat and mouse never ends.
The only solution is just actually reviewing the code we ship to our customers. Yes, even the code we copied off the internet with a magic "npm install" command.
Re: Show HN: Tips to stay safe from NPM supply chain attacks
#14> Show HN: Tips to stay safe from NPM supply chain attacks
1. Don't use the damn thing.
2. If it needs an internet connection to compile, uninstall it.
Re: Show HN: Tips to stay safe from NPM supply chain attacks
#15I appreciate all this guidance. I hope Node developers read it all and consider adopting most/all of it.
Node and the NPM ecosystem has been so productive for me and package.json scripts got me more into shell scripting than I ever thought I would.
All that said, there are some major insecurity deal breakers that frighten me when using Node in public-facing services.
Sneaking in compiled native binary blobs as part of NPM install, transitive dependencies with unpinned versions, the vast wasteland of unmaintained packages in NPM ... Node just needs to be superceded, I feel like.
It would be really great for a newer tech company with deep pockets like Tesla to pull a Sun Microsystems and release a new secure-by-design OS and language stack - maybe in support of a modernized hardware platform offering.
My preference would be for a deeper standard library like the jdk. I would like some sort of digital provenance that runs from the dev environment, through the os and package manager, through to all device types all the way through to the one and only global app store (or an enterprise-hosted proxy.) The whole kit and kaboodle signed and delivered at all levels.
I would like more energy efficient network hosting and service delivery patterns codified.
I would like public developer guilds with certs not as a prereq for employment, but rather to encourage developers to have something to show for their training other than a nebulous college diploma. Senior guildsmen can present their work products for review as an ongoing proof of their craftsmanship.
Re: Show HN: Tips to stay safe from NPM supply chain attacks
#16Someone recommended this to me on another thread and tried it yesterday and it seems very good: https://github.com/safedep/vet
Isn't this just checking packages against known cves, which wouldn't help for undiscovered or unannounced vulnerabilities. Let me know if I've misunderstood, I'm basing off the documentation site.
Also I find the irony goes hard in their recommendation of installing another attack surface (brew) on Linux and missing the point.
Re: Show HN: Tips to stay safe from NPM supply chain attacks
#17For what it's worth, I prompted GPT-5 Pro to produce a npm supply chain best practices guide, to see what it comes up with. I've not read it yet.
https://gist.github.com/pschleger/c1c36fbde003bea5eee7ce4291...
And a prompt to review a site I built for GitHub Pages, which I'll try this week.
https://gist.github.com/pschleger/8d5fcea6b96d8504ac58bb2f8d...
Re: Show HN: Tips to stay safe from NPM supply chain attacks
#18These tips are great, but they don’t address some of the core ways that these supply chain attacks may happen: global modules and npm modules installed with editor extensions.
So `yarn global add nx` will still install the latest version by default, unless you specifically have a `~/.yarnrc` disallowing lifecycle scripts they will still be executed. Using a package manager that doesn’t allow lifecycle scripts by default is the solution here I guess.
I don’t know what the solution is for stuff like [this](https://github.com/nrwl/nx-console/blob/d2fa56509679fc942bbc...) where the editor plugin automatically uses the latest version, or where in general you have little control over what version is used. Any eslint, typescript, nx, prettier, etc plugin will presumably depend on their corresponding package from npm, and if any of those gets compromised then just installing an editor extension could be enough to get you in trouble.
Re: Show HN: Tips to stay safe from NPM supply chain attacks
#19What 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 sou…
Lockfiles are a more standard and probably better way to do this. (People do need to pay more attention to lockfile diffs.)
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!)
Re: Show HN: Tips to stay safe from NPM supply chain attacks
#20Here is the entire guide you need to protect yourself from supply chain attacks as a software engineer. Pick whichever of these will consume the fewest resources over time: 1. review an existing library and all dependencies, and all security updates to them forever (or ensure someone capable does or did) 2. implement the minimal functions you require on top of the language standard library yourself Yes, this is serio…
Advice that you know, or should know, won't and indeed can't be followed isn't serious advice, it's just posturing. "Security engineer" or not, if you stood up in that kick-off meeting and with a straight face proposed that the team spend the first 3 months reviewing React before starting work - you're out, and rightly so.
Security and convenience are always in tension, but there is usually a productive, "sweet spot" middle ground. Your "solution" is way off to one side of that sweet spot. The status quo is probably a little too far off in the other direction. But a happy medium can be found where most teams are fine, most of the time, while retaining the ability to take advantage from the open source ecosystem.