Why SBOMs Are More Important Than Ever

The release of Executive Order 14028 in May 2021 put the term software Bill of materials (SBOM) in the daily vernacular. But why is it so important that every company should have one?

Executive Order 14028 introduced new regulations for companies supplying products or services containing software to U.S. government agencies. The order directed the U.S. National Telecommunications and Information Administration (NTIA) to publish a set of minimum requirements for an SBOM, which it did in July 2021. If this seems fast, it was, but that’s in part because the NTIA has been working since 2018 to define and publish these standards. In some ways, the Executive Order just made the work this team had been doing official.

An SBOM is a tool used when building mature security models. As the industry moves from a DevOps to a DevSecOps model, building and maintaining accurate SBOMs is a crucial step to securing the software supply chain. An SBOM lists all the open source and third-party components in a codebase as well as the component versions and the licenses that govern those components.

While the SBOM standards and best practices outlined in EO 14028 will technically only apply to federal departments and agencies and their technology suppliers, it is likely that—where practicable—they will also be adopted by broader categories of buyers and suppliers across critical infrastructure as a “North Star” for security expectations. In addition, the Executive Order leverages the government’s procurement process and contractual language to drive compliance—a model that could be adopted in the commercial sector.

“This particular Executive Order recognizes that what we’ve been doing, and the pace at which we’ve been doing it, clearly isn’t working. We just need to look at all of the cyberincidents we see on the evening news. This EO recognizes that something different needs to happen, and is effectively a call to arms,” said Tim Mackey, principal security strategist at Synopsys. 

The latest BSIMM12 findings indicate that software risk is business risk, and to effectively manage business risk, companies must address software risk. Any organization that builds software needs to maintain an SBOM for its applications because organizations typically use a mix of custom-built code, commercial off-the-shelf code, and open source components to create software. If organizations don’t know what they have in their applications, they won’t be able to address areas of vulnerability as they are disclosed.

The BSIMM12 report also highlights how companies are responding to the increase in supply chain and ransomware attacks. From malicious supply chain breaches like SolarwindsOrion, to cyberattacks like the one that hit Schreiber Foods in October 2021 and disrupted the nation’s cream cheese supply just before the holiday season, it is increasingly clear that every business is a software business.

The report outlines three categories of security activity that companies in the BSIMM community have adopted over the past year. A key activity is securing the software supply chain, which starts with building and maintaining an accurate SBOM. The concept of an SBOM derives from manufacturing, where a Bill of Materials is an inventory detailing all the items required to create a product. In the automotive industry, for example, manufacturers maintain a detailed Bill of Materials for each vehicle. The BOM lists parts built by the original equipment manufacturer itself as well as parts from third-party suppliers. When a defective part is discovered, the auto manufacturer knows precisely which vehicles are affected and can notify vehicle owners of the need for repair or replacement.

The SBOM guidelines in Executive Order 14028

It’s important to remember that the guidance released in July describes the minimum regulatory elements. Your security teams should expect the guidelines around SBOM regulatory compliance to continue to develop. For now though, the NTIA has defined the minimum elements of an SBOM, and has organized those elements into three categories.

• Data fields
• Automation support
• Practices and processes

Data fields

Data fields capture and maintain baseline data about each component so that it can be tracked across the software supply chain. This allows you to map the component to other sources of useful data, like vulnerability or license databases. The minimum required data fields are

• Supplier name
• Component name
• Component version
• Other unique identifiers
• Dependency relationship
• Author of SBOM data
• Timestamp

While this information seems pretty basic, it can be surprisingly complicated to capture. Product names, for example, can be obscured by any number of issues, from mergers and acquisitions, to rebranding, and even to typos that have come down in the codebases. There are a number of tools that can help you scan for and capture this information.

Automation support

In order to make SBOMs useable at scale and across organizations, and because the goal is to automate them, they need to be machine readable. The NTIA has approved the following formats:

• SPDX (software package data exchange)
• CycloneDX
• SWID (software identification)

Practices and processes

It’s still early days in defining the practices and processes that the NTIA will require for SBOM use. However, some preliminary guidelines have been released that describe how SBOMs should be distributed and shared. The NTIA document even includes a section on accommodating mistakes that acknowledges that in industries where velocity is crucial to success, expectations should not require perfection. This section reiterates that the overarching objective of these guidelines, EO 14028, and the SBOM process itself is to secure the software supply chain while moving quickly, and continuing to improve our security practices and processes.

Evolution of the CISO

We must ensure that the evolving CISO role supplies what our future application, product, or software security program requires. I’m using ”CISO” here as shorthand for the role (or combination of roles) that make certain software engineering and operations processes are producing, deploying, and maintaining an acceptably secure application and product portfolio.

Some CISO roles seem to be moving to be merely a governance charter—the tool purchaser or the traffic cop. Although having many silos of application, cloud, configuration, container, infrastructure, and other security ownership might help us bridge the gap between no capability and some capability, it almost certainly won’t get the entire business to an acceptable—and reliable—level of software security maturity. Instead, the CISO should evolve to include many facets and encompass a variety of roles.

Voice of the People. This CISO role must be an executive sponsor and visible spokesperson for security change—a catalyst for stronger governance, but governance that is federated into the organization in a planned and coordinated fashion. Most security, development, and operations groups can figure how to make something mostly functional—the cloud, containers, orchestration, security testing in builds, infrastructure-as-code, and so on. This facet of the CISO role must be a source of know-how that gets translated into the culture, process, and technology everyone uses to get those functional things done without tipping the risk versus productivity balance the wrong way.

In practical terms, the CISO role should continue to include the traditional “make rules and do testing” charter. But the CISO’s application security group is certainly already stretched thin and can’t know everything. They must build bridges and continually consolidate knowledge from all the relevant subject matter expert groups. They must be able to rely on the CISO to define what is and isn’t acceptable relative to code quality, security, and resilience, and then methodically federate into the enterprise the methods and guardrails that validate everyone is staying away from risky behavior while also getting their job done more productively.

To read more, become a BSIMM member.