Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Tips to stay safe from NPM supply chain attacks

github.com

Post reply on HN
Print view View original

1–10 of 56 posts

Show HN: Tips to stay safe from NPM supply chain attacks

#1

Post by bodash »

Hi everyone, given the recent increase of attacks on the NPM supply chain, I've put together a list of tips and tricks to help developers stay secure on this specific topic: https://github.com/bodadotsh/npm-security-best-practices

I'd love for you to check it out, and contribute your own insights and best practices to make this a comprehensive resource for the community.

Cheers!

Show HN: Tips to stay safe from NPM supply chain attacks
github.com

Re: Show HN: Tips to stay safe from NPM supply chain attacks

#3

Post by privatelypublic »

turtleyacht wrote: post #2

For reducing external dependencies, it would be nice to somehow know every call made to a package, generating the call tree to replace. That becomes the API of the internal, replacement package.

Not sure that's possible with JS.

Re: Show HN: Tips to stay safe from NPM supply chain attacks

#6

Post by HoyaSaxa »

For most projects, overriding every single transitive dependencies to be pinned is impractical.

Instead, for those using npm, I'd highly suggest using `npm ci` both locally and of course on CI/CD. This will ensure the (transitive) dependencies pinned in the lockfile are used.

TIL on the `npm install --before="$(date -v -1d)"` trick; thanks for that! Using that to update (transitive) dependencies should be really helpful.

For those using GitHub Actions, I'd also recommend taking advantage of the new dependabot cooldown feature to reduce the likelihood of an incident. Also make sure to pin all GitHub Action dependencies to a sha and enforce that at the GitHub repo/account level.

Re: Show HN: Tips to stay safe from NPM supply chain attacks

#7

Post by ashishbijlani »

Plug: 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).

Re: Show HN: Tips to stay safe from NPM supply chain attacks

#8

Post by condiment »

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.

Re: Show HN: Tips to stay safe from NPM supply chain attacks

#9

Post by cj »

privatelypublic wrote: post #3
turtleyacht wrote: post #2

For reducing external dependencies, it would be nice to somehow know every call made to a package, generating the call tree to replace. That becomes the API of the internal, replacement package.

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.

Re: Show HN: Tips to stay safe from NPM supply chain attacks

#10

Post by minitech »

condiment wrote: post #8

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 sou…

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