In November 2022, the Information Technology Industry Council (ITI), an IT industry lobbying group, raised eyebrows for some in the software security community when it penned a letter to the Office of Management and Budget that criticized government software supply chain security initiatives, including a planned requirement for the government to collect software bills of materials (SBOMs) from software vendors. Again, in June 2023, ITI and the Cybersecurity Coalition, an industry association coordinated by law firm Venable LLP, expressed their disapproval of SBOMs in public comments on a potential secure software development self-attestation form developed by the Cybersecurity and Infrastructure Security Agency (CISA). 

Given many of the companies represented by these groups—such as Google, Red Hat, Microsoft, and Mozilla—have been vocal on the need for better software security and transparency, why are industry trade groups lobbying against federal efforts to collect SBOMs from software vendors and improvements in software transparency? Also, and perhaps most importantly, what merits are there to their objections? 

This article explains the stated concerns of industry groups and addresses, as best as possible, the substance of these concerns. It highlights an urgent need for evidence in many of the claims made both for and against SBOMs. 

But for those who just want the punchline, here’s one straight from Taylor Swift herself: SBOM “haters gonna hate.” 

The November 2022 ITI letter spells out several objections to the potential inclusion of SBOMs in attestation forms. First, the letter argues that SBOMs are not “scalable,” not “consumable,” and therefore of “limited utility.” The authors also imply that SBOM technology is immature, making SBOMs not “suitable” for inclusion in government procurement contracting. Furthermore, the letter makes the case that SBOMs have “varying degrees of complexity, quality, and completeness.” Included in the letter are detailed technical challenges such as “naming, identification…delivery and access, the linking to vulnerability information” and other topics too. Perhaps most concerning, the letter suggests that the SBOM provision could create an increased risk for zero-day exploits and the potential for intellectual property and patent infringement. 

The Venable coordinated team, in recent public comment, argues that the provision of SBOMs as part of a potential, secure software self-attestation form “conflates the processes by which organizations carry out secure software development with artifacts of those processes.” 

These public critiques are not baseless, but they argue via hyperbole, unfairly throwing the whole of the evidentiary burden onto SBOM proponents while neglecting key arguments in favor of SBOMs. 

For instance, some SBOMs are indeed of varying quality. Past empirical research of several thousand SBOMs suggests that many SBOMs do lack key information, such as component names and component versions. But this same research also finds that some tools produce, on average, higher-quality SBOMs and that some open-source software projects already create high-quality SBOMs. 

Moreover, arguments against providing SBOMs for fear that some SBOMs are low quality suffer from two logical defects. First, low-value data plagues many aspects of cybersecurity(think of network or host logs), but their collection and analysis are still widely considered useful. Second, SBOM maturity partly depends on the extent of SBOM usage, so efforts that impede usage also degrade long-term SBOM quality. In short, better SBOMs are certainly possible and wider generation and use of SBOMs is perhaps the quickest route to better SBOMs. 

Shaking off the idea that SBOMs are just artifacts of a secure software development process would strengthen the discussion of responsible software supply chain practices. The Venable group’s letter framed SBOMs as “artifacts” intended to create an artificial separation between the artifacts and processes of responsible software development, implying that SBOMs serve as mere byproducts that exist to check off a box within an arbitrary compliance process rather than act as useful reference documents which can inform both provider and consumer decisions. Providing SBOMs to other parties allows competition in the software marketplace, allowing consumers to make better-informed choices by, for instance, enriching SBOMs with vulnerability data and thereby avoiding providers that ship vulnerability-ridden software. Ideally, SBOMs should transfer from software producers to software consumers to enable transparency and, perhaps more importantly, accountability. 

SBOM critics do have one solid point: There is a lot left to be learned about SBOMs and the foundations of SBOM knowledge remain unfinished. While the International Organization for Standardization (ISO) codifies one of several formats for SBOMs and its data structure, and many companies already offer SBOM generation tools or features, the complete universe of cases for how SBOMs will be produced and consumed is far from settled. Instead of immediately shooting down the federal government for raising those questions, trade associations could follow the lead of their member companies, many of which are actively working both to improve existing technologies for the production and consumption of SBOMs—and to help the software development and consumer communities learn more about the uses of SBOMs. 

Industry trade associations’ criticism of the federal government’s potential collection of SBOMs is strange partially because many of their members already invest in and evangelize SBOM technology. Microsoft has created and released a SBOM generation tool, and publicly argued for the benefits of SBOMs and promoting their internal adoption of the technology for all of their software products. VMWare has advocated SBOM technology, hyping the “simplicity” of SBOMs. Cisco has stated that they “support the industry’s adoption of SBOMs” in response to the need for software supply chain transparency. Google has highlighted the benefits of SBOMs for providing visibility into the technologies organizations rely upon. 

Broadly, the objections of trade associations misrepresent the current state of SBOM tooling and minimize recent advances in SBOM technology. There are now dozens of tools that generate SBOMs, a slew of tools to ingest SBOMs, tools for SBOM quality measurement, and even SBOM composition. 

Trade industry associations are also not raising these objections in response to proposed regulations on software producers for all buyers, which would be (somewhat) understandable. Instead, these objections respond to proposed federal procurement guidelines. The US federal government’s role as a software consumer means that it has a vested interest in improved software supply chain security (especially in the wake of the Russian ultimate software supply chain attack only a couple of years ago). 

To propose a reductive metaphor, if someone with a deathly nut allergy wanted to purchase a cookie and asked the baker if it contained traces of peanuts, it would be generally regarded as “nuts” for a seller to refuse to inform this customer, a customer who is simply trying to obtain information about a product they are about to consume. If software providers find themselves unwilling or unable to meet the proposed procurement requirements, they can continue to sell their software to everyone else and pass on government contracts. Measuring this risk and preventing or mitigating it is a key issue for entities such as CISA, the General Services Administration, and federal regulators.  

Government and industry giants already agree, a key step to better software supply chain security is knowing what exactly is in all of this software we buy. As SBOM adoption progresses, industry and government should take a page out of Taylor Swift’s book and just keep cruisin’, don’t let SBOM haters get in the way. 

John Speed Meyers is a nonresident senior fellow with the Atlantic Council’s Cyber Statecraft Initiative in the Digital Forensic Research Lab and principal research scientist at Chainguard, where he co-leads Chainguard Labs, a research lab focused on software supply-chain security. 

Sara Ann Brackett is a research associate at the Atlantic Council’s Cyber Statecraft Initiative under the Digital Forensic Research Lab (DFRLab).

Trey Herr is the director of the Atlantic Council’s Cyber Statecraft Initiative under the Digital Forensic Research Lab (DFRLab).