So it is a good thing that JFrog, a company that uses DevOps principles to secure the software supply chain, has released three new open source programs to detect and block the installation of malicious npm packages.
Securing the Supply Chain
These are a direct response to the colors and faker fiasco. In that one, their maintainer deliberately corrupted the packages. JFrog, along with many others, is getting concerned about open source software supply chain security.
In the npm ecosystem, new code is all too often pulled from a repository, used in a project, and put into production without ever being checked for problems. Indeed, far too many times, the developer may not even be aware that one of the components has been changed, never mind corrupted. We can no longer afford blind trust in open source code from public repositories.
This happens because, as JFrog’s senior director of advanced technologies and security research — who joined the company last year when JFrog acquired Vdoo, Ilya Khivrich wrote:
The common method for enforcing the use of specific versions of the npm dependencies in a project is using package-lock.json file, which specifies the allowed versions of the libraries. We highly recommend using package-lock.json and specifying exact dependency versions whenever possible. It is a little known fact, however, that the current npm installer — when installing a package globally (npm run with -g or — global) — does not honor the package-lock.json file and will happily download the latest available version of any package dependency, according to the dependencies specified in the package.json file. This is why users found their applications were using hijacked versions of the colors package, even though they were certain they were “protected” by package-lock.json.
This needs to be patched and it needs to be patched now. But that’s a problem for npm and its developers, not JFrog.
To help deal with this fundamental software supply security issue in the meantime, JFrog has made three new open source npm security tools available on GitHub. These programs are:
- package_checker: a tool providing an indication of whether a specific version of a given package can be trusted. The tool looks for tell-tale signs of packages used in supply-chain attacks and can be used to identify potential risks with newly released versions. Among the checked conditions are 1.) A significant gap in version numbers (i.e., jumping from 5.5.3 to 6.6.6, like in the case of the faker npm package) 2.) new updates to unmaintained package; a discrepancy between the versions appearing in npm and its linked GitHub repository; and how recently the version was posted, since a very new version has not been vetted yet, and may contain malicious code.
- npm-secure-installer: a secure wrapper for npm install, which will refuse to globally install packages that do not contain an npm-shrinkwrap lock file.
- package_issues_history: an experimental tool aiming to monitor for problematic package updates, in order to find them even before it is discovered that a certain package version introduced a breaking change.
With these tools, Khivrich added, you’ll be better able to “maintain good cyber hygiene by validating the security and robustness of each new software package version prior to use, at this time specifically for the npm package repository.”
This won’t solve the problem with bad npm files, but it’s a big step forward.