NPM by virtue of its popularity and the vagaries of the ecosystem is always going to be a prime target for attackers, and people (maintainers) will always be a weak point.
I agree generally, but I also think it's important to point out that in the NPM ecosystem it is culturally acceptable and even encouraged to install even trivial dependencies to avoid reinventing the wheel. Philosophically I completely agree with this, though practically we see the result and it is not good. The left pad debacle should have been a huge wake up call, but not really much seems to have changed after that.
As long as developers in the ecosystem are cavalier about installing huge chains of dependencies, NPM will be an attractive target for attackers.
Even though we wish it were not so, cultural problems seem to be the hardest technical problems to solve.
Most of these attacks have nothing to do with installing trivial dependencies. It’s usually because the authors npm tokens got hacked; often due to github actions.
The issue is that github actions has too many security gaps that are easy to miss.
No. It is partially due to trivial dependencies. With so many dependencies it is very difficult to evaluate the security posture of all the teams that are inserting themselves into your code.
When I publish commercial software for Unices that use shared object libraries, one of the things we do before publishing is review known vulnerabilities of our 10 dependencies. That is a tractable number. I get a senior engineer to spend time with an intern and step them through the evaluation criteria.
If the team managing a particular library grows lax over time with respect to responding to vulnerabilities, we move away from using that library.
And we can do these things because there are a tractable number of dependencies.
But yes, also GitHub is not pure as the driven slush. I agree with you on that.
Fair point, although when you have dependencies from dozens or hundreds of different publishers, the risk is much higher because it only takes one getting compromised. If instead you only had a handful of core things, there's less surface area
IPCMSes make it somewhat easy to MitM SMS. If your system poops a cookie in the wrong place it doesn't matter if the secret is in someone's head or if it's in a hardware dongle, like you say... the hacker is "in".
My recommendation for bad guys is to not attack the part of the system where it is strong. Just sniff around a bit until you find the weak part and attack that.
Also remember most devs couldn't use a static analysis tool to save their lives (which is why mythos is relevant.) I suspect that a 15 year old copy of Fortify or CoVerity could find bugs mythos missed.
And if that doesn't work, just start scanning github repos for entropy. That's where the credentials that were accidentally published live.
Yeah that’s fair. It’s only as secure as the weakest link.
That was one of the promises of wasm was sandboxing npm packages independently. Not sure what happened with that or not but I’d be curious to know now we’ve had a lot of recent supply-chain publicity.
For example, if every fetched module is sandboxed and even if they got compromised there would be more protection. It would be more “when” not “if” the package is compromised, nip it in the bud.
But then attackers will target the most exposed packages… :)
As long as developers in the ecosystem are cavalier about installing huge chains of dependencies, NPM will be an attractive target for attackers.
Even though we wish it were not so, cultural problems seem to be the hardest technical problems to solve.