Government-mandated SBOMs to throw light on software supply chain security

President Biden’s executive order (EO) on cybersecurity, released on May 12, is a sprawling and comprehensive document that aims to redress weaknesses in the digital security ecosystem. It is peppered with nearly 50 actions that the federal government must take within extraordinarily tight timeframes, signaling the urgency of the cybersecurity crisis the country faces.

Several parts of the EO seek to shore up software security. This long-overlooked and arcane topic has taken on new urgency following the SolarWinds and Microsoft Exchange software supply chain hacks.

The first software security deadline in the EO, assigned primarily to the Commerce Department’s National Institute of Standards and Technology (NIST), is to publish a definition of what constitutes “critical software,” which in turn will trigger actions by other government agencies. NIST’s deadline for producing this definition is June 26, which is why the agency held a quickly organized workshop on June 2 and 3 attended by around a thousand interested parties.

Fifteen days after the release of NIST’s definition of critical software, another arm of the Commerce Department, the National Telecommunications and Information Administration (NTIA), will publish “minimum elements” of something that has been evolving over the past several years in the cybersecurity realm, a software bill of materials, or SBOM.

What is an SBOM?

An SBOM is “a dependency rack,” Allan Friedman, lead on the government’s SBOM activities and director of cybersecurity initiatives at NTIA, said at the NIST workshop. “At its core, it’s not that complicated. It’s saying, ‘hey, this software that I have. What’s in it, and what in turn is in [the components that make up the software]?'”

An SBOM is effectively an ingredient list or a nested inventory, a “formal record containing the details and supply chain relationships of various components used in building software,” the EO states. The EO requires NTIA to produce three proposed minimum elements that should go into any SBOM:

• Data fields (such as supplier name, component name, version of the component, and more)
• Operational considerations (such as frequency of SBOM generation, depth of the dependency tree, access to SBOM data, and more)
• Support for automation (making sure the data can be produced at scale and consumed at scale using three different data formats already standardized, including three leading file formats known as SPDX, CycloneDX, and SWID).

NTIA is also examining several related issues, such as how SaaS (software as a service) or cloud data might differ from on-premises software and how to think about more sophisticated supply chain threat models.

SBOMs as a software disinfectant

Security veteran Joshua Corman, a big proponent of SBOM and currently a visiting researcher at the Department of Homeland Security’s Cybersecurity and Infrastructure Security Agency (CISA), articulated at least three use cases for SBOM before the House Oversight and Government Reform Committee’s Subcommittee in October 2017.

• A buyer could distinguish good from bad software products at procurement time, which might ultimately and cumulatively drive potentially harmful software products out of the market if the “sunlight is the best disinfectant” theory holds.
• When a new vulnerability becomes known, security professionals would be able to quickly determine if they are affected and where they are affected.
• Companies would be able to track when product support for software expires, given that the SBOM might be the only way to know that security updates for the product will no longer arrive.

For some security professionals, SBOMs in a private sector organization could be a sign of the organization’s overall caliber. “It’s a litmus test question to understand for myself what I am getting into,” Sounil Yu, former chief security scientist at Bank of America and now CISO and head of research at JupiterOne, tells CSO. “Am I going into a situation where there’s complete chaos and disorganization, or a completely antiquated tech stack that would create for me, as a CISO, hazards that I’m going to have to deal with because the tech stack and the maturity of the organization are poor?”

Transparency could lead to greater trust

More fundamentally, SBOM experts say it’s about transparency, which leads to greater trust. “You don’t need trust if you have transparency,” Yu says. “You need trust because you don’t have transparency. If I can produce for you an SBOM, keep it up-to-date on a regular basis, I’m being transparent, which reduces your need to trust me as much.”

The transparency delivered by SBOM aligns with the repeated reference to “zero trust” throughout the executive order. “We take the concept of zero trust and apply it to vendors,” Yu says. “That means if we start with zero trust, we need to compensate that zero trust with transparency and that transparency comes from things like SBOM.”

Bills of material are not new

Although a relatively new concept in cybersecurity, bills of material have been part of other industries’ requirements for decades. American engineer, innovator, and management specialist Edward Deming pioneered the concept of a bill of materials at Toyota in the 1940s. Lately, the medical industry has been building resilient technology supply chains using SBOMs, with Philips Medical and Siemens Healthineers putting SBOM theory into practice over the past several years.

“Bills of material are standard in every other industry,” Jennings Aske, senior vice president and CISO at New York-Presbyterian Hospital, tells CSO. “Why not software?”

Simply exposing the ingredients of software would improve the safety and security of software products, although many organizations are likely to object to such exposure. “I liken this to automotive safety,” Aske says. “When Ralph Nader was pushing for seatbelts, people thought, ‘well, they’re not needed,’ or ‘it’s government overreach’ or ‘customers aren’t going to like it.’ And then companies like Volvo figured out this actually could be something they could use to sell their products. They could charge more.”

“I think we should take SBOM as a concept, take things in the executive order, make them national across all industry sectors, and give people time to come into compliance with being able to create SBOMs,” Aske says.

NIST will take the minimum elements of the SBOM that NTIA produces and include them in preliminary baseline security guidelines for commercial software sold to the federal government sometime around November 8. Within a year of the executive order’s date, the Federal Acquisition Regulation (FAR) Council will incorporate the guidelines into contracting language for all federal contractors.

How much of a spill-over effect will SBOM have?

The question then becomes, will the federal government’s massive purchasing power spill over to create secure software products for the private sector? Private sector companies are likely to buy many if not most of the same products that the federal government purchases.

“There are only so many companies that directly do business with the federal government, and they’re going to be obviously directly impacted,” Yu says. “The second-order effect, those companies that sell to those companies that sell to the federal government, is much greater.” The third-order impact is probably close to 100%, Yu estimates.

Aske says that “there’s going to be a trickle-over effect. It’s not trickle-down; it’s trickle-over. I can guarantee that we have vendors the government doesn’t use. We have over 1,400 device manufacturers that supply our devices. There’s going to be overlap, but it’s not going to be entire.”