Since 2021, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) has been a proponent of software bills of materials (SBOMs) as a tool that can help secure the software supply chain. The policy grew out of the White House’s 2021 Executive Order 14028 and was developed further with the National Telecommunications and Information Administration’s release of “The Minimum Elements for a Software Bill of Materials (SBOM)” [PDF].
SBOM adoption has risen since then. Sonatype reports that three-quarters of enterprises in the United States and the United Kingdom have implemented SBOMs since EO 14028's May 2021 release. But implementation remains a challenge for many organizations. Numerous obstacles stand in the way of the SBOM becoming widely accepted and used, including standardizing SBOM formats, ensuring that SBOMs are comprehensive, and making them actionable.
To field these critical questions and hear possible solutions from key stakeholders, CISA in June 2023 inaugurated SBOM-a-rama, a periodic gathering of practitioners and leaders from government, enterprises, and the community to address the state of the SBOM. Since then, CISA has held SBOM-a-rama events in February 2024 and earlier this month, in Denver, Colorado.
Key themes of the most recent gathering included automation, the importance of transparency, and much more. Here are the key takeaways from Denver's SBOM-a-rama that application security (AppSec) leaders and practitioners need to know.
[ See Special: Go Beyond the SBOM With Deep Visibility and New Controls for Your Software ]
1. Practitioners stress the importance of transparency
One key benefit of the SBOM that multiple stakeholders stressed throughout the event is the tool’s ability to shed light on what a piece of software consists of, such as third-party software, open-source components, and internally developed code. This transparency, many at SBOM-a-rama argued, translates into greater security for the critical systems using it.
In one of the first sessions of the day, James Paolo Caseja, team lead for software modernization in the Office of the Deputy Assistant Secretary of the Army for data, software, and engineering, gave an update on the Army's new SBOM adoption and use mandate. Caseja termed increased use of SBOMs essential for the Army because they provide greater transparency.
“How do we ensure that the vendors providing software to us are secure?”
—James Caseja
Transparency is also essential for the growing artificial intelligence industry, said Helen Oakley, director of secure software supply chain and secure development at SAP. In a presentation on AI SBOM (AIBOM) use cases, she stressed that the community needs to work together “to build trust in AI systems” and said AIBOMS are “enablers for transparency and security.”
CISA’s Allan Friedman, considered to be the agency’s No. 1 cheerleader for SBOMs, started the first open discussion of the event by saying transparency from software producers is key to software supply chain security and should be a given.
“How absurd it is that people want to sell us software when they themselves don’t know what’s in it?”
—Allan Friedman
2. Automation is key to making SBOMs relevant
While attendees of SBOM-a-rama widely agreed on the essential purpose of SBOMs as a tool for software transparency, there were several conversations concerning the tool’s shortcomings, including the need for the automation of SBOMs — to generate them, update them, share them, etc.
Olle Johansson, speaking on behalf of the Open Worldwide Application Security Project (OWASP), said that for SBOMs to be useful and impactful, “we need an automated way to transport” them. He believes that “standard formats and automation is the key here” in order for SBOMs to deliver transparency to relevant stakeholders.
Attendees at the event also discussed what different stakeholders require when it comes to SBOM generation and use. Conventional wisdom holds that SBOMs best serve those consuming third-party software products. However, there could be benefits to software producers using SBOMs as well. But noting the speed at which DevOps operates, one SBOM-a-rama attendee expressed hesitance:
“Until we have automation, developers will never use an SBOM.”
Automating SBOMs won’t just allow developers to make them actionable and useful; it will also serve other stakeholders that can use SBOMs to make their software supply chain security efforts better.
3. SBOM sharing isn’t as straightforward as it should be
Several key speakers at the event last week voiced that SBOM distribution and sharing aren’t as straightforward as many might hope.
Caseja said that while the Army's new SBOM mandate will be helpful in creating software transparency, work still needs to be done to ensure that the service is being specific in what it's asking for.
“What do we need in terms of language to request this [SBOM] from software producers?”
—James Caseja
Not only do relevant stakeholders need to be careful in how they request SBOMs from third parties, but they also need to ensure that the sharing and use of such SBOMs is secure for all parties involved. Caseja asked rhetorically, “How do we reduce the amount of risk with sharing SBOMs?”
Representatives from information sharing and analysis centers at the event highlighted similar concerns about SBOM sharing. Phil Englert from the Health-ISAC noted in his presentation that ISACs are working hard to distribute SBOMs to health care organizations, which are all using similar software products and services. The key challenge, he said, is, “How do providers make [SBOMs] available, and how do consumers know they are available?”
Despite increasing SBOM adoption, there is a lack of clarity for software producers on the question of whether they need to produce an SBOM and how they can best share it with consumers of their products, in addition to whether or not relevant consumers are asking for — or are even aware of — SBOMs.
4. Make them actionable to support your supply chain security
There is consensus that, once SBOM sharing becomes standardized within different industries, SBOMs can be made actionable for key components of software supply chain security. United Airlines' Deanna Medina, who is a part of a tiger team for SBOM actionability, said that the SBOM “enables an organization to meticulously track its software inventory” and can also “protect organizations from legal risks.” From a practical standpoint, an SBOM also “prevents the over-deployment of software," Medina noted – reducing an organization’s software bloat.
For incident response and risk remediation efforts, Medina stressed that organizations' security teams can “quickly determine which components may be compromised” when relying on an SBOM and said the tool “enables more rapid remediation and containment of risks” within the software consumer’s organization. In the health care field, Nastassia Tamari of the U.S. Food and Drug Administration made it clear that SBOMs are critical for the risk management process for medical devices.
What’s next for the SBOM?
Overall, last week’s SBOM-a-rama raised important questions about the state of SBOMs. Much was demonstrated about the progress being made in several areas with multiple stakeholders to ensure that their use increases and is more actionable. In the general discussion period, one attendee made the point that we “need the scale of multiple people doing it [SBOM generation and use] to determine what the answers are” to our challenges.
Another attendee raised a point that contextualized SBOMs in the greater scheme of software supply chain security:
“Don’t look at SBOMs as your only supply chain risk management tool.”
SBOMs, while an important first step, are only a list of ingredients, not a recipe for comprehensive software supply chain risk management and threat prevention. To learn how your organization can go beyond the SBOM to prevent software supply chain attacks, read this ReversingLabs white paper.
