SBOM generation (mostly) ‘a solved problem’

Commercial vendors including Cisco, Red Hat, Splunk, VMware and Oracle produce SBOM and VEX data, while GitHub and Jenkins users can automatically generate their own SBOMs using built-in tools. Cloud-based software systems were specifically excluded from the National Telecommunications and Information Administration’s (NTIA’s) minimum requirements for SBOMs, but the Linux Foundation, Open Source Security Foundation and Cloud Native Computing Foundation also house SBOM-related projects for such systems, including Google’s Supply chain Levels for Software Artifacts, or SLSA, and Graph for Understanding Artifact Composition, or GUAC.

On the supplier side, the executive order jump-started SBOM efforts at observability and IT security vendor Splunk, now owned by Cisco. Before the executive order, the company had an opt-in system for producing SBOM information that was managed by different departments, said Anusha Penumacha, senior security software engineer at Splunk, in an SBOM-a-Rama presentation.

We had nowhere to track what is happening with all these vulnerabilities that are being generated. That’s where the executive order came in.

“We had nowhere to track what is happening with all these vulnerabilities that are being generated,” Penumacha said. “That’s where the executive order came in, and the [CISA] SBOM guidance came in … [and with] some teams that were resistant to change … we were like, ‘Hey, you need to be compliant — otherwise, you can’t sell this anymore.'”

That was the “stick” the executive order gave Splunk’s product security team to centralize SBOM generation, but it also gave them a “carrot” of fresh guidance to offer product teams that were more interested in creating SBOMs, or already generating their own, Penumacha said.

“Without the executive order, that wouldn’t have been possible,” she said. “The final result is that we have an end-to-end automated SBOM generation pipeline [that publishes] to an internal hub where everybody can access it.”

Cases like this show that SBOM generation is “almost a solved problem” in the industry, according to a presentation from Viktor Petersson, founder of Sbomify, an SBOM sharing and management software vendor. Petersson is part of a tiger team, a group of stakeholders in the CISA community focused on specific best practices. In Petersson’s case, he is the co-chair of a tiger team creating an SBOM generation reference implementation for commonly used CI/CD tools from GitHub and GitLab.

There are further phases to creating an SBOM such as augmentation and enrichment with configuration and vulnerability data, and consolidation between an organization and its suppliers’ SBOMs that remain a challenge, Petersson said, but the group now has a working blueprint for SBOM generation in the CycloneDX format.

“We are more or less done with the generation and consolidation stage for CycloneDX, and we are fairly well far along in the augmentation and enrichment phase. … We’re getting back to [Software Package Data Exchange] SPDX to make sure we get parity,” Petersson said.

CISA event chats dwell on SBOM snags

Despite presentations on SBOM success stories and progress on industry best practices, the regulatory urgency that sparked SBOM efforts at Splunk has faded somewhat in the years since the executive order was issued.

The executive order specifically mentioned SBOM multiple times in its instructions to federal agencies such as NIST and NTIA, to “issue guidance identifying practices that enhance the security of the software supply chain” and “publish minimum elements for an SBOM.”

NIST and NTIA both issued this guidance, but both emphasized that SBOMs “are currently nascent for federal acquirers,” according to NIST. As a division of the Department of Homeland Security, CISA was issued instructions in the order to provide guidance to federal agencies on improving cybersecurity, particularly for critical infrastructure.

While the adoption of zero trust architecture, encryption and multi-factor authentication are specifically mentioned in those CISA instructions, SBOMs are not. CISA collaborated with the Office of Management and Budget (OMB) over the last three years to create a secure software development self-attestation form for federal suppliers, the initial drafts of which specifically called for SBOMs. But the final version, released in March, did not.

Meanwhile, many of the discussions during CISA’s third annual SBOM-a-Rama event focused on the challenges still facing SBOMs in practice.

There are still areas where Lockheed is waiting for SBOM workflow tools to mature, such as high-scale SBOM registries for distributing SBOM information within the organization and with third parties, according to Ganger’s presentation.

Embedded systems, especially those written in languages such as C++ and C, have limited support for automatically generating SBOMs, as do open source infrastructure-as-code tools, he said.

Even without strong SBOM support for some systems, receiving and assessing the amount of information generated from the SBOM data that’s available has been a challenge, Ganger said.

“We found out that we’re using a whole lot more open source than we knew about, because there’s just so much [in] that transitive dependency space,” he said. “Once you automate that, it generates a lot of information which is difficult for the compliance organizations to always consume. This is something we’re still working through.”

Bridging the multiple standards for sharing and ingesting SBOMs in CycloneDX and SPDX remains another work in progress. Given that those formats were created for different reasons, are governed by different standards bodies and have strengths and weaknesses depending on how they’re used, consolidating them into one standard isn’t practical.

In light of this, the Protobom OpenSSF project creates an abstraction layer that translates common data fields between two major data-sharing standards to make them easier to work with for software consumers. Another effort presented at SBOM-a-Rama, the Open Worldwide Application Security Project’s Transparency Exchange API allows suppliers to distribute SBOM data in multiple formats.

However, some event attendees questioned whether too many competing standards might hinder SBOM progress, while others called for additional standards for SBOM data management, and still others for existing standards such as VEX and the NTIA SBOM framing document.

“We started with the second edition of the framing document that the team from NTIA got out to the field [in 2021],” said Kate Stewart, vice president of dependable embedded systems at The Linux Foundation and one of the co-chairs of a CISA tiger team working on updates to the framing document. “It already had some of the controversial fields in there and some other ones that were [missing]. … The formal minimum elements that came out from NTIA didn’t have certain fields. However, the framing document did, so we retained those and extended based on the input from the participants and the community.”

Other topics raised in the online chat and during discussion sessions at the event touched on established issues including maintenance struggles for the National Vulnerability Database; a call for business incentives to raise demand for SBOM use rather than relying on regulatory threats; and a tendency toward false positives and varied results from vulnerability scanning tools.

“Creating SBOMs is relatively straightforward, but there’s room for improvement in their accuracy,” said one attendee, Zvika Ronen, CTO at FossAware, an open source risk management consultancy in Tel Aviv, in an online interview during the event. “The real challenges lie in the subsequent stages [such as] enriching SBOM outputs [with] crucial information like software licenses. … Without it, organizations are left with an incomplete picture, making it difficult to fully assess and manage their software supply chain risks.”

”Crawl’ has had a decade’

The lack of specific regulatory follow-up on SBOM requirements after the executive order and the fact that many of the issues raised at the third SBOM-a-Rama event were the same as they had been at previous gatherings were sources of frustration for one presenter.

Joshua Corman

SBOMs have been in use in the financial services industry and on the federal government’s radar since the failed Cyber Supply Chain Management and Transparency Act of 2014, according to Joshua Corman, co-leader of a CISA community working group for SBOM on-ramps & adoption and executive in residence for public safety & resilience at The Institute for Security and Technology (IST).

NTIA had begun work on SBOM guidance in 2018, well before the executive order, Corman said. The executive order helped raise awareness about SBOM, but it also brought an influx of new community participants that weren’t aware of past efforts.

“I’m trying to reflect what’s been told to me by people who no longer come to these meetings, people that contributed for five-plus years before you heard of SBOM,” Corman said during the presentation. “They are frustrated to see some of their prior art done [over again].”

Corman also questioned some of the blockers to SBOM he’d heard raised during the event, such as false positives and inconsistent results from different tools.

“We have multi-billion dollar markets like pen testing, static analysis, dynamic analysis, bug bounties that do not get consistent results, and yet, they’re driving incredible business value, and they’re driving up the trustworthiness of software,” he said.

Finally, Corman said he was concerned about a lack of clarity in the community about what role CISA and other federal agencies should play in federal SBOM guidance and requirements. There are already clear guidelines about CISA’s role in directing federal agencies on how to protect critical infrastructure such as the water and food supply, power systems, and emergency medicine, he said.

“I really would love to see the executive order completed,” he said. “The President asked outright, ‘I want anything purchased by the federal government to have a software bill of materials,’ and then at some point [in] differentiating critical from non-critical [infrastructure], OMB guided agencies that they have to specifically opt in to ask for artifacts like SBOMs. … And now in the final guidance on those [CISA] attestation forms, the word SBOM does not exist, so there is still work to be done.”

The software supply chain of critical industries in the U.S. doesn’t have another 10 years to figure out how to more effectively identify vulnerabilities and defend against attacks such as China’s Volt Typhoon nation-state threat group, Corman said. An initiative Corman is leading at IST under the working title UnDisruptable27 now looks to address these threats, with or without the rest of the CISA community.

“We’ve got to end the crawl stage of crawl, walk, run. … Crawl has had a decade,” Corman concluded. “Some of you that don’t like this or want to drag your feet and want to find some ways not to do it, you can do that, and you will own the consequences of that. But at least on these critical infrastructure things, we’re not waiting anymore. … We’re going to have to find ways to go faster.”

CISA officials did not respond to a request for comment on whether the agency will add SBOM-specific requirements to future versions of its self-attestation form. But during the event, CISA senior adviser and strategist Allan Friedman expressed his own frustration at SBOMs’ slow progress.

“I find it helpful to just remember how absurd it is that people want to sell us software [when] they themselves don’t know what’s in it,” he said during an open discussion session at the event. “Whenever I talk about this to policy experts who aren’t experts in software, they’re just shocked that we don’t already have this.”

Beth Pariseau, senior news writer for TechTarget Editorial, is an award-winning veteran of IT journalism covering DevOps. Have a tip? Email her or reach out @PariseauTT.