News, news analysis, and commentary on the latest trends in cybersecurity technology.

The three open source tools flag malicious JavaScript packages before they are downloaded and installed from the npm package manager.

Dark Reading Staff, Dark Reading

January 26, 2022

3 Min Read
Word cloud with javascript in center.
Source: bleakstar via Shutterstock

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.

About the Author(s)

Dark Reading Staff

Dark Reading

Dark Reading is a leading cybersecurity media site.

Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

You May Also Like


More Insights