“The latest npm incident is just another example of a series of newly discovered open source software vulnerabilities that have the potential to wreak major havoc on enterprise systems worldwide,” said Ilya Khivrich, Senior Director of advanced technologies and security research at JFrog. “It’s a good reminder that even software repositories we believe to be trustworthy can be easily broken in a single day – and so we should always practice good cyber hygiene.”
The new tools — package_checker to check if a specific version of a package is trustworthy, npm-secure-installer to block packets missing the npm-shrinkwrap-lock.json folder, 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 packages in use 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 clues that the package has been used in supply chain attacks and identifies potential risks with new releases. Signs that the package version should not be approved include a “significant discrepancy” 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 released.
Instead of using npm install (official installer) to install packages globally, developers can use the wrapper npm-secure-installer to enhance the security of the installation process. npm shrink wrap is a built-in mechanism similar to packages-lock.json, which locks required package versions and their descendants for a published package. This means that the precise versions of all dependencies are frozen, reducing the risk of using a recently updated faulty software component. The wrapper tool looks for the package lock file and, if missing, refuses to install the package.
Note on use npm-secure-installer: it errs on the side of caution by imposing a requirement (having the shrink wrap lock file) that even some legitimate packages don’t meet, says Khivrich.
package_issues_history is an “experimental tool” that attempts to determine if a new package version contains problematic code. The tool tracks package GitHub issues in the days after a release is released to see if there are any reported issues. The developer determines whether the issues are problematic or not. “For a sufficiently popular library, the number of dependent projects can be large enough that the overage issues resulting from a breaking change are significant relative to the ‘background’ issues that are unrelated to the change” , explains the company.
The tool is aimed more at researchers trying to catch early signs of problems rather than at a concrete step in the developers’ workflow, Khivrich says.
While package_checker and package_issues_history will raise flags on suspicious package versions, they may miss other flags that weren’t considered, or flag benign versions in error, Khivrich says. There is no perfect method to distinguish malicious or corrupt packets from legitimate packets, so protecting against supply chain issues is an “ongoing industry-wide challenge that requires multiple different layers of protection “, he says.