JFrog's New Tools Flag Malicious JavaScript Packages

DevOps security firm JFrog released three open source security tools in response to recent issues with software registry npm to help JavaScript developers detect and prevent the installation of problematic packages.

Software supply chain attacks are becoming a big problem in the open source software ecosystem, with attackers sneaking information stealers, keyloggers, and other types of malware into package managers and repositories, such as npm, RubyGems, and PyPi. In many cases, the packages containing the malicious code have names similar to well-known, legitimate packages. In other cases, the packages themselves have been tampered with. Last week, the maintainer behind two widely used JavaScript libraries intentionally corrupted colors.js and faker.js, causing problems with tens of thousands of JavaScript applications relying on those packages.

"The latest npm incident is just another example in a series of recent open source software vulnerabilities discovered with the potential to wreak major havoc on enterprise systems worldwide," says Ilya Khivrich, JFrog's senior director of advanced technologies and security research. "It's a good reminder that even the software repositories we believe to be trusted can be easily broken in a single day — and thus we should always practice good cyber hygiene."

The new tools — package_checker to verify whether a specific version of a package can be trusted, npm-secure-installer to block packages missing the npm-shrinkwrap-lock.json file, and package_issues_history to monitor packages for problematic updates — are available on GitHub.

package_checker can be used "to actively test new versions of used packages before deciding to update the dependency, or by organizations to monitor all new versions of packages used internally," the company says. The tool looks for hints that the package has been used in supply chain attacks and identifies potential risks with new versions. Signs that the version of the package should not be trusted include a "significant gap" in version numbers, an update for a package that has not been maintained for a long time, discrepancies between the version in npm and in the GitHub repository, and how recently the version was posted.

Instead of using npm install (official installer) to globally install packages, developers can use the wrapper npm-secure-installer to add security to the installation process. npm shrinkwrap is a built-in mechanism similar to packages-lock.json, which locks the versions of required packages and their descendants for a published package. This means the precise versions of all dependencies are frozen, mitigating the risk of using a recently updated faulty software component. The wrapper tool looks for the lock file for the package and, if it is missing, refuses to install the package.

A note about using npm-secure-installer: It errs on the side of caution by imposing a requirement (having the shrinkwrap lock file) that even some legitimate packages do not meet, says Khivrich.

package_issues_history is an "experimental tool" that tries to determine whether a new package version includes problematic code. The tool tracks the package's GitHub issues in the days following a version release to see whether there are any problems reported. The developer determines whether the issues are problematic.

"For a popular enough library, the number of dependent projects might be large enough so that the surplus issues resulting from a breaking change will be significant with respect to the 'background' issues which are unrelated to the change," the company says.

The tool is intended more for researchers trying to catch early signs of trouble rather than a concrete step in the developer workflow, Khivrich says.

While package_checker and package_issues_history will raise flags over suspicious-looking package versions, they can miss other indicators that were not considered or flag benign versions by mistake, Khivrich says. There is no perfect method to distinguish malicious or corrupted packages from legitimate ones, so protecting against supply chain issues is an "ongoing industrywide challenge that requires several different protection layers," he says.