Software bills of material face long road to adoption

There are few things the fractious community of cybersecurity experts and researchers can agree on. One of the rare exceptions is the need for more widespread use of software bills of materials, or SBOMs, a tool that lists the components of a given piece of software. 

With that information in hand, cybersecurity defenders are far better positioned to find and fix bugs. Though they are far from widely deployed, the use of SBOMs has been endorsed by a who’s-who of the cybersecurity community. The landmark Cyberspace Solarium Commission report urged that they be required in software bought by the federal government. The Cyber Safety Review Board’s examination of the log4j vulnerability cited SBOMs as a key tool in preventing another such disaster.

Implementation remains a challenge, however, not least because of the technology industry’s need for a clear understanding of precisely what information is needed to comply with such a regime and how it will be used.

Despite the groundswell behind SBOMs, key entities within the federal government are moving slowly to require their use. Rather than mandate their inclusion in software purchased by the federal government, the Office of Management and Budget only made it optional as part of a September memo for agencies to require SBOMs in federal IT contracts. And in the rush to pass the end-of-year National Defense Authorization Act, a provision that would have required DHS to mandate the use of SBOMs in its contracts was dropped amid industry opposition. 

The September White House memo requires that federal government agencies obtain self-attestation from vendors but does not necessitate the use of SBOMs.

The principal challenge facing SBOM production and consumption today lies in encouraging more widespread adoption. Allan Friedman, a computer scientist who leads the Department of Homeland Security’s work on SBOMs, describes encouraging the use of these tools as “a chicken and egg problem.”

While an SBOM could solve major security problems, “no one was asking for it so no one was supplying it; no one was supplying it so no one was asking for it,” Friedman, a senior advisor and strategist at the Cybersecurity and Infrastructure Security Agency, says. 

Just like a list of ingredients on the side of a cereal box, an SBOM (pronounced ess-BOM) provides a list of software components and libraries and the relationships between them. To fix vulnerabilities, computer engineers need to first know they’re there, and an SBOM provides the inventory necessary to understand what software components exist in each system.

Because modern software largely consists of assembled components, many of them open source, understanding what a given piece of software contains is the first step toward identifying vulnerabilities. 

The modular nature of modern software also means that when a vulnerability is spotted in a widely used software library — such as Log4j — that vulnerability may exist across a huge number of programs that rely on it. 

SBOMs begin to address this problem by mapping software components and their dependencies. But getting the software industry to embrace this technology is herculean undertaking, one that is only beginning. 

“Trying to get the entire software industry to provide SBOMs is a huge change,” says David A. Wheeler, the director of open source supply chain security at the Linux Foundation. “We should not expect this to happen overnight. This is going to take time.”

To encourage the adoption of SBOMs, many experts would like to see the government take a more aggressive role in requiring their use. A mandate for suppliers of software to the U.S. government to include SBOMs would provide a major infusion of engineering resources at a time when SBOMs are beginning to show progress but need to mature to deliver on their benefits. 

That’s why some saw the decision to drop the SBOM requirement from the NDAA as a missed opportunity. “A procurement requirement like that would’ve been really helpful in expanding SBOM adoption,” said Trey Herr, who directs the Atlantic Council’s Cyber Statecraft Initiative.

The provision was dropped due to industry opposition, but “the amount of flack that the trade associations put up was both confusing and disingenuous,” Herr argues, especially given the urgent need to begin building and ingesting SBOMs. 

Industry representatives say they sought for NDAA requirements to be dropped because of lack of specificity about how information will be collected from vendors.

The Office of Management and Budget’s keystone memo, published in September, set out requirements for technology vendors and the federal government agencies they work with. According to the guidance document, tech companies must be prepared to attest to the cybersecurity of their products by June 15.

However, amid continued uncertainty over precisely what information each federal government department will seek from vendors, some companies are working to ensure they are ready to sign a cybersecurity self-attestation form by that precise date, while others wait to obtain further clarity on what’s required.

“My clients are split,” one senior technology policy advisor said citing tech vendors’ experience with the Department of Defense’s Cybersecurity Maturation Model Certification (CMMC) — a troubled third-party attestation regime — as a potential reason for their hesitancy. He added: “As of right now, [we don’t] exactly know what is going to be mandated for tech vendors.”

Another tech industry advisor said that any new SBOM regime would need to be accompanied by clear guidance about how each federal agency will ingest data obtained through the program. “I’d have to know the what, why, how and where,” he said. “We need to be sure lessons are learned from CMMC.”

Industry concerns around the quality of SBOM technology and use are well-founded. SBOMs currently in use are of middling quality, and the technology to produce SBOMs is better developed than the technology to consume SBOMs.

According to data assembled by the security company Chainguard, SBOM production and consumption tools are riddled with problems. In an examination of more than 50 SBOMs from open-source projects, nearly four fifths lacked package license information, two fifths lacked package version information, and none of the SBOMs conformed to the “minimum elements” laid out by the National Telecommunications and Information Administration. 

“When we look at the SBOMs people are shipping today they are full of bugs, inconsistencies, and missing data,” said Dan Lorenc, a former Google engineer whose company Chainguard builds tools for developers to generate SBOMs

Addressing these problems requires attempts to build solutions, and engineers working on SBOM solutions say the government has a key role to play in spurring adoption. 

“The government’s role here is challenging,” Lorenc argues. The government is trying to solve an “ecosystem problem,” Lorenc argues, but “to kick start that action they have to force someone to start doing it.” 

Improving the quality of SBOMs will be a major focus for CISA in the near term, according to Friedman. Among his priorities are looking at the development of a holistic namespace for software. “It’s a very mundane and technical piece but it’s a foundational aspect,” Friedman said.  

SBOM advocates are encouraged by what they see as increasing adoption of the technology. New York Presbyterian Hospital has begun consuming SBOMs, and the Federal Drug Administration has secured a provision in the pending omnibus spending bill allowing it to require the use of SBOMs in its approval of internet-connected devices. Major technology companies — even if their trade associations have opposed the recent SBOM requirement in the NDAA — are making investments to build these tools. 

“Compared to when I started to bang my head against this wall 10 or 11 years ago, we’ve come a long way,” said Kate Stewart, a computer scientist at the Linux Foundation who helped develop some of the foundational standards for communicating SBOM information. “The industry is finally moving there.” 

Once SBOMs are being produced in greater numbers, Friedman expects the focus to shift toward improving the consumption of SBOMs. Ideally, SBOMs should integrate with existing vulnerability management systems, making it much easier for defenders to spot and fix vulnerabilities. 

“The magic will happen when we can consume good quality SBOMs across the ecosystems and have the data to match them up to vulnerabilities,” Stewart said.