Hacker News Reader

Comment by hmrr | Hacker News Reader

Genuine question as I quite frankly stay the hell away from it: Can malicious NPM packages compromise your build infrastructure?

View on HN

NPM modules can run arbitrary code at install time using the privileges of the user doing the install. So, whatever malicious actions such a user could take, an NPM module could take.

Fortunately there is an option (--ignore-scripts) that prevents all code from running at install time, and there are solutions if specific scripts do need to be run. Such examples are so rare, though, that there is an active proposal to make this option the default.

https://github.com/npm/rfcs/pull/488

If you don't trust the scripts, you don't trust the code. Although this limits one attack vector, the issue is just kicked down the road to `import`/`require` time.

It does reduce the attack surface a little, though. For example, if you install a package A which depends on B for some obscure feature, and B gets compromised, but you never use A in a way that imports/requires the code in B, then you can potentially dodge that landmine.

Similarly, if you are downloading npm packages that provide frontend-only code, that is only run in the context of the browser's sandbox, then you don't have to worry about arbitrary code execution (although a malicious frontend package could still exfiltrate user passwords, among other things).

Yeah it's definitely an improvement, but there needs to be something more.

The way dependencies move depending on when you run a yarn/npm install has never been useful. Both for projects initialising a lock, and projects upgrading from a previous locked position.

Reply on news.ycombinator.com