How SBOMs Strengthen the Software Supply Chain

The need to strengthen and secure the software supply chain has gained heightened awareness in recent months. The Biden administration, for example, issued an executive order that outlined security measures for critical software use and specifically mentioned open source provenance and the need for companies to provide a Software Bill of Materials (SBOM) as part of their efforts to improve software supply chain security. 

In this article, we’ll explain what an SBOM is and point you to additional resources outlining best practices and other key information.

What’s an SBOM?

According to the National Telecommunications and Information Administration (NTIA), an SBOM is a formal, machine-readable inventory of software components and dependencies — a list of ingredients, if you will — containing information about all known components and their hierarchical relationships.

Such an inventory list improves software transparency and allows for the discovery and understanding of new vulnerabilities. “An SBOM allows an organization to understand what components are active on its systems and networks. When any new flaw in a particular component is discovered, the organization can quickly evaluate whether it is using the component, and therefore whether it is at risk,” says NTIA.

In “Determining the Source of Truth for Software Components,” Kate Stewart and Mark Gisi note that SBOMs are also “a requirement for the successful execution of the following DevOps tasks:”

  • Open source and third-party license compliance
  • Security vulnerability management
  • Malware protection
  • Export compliance
  • Functionally safe certification

Requirements and Tools

The “NTIA is working on guidance to help organizations comply with the Biden administration's executive order that requires vendors to have an SBOM,” says Sean Michael Kerner. Toward this end, the NTIA recently released the minimum required elements of an SBOM covering the following three categories: 

  • Data fields: Baseline information about each software component
  • Automation support: The ability to auto-generate SBOMs in machine- and human-readable formats
  • Practices and processes: How and when SBOMs should be generated and distributed

Stewart and Gisi note that the “holy grail of an effective SBOM design” involves two main points:

  • Defining a commonly agreed-upon data structure that best represents a software component
  • Devising a method that uniquely and effectively identifies each software component

Additionally, they state that “finding the right granular level of representation is critical. If it is too large, we will not be able to represent all the component types and the corresponding meta-information required to support the various DevOps tasks. On the other hand, it may add unnecessary complexity, cost, and friction to adoption if it is too small.”

The good news, says Allan Friedman, Director of Cybersecurity Initiatives at NTIA, in a presentation at DevOpsConnect 2021, is that there are already data formats to help convey this information. “The three that the community has settled on as the consensus SBOM standards,” he says, are:

  • SPDX — An open standard for communicating SBOM information developed by the SPDX workgroup under the Linux Foundation
  • CycloneDX — A lightweight SBOM standard with origins in the OWASP community
  • SWID Tags — An ISO standard providing a set of data elements that identifies information such as the component’s name, version, developers, and relationships between software products

The transparency made possible by an SBOM, however, is not about dictating what is good or bad, says Friedman. “It is about allowing everyone to make the right, risk-based decisions... And, you can’t make good risk-based decisions unless you know what you have.”

As NTIA states, an “SBOM will not solve all software security problems, but will form a foundational data layer on which further security tools, practices, and assurances can be built.”

Learn More

FOSSlife Newsetter

Comments