Here's what you need to know about the new OpenSSF npm security best practices.
In August, the Open Source Security Foundation (OpenSSF) unveiled its ambitious plans to overhaul software security supply chains. Those plans include better securing the production of open source code, improving vulnerability detection and remediation, and shortening patching response time.
David A. Wheeler, director of open source supply chain security at the Linux Foundation, which runs the OpenSSF, said that, on average, npm packages contain less code than other kinds of packages.
"They're much smaller. Typically, an order of magnitude smaller. When each package does less, you need more packages to do something."
—David A. Wheeler
Here are key best practices from the new OpenSSF guidelines — and what you need to know about them.
A solid first step
With its guide, available on GitHub, the OpenSSF Best Practices Working Group provides an overview of supply chain security features available in npm, describes the risks associated with using dependencies, and lays out best practices to reduce those risks at different project stages. For example, the guidelines cover how to set up a secure CI configuration, avoid dependency confusion, and limit the consequences of a hijacked dependency.
Romeo said that the team that put this guide together are top-notch experts in the various areas of npm, "and they put together a solid guide." But he said that while this is an excellent technical document, it needs some work on the usability side of things. "When I think of a developer picking up this guide, there are holes in answering 'why' we are doing these various things."
The new guidelines are a solid foundation, but could go deeper in explaining why these steps are necessary, Romeo said.
"By answering why we need dependency management in more detail, the new developer picking up the guide has context on the value of the additional work they are taking on."
Wheeler said that like anything in the world, you can make mistakes, but the OpenSSF guide provided a starting point, and should "help people avoid a lot of mistakes."
"Since this isn't the kind of stuff that's taught in schools, it's really important to have something that people can look at so they know what to, what not to do, and why."
—David A. Wheeler
Karlo Zanki, a reverse engineer at Reversing Labs who has focused his threat research on package managers, said the guidelines are a good starting point for every developer using npm packages in their project.
"They identify a lot of potential project configuration issues that many developers aren't aware of."
Vetting dependencies is priority one
As the primary author of a dozen or so npm packages with roughly one million downloads per month, Larry Maccherone, DevSecOps transformation evangelist at Contrast Security, a maker of self-protecting software solutions, said he was very pleased with the new OpenSSF npm guidelines.
Maccherone said the guidance was concise and thorough, and well aligned with the software security community's best thinking on software supply chain security. "There are no barriers for any package owner to comply with everything in it," he said.
"The fact that it was all pulled together under the trusted auspices of OpenSSF is the biggest way in which this will help. Previously, package owners had to go on a Google-driven expedition and potentially get some bad advice. As a bonus, the document includes references to tools that can enforce much of the guidance."
The guide explained that the first step when using a dependency is to study its origin, trustworthiness, and security posture. It recommends using the criteria in projects like Envoy proxy to determine if a dependency should be used.
Other measures valuable in evaluating dependencies are use of OpenSSF Security Scorecards to learn about the current security posture of the dependency, use of deps.dev to learn about the security posture of transitive dependencies, and use of npm-audit to learn about existing vulnerabilities in the dependencies of the project.
Andrew Obadiaru, CISO of Cobalt Labs, a penetration testing company, said the new best practices go to the core challenges for developers around the use of package manager for JavaScrip.
"If adopted they will help developers reduce the security risks associated with using open-source dependencies. Specifically, the need to extensively study the origin, trustworthiness, and security posture of any dependencies prior to their use."
Focus on typosquatting
The OpenSSF guidelines will help developers secure the software supply chain with a multi-pronged approach, explained Divya Rao, a dependency management specialist at Endor Labs, a dependencies management company. "Using scorecards, deps.dev to learn of the security posture of transitive dependencies, and npm-audits will help, as well as being aware of typo-squatting and correctly identifying a package name," he said.
Although the npm performs scans to detect typosquatting, no system is perfect, so developers must remain vigilant and always identify the GitHub repository for the package and assess its trustworthiness through characteristics, such as the number of contributors, the OpenSSF guide noted.
It also advises developers to scrutinize the use of uppercase letters in package names, a common tactic used in typosquatting attacks. For example, a package named jsonstream could be confused with a malicious one named "JSONStream".
Homographic attacks — where a package's name contains non-ASCII characters that resemble ASCII ones — is less of a problem now because npm doesn't support non-ASCII characters in package names.
However, that can vary from registry to registry so developers need to check the policies of any registries in use to make sure the non-ASCII character rule is in use.
A new addition to the software supply chain security toolbox
With pressure on software development teams to reach higher release velocity, there's an environment of ignoring security risks and treating security as a bottleneck, Rao said.
Also, many development teams are not aware of npm attacks, and more importantly, are not aware of the tools at their disposal, Rao said. That's the value of these new best practices.
"Simply following what the above guidelines recommend will effectively reduce the risks and help in keeping your software supply chain better protected."
ReversingLabs' Zanki said the guide did describe the most common security threats encountered through the npm ecosystem, like typosquatting and dependency confusion. And OpenSSF's Security Scorecards are a good example of dependency evaluation tool.
However, they currently only cover GitHub projects, and aren't universally applicable across all npm packages, leaving blind spots. The next step needed to create secure software solutions are tools that can actually evaluate trustworthiness and security posture of dependencies for the developers, he said.
"Dependency evaluation is identified as a problem, but leaving such evaluation to developers' best judgment leaves wide-open doors for malicious actors."
- Get up to speed on software supply chain security
- Get report: Software supply chain and the SOC: Why end-to-end security is key
- Report: Supply chain security top of mind for devs — but tampering detection lags
- WH memo calls for supply chain security, takes a step closer to mandating SBOMs
- NVD Analysis 2022: Why you need to modernize your software security approach
- SBOM: What it is — and why it matters for software supply chain security
- Get a free SBOM and software supply chain risk report