3 ms·

By getting off NPM entirely and new projects internally banned from using it from day ome. Luckily all the backend stuff isn't in javascript which is 80% of the

• hmrr 5y ago
  Genuine question as I quite frankly stay the hell away from it: Can malicious NPM packages compromise your build infrastructure?
  • christophilus 5y ago
    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.
    • dane-pgp 5y ago
      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 https://github.com/npm/rfcs/pull/488
      • mhio 5y ago
        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.
        • dane-pgp 5y ago
          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).
          • mhio 5y ago
            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.