I don’t know much about NPM (having avoided JS as much as possible for my entire life), but golang seems to have a good solution: ‘vendoring’. One can choose to lock all external dependencies to local snapshots brought into a project, with no automatic updating, but with the option to manually update them when desired.
I don’t think that that’s a counter to the specific attack described in the article:
The malicious packages have names that are similar to legitimate ones for the Puppeteer and Bignum.js code libraries and for various libraries for working with cryptocurrency.
That’d be a counter if you have some known-good version of a package and are worried about updates containing malicious software.
But in the described attack, they’re not trying to push malicious software into legitimate packages. They’re hoping that a dev will accidentally use the wrong package (which presumably is malicious from the get-go).
Ah, good. I wonder why it isn’t used more often – this wouldn’t be such a huge problem then I would hope. (Let me guess – ‘convenience’, the archenemy of security.)
Because it doesn’t really solve much. After every update of external libraries, do you go through all the diffs to see if there is malicious code? Of course you don’t. And even if you would, it’s not even always possible to spot it. So all locking packages does is postpone the problem to when you eventually update. As an added bonus, you’re now vulnerable to all the legitimate issues that get fixed in those updates you’re not installing regularly.
I don’t know much about NPM (having avoided JS as much as possible for my entire life), but golang seems to have a good solution: ‘vendoring’. One can choose to lock all external dependencies to local snapshots brought into a project, with no automatic updating, but with the option to manually update them when desired.
I’m with you but I have regrettably been sucked into the node-i-verse against my will.
I don’t think that that’s a counter to the specific attack described in the article:
That’d be a counter if you have some known-good version of a package and are worried about updates containing malicious software.
But in the described attack, they’re not trying to push malicious software into legitimate packages. They’re hoping that a dev will accidentally use the wrong package (which presumably is malicious from the get-go).
NPM has that as well. In fact most languages and build tools support that. It’s actually rare to not have support for that these days.
Ah, good. I wonder why it isn’t used more often – this wouldn’t be such a huge problem then I would hope. (Let me guess – ‘convenience’, the archenemy of security.)
Because it doesn’t really solve much. After every update of external libraries, do you go through all the diffs to see if there is malicious code? Of course you don’t. And even if you would, it’s not even always possible to spot it. So all locking packages does is postpone the problem to when you eventually update. As an added bonus, you’re now vulnerable to all the legitimate issues that get fixed in those updates you’re not installing regularly.