1. 27
  1.  

  2. 6

    Like many security holes, this could’ve been much worse.

    Key point:

    Of course you could run your own internal Maven repository for your company and have every project rely on that exclusively, with only carefully reviewed and verified packages being imported there. Most won’t have time to be so careful about dependencies.

    If you’re at a company that’s producing apps for internal or external use, you need to be using an internal managed repository, otherwise you’re wide open to these kinds of attack vectors. And this is not a new problem, it’s been around for decades.

    1. 5

      One really important difference between this and the EventStream problem is that in this case, the repo itself was not compromised. The attacker didn’t trick the maintainer into handing over control, and they didn’t push an update to the repo. This suggests that the two most-commonly said “fixes” for the npm issue, “Pay open source maintainers money” and “Don’t auto-update your dependencies”, aren’t sufficient to prevent dependency attacks.

      A full STAMP analysis of both these attacks (and perhaps also the Leftpad attack) would be a really interesting essay.