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

21–30 of 56 posts

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

#21

Post by janstice »

DanHulton wrote: post #19
minitech wrote: post #10

Earlier quoted context omitted.

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…

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.

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

#22

Post by eastbound »

lrvick wrote: post #12

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

Your suggestion is that I should reimplement React from scratch to avoid supply chain attacks. Like an American fab should extract ore locally to prevent shortages.

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

#24

Post by jimbohn »

This needs to be solved at the language level by defining whitelist-like contexts. Some sort of

  with MyContext(allow_sys_cmds=false, network=false, read_disk=false):
     ...
I've seen at least a paper trying to bolt-on such a feature on golang but it's way too convoluted. Of course this doesn't solve everything, especially for languages with magic/collateral effects like running logic on module import.

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

#25

Post by em-bee »

captn3m0 wrote: post #11

Like the projects but not a Show HN, see the guidelines.

it isn't any of these:

Off topic: blog posts, sign-up pages, newsletters, lists, and other reading material. Those can't be tried out, so can't be Show HNs.

it's not reading material.

it's a set of instructions that you can actually try. so i think it fits.

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

#26

Post by bodash »

Rockslide wrote: post #23

That first recommendation of pinning exact versions of each and every dependency is borderline insane. That's exactly what lockfiles are for. Which are used by default.

The lockfile is updated _after_ any new malicious version is downloaded and installed. If we pinned the exact version, `npm install` will _not_ download and execute any new published versions.

That's why we use `npm ci` or `--frozen-lockfile` to install the exactly versions as lockfiles. But, by default, the `^` operator and just `install` command will check registry for any new releases and download them.

The primary arguments against pinning versions are missing security updates and increased maintenance overhead. But given the patterns we've seen, the attackers really _hope_ we automatically install new releases

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

#27

Post by Rockslide »

bodash wrote: post #26
Rockslide wrote: post #23

That first recommendation of pinning exact versions of each and every dependency is borderline insane. That's exactly what lockfiles are for. Which are used by default.

The lockfile is updated _after_ any new malicious version is downloaded and installed. If we pinned the exact version, `npm install` will _not_ download and execute any new published versions. That's why we use `npm ci` or `--frozen-lockfile` to install the exactly versions as lockfiles. But, by default, the `^` operator and just `install` command will check registry for any new releases and download them. The primar…

npm install does install the exact versions from the lockfile. Even though this misconception gets repeated in every single thread about npm here on hn. npm install will not randomly update your direct dependencies, let alone transitive dependencies.

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

#28

Post by aiahs »

One 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 browsers for Dev/Internet?

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

#29

Post by Yoric »

jimbohn wrote: post #24

This needs to be solved at the language level by defining whitelist-like contexts. Some sort of with MyContext(allow_sys_cmds=false, network=false, read_disk=false): ... I've seen at least a paper trying to bolt-on such a feature on golang but it's way too convoluted. Of course this doesn't solve everything, especially for languages with magic/collateral effects like running logic on module import.

For context, it's called "an effect system". IIRC, these were developed in the 80s-90s, but as far as I know, OCaml is the only industrial language that offers any kind of support for effects.

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

#30

Post by jimbohn »

Yoric wrote: post #29
jimbohn wrote: post #24

This needs to be solved at the language level by defining whitelist-like contexts. Some sort of with MyContext(allow_sys_cmds=false, network=false, read_disk=false): ... I've seen at least a paper trying to bolt-on such a feature on golang but it's way too convoluted. Of course this doesn't solve everything, especially for languages with magic/collateral effects like running logic on module import.

For context, it's called "an effect system". IIRC, these were developed in the 80s-90s, but as far as I know, OCaml is the only industrial language that offers any kind of support for effects.

Didn't know about the terminology, thanks!
Post reply on HN