CISA SBOM-a-rama tackles challenges: 5 key takeaways

“The devil is in the details,” as the saying goes. Nowhere is that more true than in the looming requirement that software makers implement software bills of materials (SBOMs), which provide a list of ingredients for software and services.

Those challenges — and also the promise — of SBOMs were on display Wednesday as the Cybersecurity and Infrastructure Security Agency (CISA) hosted SBOM-a-rama, a daylong conference to hash out the state of play in SBOM development and adoption, and solicit feedback from the private sector on how to promote wider adoption and acceptance of SBOMs going forward.

This year’s event, held in Los Angeles and hosted online, attracted more than 500 attendees and highlighted both the successes and ongoing challenges of SBOM adoption. That included industry-specific presentations on SBOM adoption covering finance, healthcare and automotive, where leading organizations are well down the road to implementing and operationalizing software bills of materials. Discussions also highlighted the challenges facing smaller firms, where evolving SBOM tooling and guidance from the federal government has many organizations looking for answers.

Here are five key takeaways from SBOM-a-rama.

Learn more about SBOMs Get a free SBOM and supply chain risk report

1. SBOMs have arrived

If nothing else, SBOM-a-rama was a celebration of the success of the SBOM as a concept. A novel notion just five years ago, SBOMs these days are a topic of intense interest and discussion across industries — an acronym everyone knows.

Eric Goldstein, the Executive Assistant Director for Cybersecurity at CISA, opened the day’s events with remarks on how essential SBOMs have become in the effort to secure software supply chains. He noted that “there is no secure future without SBOMs,” and that in order to live in a world that is secure by design (referencing CISA’s recent Secure by Design Initiative), SBOMs need to become a part of our everyday lives.

See also: CISA's Secure by Design: 'It's a starting point, not an endpoint'

Driving that interest is the strong hand of the U.S. government. The concept of SBOMS got a major boost from the White House's 2021 Executive Order 14028, which called for greater transparency in software, with SBOMs as a way to increase that transparency. The EO directs agencies to take a variety of actions that “enhance the security of the software supply chain.” That includes following NIST Guidance on secure software development and software supply chain security, per a September, 2022 memorandum (M-22-18).

See also: A timeline of federal guidance on software supply chain security

And interest isn’t limited to the U.S. CISA invited Benjamin Bögel, a Policy Officer on Cybersecurity at the European Commission, to present on the Cyber Resilience Act, which is a proposed piece of legislation that outlines cybersecurity policies for European-based organizations. Bögel made it clear that SBOMs are a major piece of this legislation, stating that if it is passed by the European Parliament and Council, that organizations producing software must generate SBOMs, and at the very least they must cover the “top-level dependencies of a product.”

Today, software makers who do business with the federal government face looming deadlines to attest to the security of their wares — both critical and non critical. (The White House this week moved back some of those reporting deadlines, pending formal adoption of a standard attestation form by the Office of Management and Budget.) And, while SBOMs aren’t a broad federal requirement to attest to software security, federal agencies may require them of their software suppliers.

2. Major industries are moving SBOMs forward

In order for SBOM-a-rama attendees to see how SBOMs are practically aiding organizations in the field, CISA invited representatives from the finance, healthcare, and automotive industries to share their thoughts on the state of SBOM. The picture that emerged from those presentations was a strong endorsement of the SBOM concept.

Healthcare industry leader Jennings Aske, the Chief Technology Risk Officer at New York-Presbyterian Hospital, said that healthcare organizations “need to be open to trying new things” if they want to better secure their software systems.

Charlie Hart, a Senior Analyst in Cybersecurity Research at Hitachi America R&D, spoke about the automotive industry’s embrace of SBOMs as part of a larger industry focus on secure software development. If anything, the emphasis on SBOMs distracted from a much larger and thornier problem of software supply chain security, Hart noted.

“I think about a gradual slow down in emphasis on SBOMs and an increase in talking about things like identity, (software) provenance and pedigree and other security-related things,” Hart said.

3. The elephant in the room: SBOM standards

While speakers at the SBOM-a-rama were quick to emphasize the benefits of SBOMs, they also shared a litany of obstacles to SBOM adoption that must be addressed if widespread adoption and use of software bills of materials is to happen. Among the growing pains they identified were naming conventions and a lack of clear standards for SBOM creation and transmittal. Also on the list: software dependency tracking and uncertainty about which software dependencies should be reflected in SBOMs in order for them to be valid and effective.

Conversations about how to implement SBOMs frequently returned to what one attendee called the “elephant in the room,” namely: whether the federal government would implement a common framework and infrastructure to support its demands for greater software supply chain transparency, or leave it to the private sector to work out.

Attendees noted the uncertainty and confusion about basic questions such as how broad SBOMs should be, what format they should use and how they were to be submitted to government agencies. There is uncertainty, as well, about what infrastructure would support the government’s demand for more software supply chain transparency. “Are we working toward a common solution mandated by the government,” one attendee wondered. A standard format and infrastructure that supported automated submissions would be preferable, other attendees noted.

“I think it would be great if CISA or another government agency stood up an SBOM repository that would be managed for SBOM sharing,” wrote Sam Moore, an attendee at the SBOM-o-rama in a chat session. “IT could tie into other government services already in use such as CISA KEV and (the) National Cybersecurity Alert System.”

Chris Blask, a speaker at the event and chair of the ICS-ISAC, said that while the specific policies and enforcement are still a work in progress, there is a clear need for a common infrastructure to support SBOM management — the “plumbing” to support government efforts to manage its software supply chain security. That plumbing should, preferably, be standardized and open source, Blask said.

4. SBOM growing pains are apparent

Organizers said that questions on how to operationalize SBOMs were to be expected and, to some extent, operationalizing SBOMs was a work in progress. But the momentum towards greater attention to software supply chain security and use of software bills of materials was clear to see, said Josh Corman, the Vice President of Cyber Safety Strategy at Claroty and co-founder of the group I Am The Cavalry.

Firms across industries that had implemented SBOMs found it far easier to respond to security emergencies like the disclosure of the Log4Shell vulnerability, Corman noted. Since then, major platform providers including Amazon, GitHub and Jenkins have introduced features for SBOM creation. At the federal level, the recently passed PATCH Act requires medical device makers to submit machine-generated, machine readable SBOMs for devices seeking FDA approval, Corman noted.

5. SBOM resistance must be overcome

Resistance to SBOMs may reflect a lack of understanding on the part of software makers, or their justified fear of what an SBOM might reveal about the makeup of their products, Corman said.

We all sin. We all have a lot of tech debt and legacy security debt. And really, some people are afraid to share potential license violations [or] unfixable security issues where it would be cost prohibitive to remediate those known vulnerabilities.

Josh Corman

The goal isn’t to shame or punish those firms, but to be “tempered and graduated in expectations” and guide them from denial to acceptance of software transparency. That entails giving people time, but also “making it costly to not know what's in your own code,” Corman said.

See ConversingLabs with Corman: What’s behind SBOM skepticism? One word: Fear

CISA's end game on SBOMs

The goal for CISA is to create the conditions for success and then “get out of this game,” and leave software transparency to corporate Boards of Directors, governance risk and compliance organizations and insurers to enforce, said Allan Friedman, a Senior Advisor and Strategist at CISA who heads up the agency’s SBOM initiative.

If CISA is still asking high level questions in four years, that would not be viewed as a success.

Allan Friedman