NIST Releases New Guidelines for Supply Chain Security

By Mike Pittenger, VP of Product Strategy, Black Duck Software

The National Institute of Standards and Technology (NIST) released new guidelines for managing risk in the supply chain. Aside from the legal ramifications of using unauthorized or counterfeit software, the focus of the guidelines centers around the potential risk introduced via third-party software, which includes commercial off-the-shelf (COTS), Government off-the-shelf (GOTS) and open source software (OSS). From a security practitioner’s viewpoint, each of these third-party software “products” introduces unknown risk to internal applications.

Much of NIST’s focus is on the software’s maturity and provenance. This is good advice; better-tested software may be more reliable and easier to maintain over time, and ensuring that developers are using source or binaries that match those distributed by the open source community is important.

Additional selection criteria are warranted, but missing from the NIST guidelines. These include the obvious criterion of “no known vulnerabilities” in the component, an OWASP Top 10 issue, but should also include an evaluation of the open source projects historical record for security bugs, and the density of those bugs. While past results are not perfect predictors, they do provide a metric for the community’s overall “security maturity.” Other important factors include the size and complexity of the code base, overall community support, and even the frequency and size of releases (embedded software that can’t be easily updated across a user base may influence an organization to look for larger, more infrequent releases).

Identify and track open source use

NIST highlights out two areas that are often overlooked in supply chain security. First, it recommends maintaining a full inventory of any open source components used by an organization in their own code and in third-party code. Next, it requires organizations “for critical elements in the ICT supply chain to demonstrate a capability to remediate emerging vulnerabilities based on open source information and other sources.”

These two items provide enormous value when managing supply chain risk. State of the art security testing tools, whether static or dynamic, are not necessarily useful at identifying new vulnerabilities in open source software. The tool vendors and open source contributors have reviewed these components for years, and bugs such as Heartbleed and Shellshock are still beyond automated detection capabilities.

“Emerging vulnerabilities” are increasingly common. The Open Source Web Vulnerability Database (OSVDB) reports more than 1,000 each quarter. When these vulnerabilities are disclosed, organizations must be armed to mobilize incident response teams, just as they would for a network intrusion. The first step is understanding where the vulnerable component is used, followed by prioritization and remediation based on the criticality of each affected application. The ability to identify all of the applications that use a particular component quickly, including with version, is critical to mitigating risk.

Managing supply chain risk requires organizations to understand risk introduced by third-party software, whether open source or COTS. The NIST guidelines are a good start. Building and enforcing internal policies regarding third-party software, and maintaining an inventory (or bill of material) for each application in use, makes responding to the inevitable “emerging vulnerabilities” in these components simpler, faster, and more effective.