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.
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.
As LiPoly said, it doesn’t really solve the problem. It’s not useless, it does accomplish something, but not that. Locking dependencies isn’t a security thing, it’s a reproducible builds thing. You can accomplish that by just using a traditional static version of everything, but now you’ve got a maintenance headache as you’re constantly needing to go in and update your dependency versions. You could instead use version ranging, but now you never actually know which version of a dependency any given build is going to end up using. Locking allows you to have the best of both worlds.
To understand how this works, lets take a look at a hypothetical. Lets say you have a code base, and a CICD setup. Additionally you’re using a git-flow style release management where your release version is in master, your active development is in develop, and your feature work is done in feature branches. What you do is setup your version ranges to cover what the semantic versions of things say should be compatible (generally locked major version, and possibly locked minor depending on the library, but unlocked patch). In your CICD for CI builds of develop and feature branches you include a step that updates your lock file to the latest version of a library matching your version range. This insures that your develop and feature branches are always using the latest version of dependencies. For your master branch though, its CI job only builds, it never updates the lock file. This means when you merge a release to master your dependencies are effectively frozen. Every build from the master branch is guaranteed to use exactly the same versions of dependencies as when you merged it.
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).
That won’t prevent typo squatting. This article is a out people wanting to add a dependency to “famousLib” and instead typing “famusLib”.
What probably help more in Go is the lack of a central repo so you actually need to “go get github.com/whoever…” so typo squatting is a bit be a bit more complicated.
On the other hand it will be an easy fix in NPM by simply adding a check to libraries names and reject names that are too similar since it’s centralized.
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.
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.
Yes. I can’t imagine being foolish enough to automatically update your external dependencies when you don’t need to.
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.
As LiPoly said, it doesn’t really solve the problem. It’s not useless, it does accomplish something, but not that. Locking dependencies isn’t a security thing, it’s a reproducible builds thing. You can accomplish that by just using a traditional static version of everything, but now you’ve got a maintenance headache as you’re constantly needing to go in and update your dependency versions. You could instead use version ranging, but now you never actually know which version of a dependency any given build is going to end up using. Locking allows you to have the best of both worlds.
To understand how this works, lets take a look at a hypothetical. Lets say you have a code base, and a CICD setup. Additionally you’re using a git-flow style release management where your release version is in master, your active development is in develop, and your feature work is done in feature branches. What you do is setup your version ranges to cover what the semantic versions of things say should be compatible (generally locked major version, and possibly locked minor depending on the library, but unlocked patch). In your CICD for CI builds of develop and feature branches you include a step that updates your lock file to the latest version of a library matching your version range. This insures that your develop and feature branches are always using the latest version of dependencies. For your master branch though, its CI job only builds, it never updates the lock file. This means when you merge a release to master your dependencies are effectively frozen. Every build from the master branch is guaranteed to use exactly the same versions of dependencies as when you merged it.
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).
That won’t prevent typo squatting. This article is a out people wanting to add a dependency to “famousLib” and instead typing “famusLib”.
What probably help more in Go is the lack of a central repo so you actually need to “go get github.com/whoever…” so typo squatting is a bit be a bit more complicated.
On the other hand it will be an easy fix in NPM by simply adding a check to libraries names and reject names that are too similar since it’s centralized.
I’m with you but I have regrettably been sucked into the node-i-verse against my will.