Today, the ESLint package for NPM was compromised. In short, a publisher for that package had his account hijacked, and a new version of the package was pushed out that fetched NPM tokens from anyone who used it.
In ESLint's postmortem of the event, they state that the malicious versions of ESLint were unpublished from NPM, and the Pastebin page containing the malicious code was taken down. In addition, all NPM tokens published before 2018-07-12 at 12:30 UTC were revoked.
The NPM team was very quick to mark the issue as resolved after the tokens were revoked. So, according to them, there should be no additional risk in downloading new packages anymore.
However, there's a significant issue they're missing.
If this were an issue of any other personal information being stolen besides NPM tokens, they would be correct in stating that the issue is completely resolved with the fixing of the ESLint package and the securing of the publisher's account. However, these are NPM tokens, which authorize users to publish their own packages to NPM.
So, what if other packages were compromised? Hacker News commenter thenewwazoo gives a good theoretical example showing that this issue is much bigger than the NPM team may know:
If NPM tokens were compromised, then it doesn't matter that those tokens were revoked, if other packages were compromised as a result. The fact that the NPM team so quickly marked the issue as resolved shows that they really just care about pushing the issue under the rug asap.
Honestly, I believe this incident highlights some far-reaching issues with the NPM paradigm in development. In short, developers are putting far too much faith in a team of far too few people to make sure the sources of their imported code are secure.
It's true that NPM is open source, which theoretically is a good boon to the security of the system. But when the team is really only made up of a handful of contributors, and also are notoriously closed when it comes to accepting input through issues and pull requests, it really shows how fragile NPM can be. Developers need to be incredibly careful with the code they import, and frankly, when it comes to NPM, which is widely used in the current state of software development, they aren't.