Detection and prevention of faulty packages
Modern software projects usually consist of open source code. The discovery of the Log4Shell vulnerability raises the extremely security-critical question of who really controls this code and who is responsible for detecting and fixing security problems in the software supply chain.
The deeply disturbing fact is that in many circumstances, new code can be pulled from a repository, used in a project, and run on the machine in a way that is almost invisible to the developer. Trust in the code from public repositories is ingrained in many package managers, but this trust may be misplaced. This incident shows us how trust that has been built and established for years can one day be broken, so that even new versions of a robust package can no longer be trusted.
The potential risk of installing npm packages
The usual way to constitute the use of certain versions of the npm dependencies in a project is to use the package lock.json file that specifies the allowed versions of the libraries. The recommendation is package-lock.use json and specify the exact versions of the dependencies whenever possible. However, it is a little-known fact that the current npm installer – if it installs a package globally (npm is run with -g or -global) – will open the package-lock file.json does not pay attention and unsuspectingly downloads the latest available version of each package dependency, according to the ones in the package file.json specified dependencies. That’s why users find that their applications are using hijacked versions of the colors package, even though they were sure they were using package-lock.json was “protected”.
Installing the latest version of an npm package (a dependency) without prior verification can be dangerous (for example, if the package was hijacked in its latest version, as in the case of Faker and Colors) and because it can destroy the code that uses the dependency (for example, due to API changes in the latest version of the dependency).
Newly released OSS tools for npm packages
In response to cases such as those mentioned earlier, the JFrog Security Research Team has released three OSS tools aimed at detecting and preventing the installation of potentially faulty npm packages:
- package_checker: A tool that gives an indication of whether a particular version of a particular package can be trusted. The tool looks for telltale signs of packages being used for supply chain attacks. It can also be used to identify potential risks with newly released versions.
- npm-secure-installer: A secure wrapper for npm install that refuses to install packages globally that do not contain an npm shrinkwrap lock file.
- package_issues_history: An experimental tool that aims to monitor problematic package updates to find them even before it is discovered that a particular package version has introduced a malicious change. Malignant changes can occur in different ways, and apart from extreme (and probably rare) cases, it is difficult to define a rule for such changes that are not also triggered by benign changes.
The JFrog Security researchers see these tools as a small step in the right direction to identify critical problems in the modern software supply chain and at the same time to identify appropriate solutions. In addition to supporting the developer community with information and open source tools to deal with the latest software security threats, JFrog provides developers and security teams with advanced software supply chain security features using JFrog Xray.