OpenSSF's npm best practices: A solid first step for software supply chain security — but trust issues remain

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.

With those goals in its sights, OpenSSF released this month a new set of best practices for dependency management and supply chain security for npm, the package ecosystem that serves JavaScript and TypeScript projects.

The npm package ecosystem for software teams is one of the largest in existence. It has grown to include 2.1 million packages. Many JavaScript projects are built on tens or even hundreds of dependencies. The ecosystem is so large that it's considered larger than most other significant programming language ecosystems combined, said Chris Romeo, co-founder and CSO of Security Journey, an application security education firm.

"[The npm package ecosystem] was a tremendous first target because of the dependency complexity in JavaScript applications. With npm, it is not uncommon to see an exponential increase in the number of included packages, hence the reason to start with npm."
—Chris Romeo

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."
—Chris Romeo

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."
—Karlo Zanki

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."
—Larry Maccherone

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."
—Andrew Obadiaru

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."
—Divya Rao

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."
—Karlo Zanki

Keep learning

• Learn more about recent npm attacks 
• See "New U.S. software supply chain guidelines: A roadmap is born"
• Download report: NVD Analysis 2022 — A call to action on supply chain security
• See survey report: Tampering top of mind for dev — but detection lags
• Explore solutions for improving your software supply chain security