A major U.S. initiative aimed at improving transparency into the security of software components has a long way to go before it will be able to reach its full potential.
According to industry analysts and the federal official leading the “software bill of materials” (SBOM) effort for the government, the next phase of the initiative is ready to begin, with more vendors expected to soon start offering a detailed peek at the components used inside their software to federal customers.
But while SBOM will need time to fully mature, the important thing is to get started with what’s ready now and build from here, said Allan Friedman, who heads the SBOM effort at the Cybersecurity and Infrastructure Security Agency.
"To go from security [where software] is a black box to thinking about the broader supply chain — that takes a while, especially in the federal government," said Friedman, a senior adviser and strategist at CISA, in an interview with Protocol. "But it is a priority."
At a basic level, an SBOM is just a text file that lists the components used to build a piece of software. The usual analogy that gets drawn is with the ingredients list on a package of food; some security professionals have even suggested just referring to it as a “software ingredient list.”
The software bill of materials could have a range of applications for reducing cyber risk, proponents say, though the most commonly cited use is enabling a customer to quickly pinpoint where they're running vulnerable components.
The effort has gained traction in part due to rising concerns, in the wake of vulnerabilities such as Log4Shell and attacks such as the SolarWinds breach, about the security of open-source software components and the software supply chain overall. At the same time, not everyone in the cybersecurity community believes SBOM deserves to be a top focus, given all of the initiatives an organization could undertake to improve its security.
SBOM is only a starting point and does not solve any problems on its own, Friedman acknowledged.
"The important thing to remember about SBOM is it's a data layer. And that's all it is," he said. "The goal is to take that data and turn it into intelligence, which can then drive action."
Help wanted
In truth, the software tools needed to analyze SBOMs in bulk and glean insights from the data largely do not exist yet.
Even the much-touted use case of checking the SBOM for a flaw like Log4Shell is not something even a skilled developer would want to do manually, and it’s beyond the reach of anyone non-technical, said Gareth Rushgrove, vice president of products at Snyk, which offers developer security tools including SBOM generation. Notably, in the initial stage, an SBOM won't be automatically correlated with vulnerability information.
But many in the industry told Protocol they expect people and companies will be able to solve these problems as soon as more SBOMs are being produced. That will likely be spurred, at least in the beginning, by the federal government and its tens of billions of dollars in annual IT spending.
The U.S. government has been working on various elements of the software bill of materials equation for more than a year now, ever since President Biden's executive order in May 2021 established SBOM as an important initiative for national cybersecurity. Many software companies have interpreted the efforts as the basis for the eventual inclusion of SBOMs as a requirement in federal contracts.
The White House's Office of Management and Budget is expected to soon issue a memo to federal agencies detailing how to go about including SBOMs in the contracting process, cybersecurity policy watchers told Protocol. OMB declined to comment.
In the meantime, some federal agencies have already begun to ask for SBOMs.
"It's going to be a big change."
In July, the State Department issued a draft request for proposals on technology contracts worth $8 billion to $10 billion, which included a requirement for a software bill of materials. The National Defense Authorization Act for Fiscal Year 2023 mentions a requirement for procured products — with individual items listed in a "submitted bill of materials" — to either be free from software vulnerabilities or include a plan for remediating issues.
If the White House does ultimately direct federal agencies to require SBOMs from software suppliers, it would represent the most-specific technical requirement for cybersecurity ever placed on private-sector contractors by the U.S., said David Brumley, a computer science professor at Carnegie Mellon University and co-founder of cybersecurity startup ForAllSecure, which serves federal customers including the Department of Defense.
In short, in the event this happens, "it's going to be a big change," Brumley said.
But given the seriousness of the problem around the security of software — particularly open-source components — it may be exactly the type of ambitious change that the tech industry needs, a number of executives in the software and cybersecurity industries told Protocol.
"I think there is very significant inherent value in this, and we will see adoption across the industry," said Yogesh Badwe, chief security officer at data protection vendor Druva. "It will take time, of course."
Scaling up
Standard data fields in an SBOM include the names and versions of components, as well as the relationships between component "dependencies" — the pre-built, third-party software components that are heavily used in software development and are often distributed under open-source licenses.
The lack of visibility into software dependencies has been a major factor behind the push for SBOMs, particularly in the wake of Log4Shell, a critical vulnerability in the widely used Apache Log4j logging component that was discovered last December.
In the ensuing rush to patch affected systems, many software vendors struggled to figure out if their products were vulnerable to Log4Shell due to lack of visibility into their own code, a much more common problem than one might think, said MongoDB CISO Lena Smart. But the data platform company's work with Snyk allowed it to "see every instance of Log4j so quickly," Smart said. "That's why we were able to tell our customers within two days, 'This is where we are [with Log4j].'"
Notably, the U.S. government's list of minimum elements needed for an SBOM includes that the documents are written in a machine-readable format to allow for automated usage. The two leading formats, SPDX and CycloneDX, will appeal to different customers based on which type of compliance or standards their industry is focused on, said Tim Mackey, principal security strategist with the Cybersecurity Research Center at Synopsys, which will generate SBOMs for customers.
"It should just be a natural part of the landscape, the way that the other parts of our vulnerability ecosystem are."
At this point, the basics of SBOM are "reasonably well understood," and numerous commercial and open-source tools now exist for generating the documents, Friedman said. "There's no reason that an organization cannot start generating SBOMs and asking for SBOMs from their suppliers."
Friedman, who has been the federal government's most prominent SBOM champion for years, previously worked on the issue as director of cybersecurity initiatives at the National Telecommunications and Information Administration, before continuing the effort at CISA.
Going forward, he said, the focus will be on scaling up the production of SBOMs, achieving interoperability between the different vendors that generate them and "operationalizing" the concept — in other words, making SBOM into an everyday part of corporate life, like tax reporting.
"Most people should not be thinking about SBOM" within three to five years, according to Friedman. "It should just be a natural part of the landscape, the way that the other parts of our vulnerability ecosystem are," he said.
Consuming SBOMs
Even in its limited initial phase, the SBOM approach is useful for helping to better inform purchase decisions on software, according to Dan Lorenc, a former Google software engineer who is now founder and CEO of Chainguard. The startup offers tools that aim to help software developers more accurately generate an SBOM and more efficiently remediate vulnerabilities in their own code with the help of the document.
However, because SBOMs aren't automatically correlated with the National Vulnerability Database, making vulnerabilities transparent in an SBOM will be difficult "until a lot of work gets done on matching the vulnerability database to the software database," Lorenc said.
"If I had to guess, the first year or two of this SBOM journey is going to be focused on just building up the muscle to ask for them, to provide them, to create them, to keep them up to date," he said.
At Mend, which offers SBOM generation capabilities, vice president of product Jeff Martin said the federal efforts have also opened the door for private industry customers to begin requesting SBOMs from their software suppliers. Ultimately, "that's what will actually move the needle," he said.
Security teams across both the public and private sectors are tired of the mad scramble that occurs every time a new critical vulnerability is disclosed, said Dale Gardner, senior director and analyst at Gartner. Greater software transparency is a top priority for many organizations.
"I think there's a lot of pressure and demand within the marketplace for these kinds of solutions," Gardner said. "So I'm pretty confident [SBOM] is going to happen."
Vendors looking to enable "dynamic SBOM" could be another key piece of the puzzle, according to Katie Norton, a senior research analyst at IDC. Such tools "can help prioritize what to deal with first, by telling you that these are the things that are internet-exposed and exploitable," she said.
The need for tools that can make sense of SBOMs has always been recognized as a chicken-and-egg issue that would eventually have its time to be addressed, and that's beginning to happen now, Friedman said.
"Our consumption of SBOM data has lagged — and that's OK," he said. "Until recently, we didn't have a lot of SBOM data sitting around, so no one would have sought out an SBOM consumption tool. We're now at a level where that's starting to emerge."
Without Biden’s executive order, it’s unclear whether the SBOM movement would have gained the attention and momentum needed to go mainstream.
“When the White House announced that part of the basic level of software security was including an SBOM, that did have a huge impact on how people saw this,” Friedman said. “It was an emerging idea. And now it was going to be expected as part of the basic software model.”
Questioning the ROI
The SBOM initiative has prompted significant debate in the cybersecurity community in recent years, and continues to do so. While most say they support the push for greater software transparency, not all agree that focusing on SBOM is the best use of time for shorthanded security teams.
For the amount of effort that will be required to use SBOMs, the actual risk reduction is not likely to be worth it right now, said Wim Remes, managing director of the security services unit at Damovo.
"SBOM is a nice idea," Remes said. "But I think it shouldn't be a priority at this moment."
Jonathan Reiber, vice president of cybersecurity strategy and policy at AttackIQ, and a former cyber policy official in the Obama administration, agreed.
SBOMs are “a great thing. They should happen. They're not ‘the’ thing,” he said. “Start with what we know the adversary is going to do, and defend your high-value data [against that].”
Meanwhile, the federal effort around SBOM has also been questioned by some in the broader tech industry, including representatives of the Information Technology Industry Council, a trade group whose members include many of the largest companies.
"We're not saying that SBOMs can't be useful," said Courtney Lang, senior director of policy at the group. "But I think there does remain a lot of work to be done in order to ensure that, if there is going to be some kind of future requirement, it actually yields useful information to the federal government."
When asked about the readiness of federal agencies to use SBOMs, Friedman said that "there are definitely organizations in the U.S. government today that are ready to embark on that journey."
Just like in the private sector, the government "has organizations that have spent a lot of time and money and staff thinking about the broader security landscape," he said. "And there are also much smaller organizations that comply with federal rules, but don't necessarily have abundant resources to take on new roles and responsibilities."
“[SBOMs are] a great thing. They should happen. They're not ‘the’ thing.”
Likewise, smaller software vendors that sell to the federal government could also be affected differently by any forthcoming SBOM requirements, said Rick Holland, CISO at ReliaQuest-owned cybersecurity vendor Digital Shadows.
Smaller vendors may have a steeper challenge with finding the resources needed to supply an SBOM, and may have to decide whether a federal contract is valuable enough to do so, Holland said.
Whatever the federal government ends up doing in terms of SBOM requirements for contractors, "I'd like to see a gentle approach to SBOM initially," said Marc Rogers, executive director of cybersecurity at Okta.
For the first phase of SBOM, companies should just be asked to make their best effort, “and then they can improve on it," Rogers said. "I'd like to see that go through some cycles before anyone starts sort of waving a stick."
At data management software vendor AvePoint, cybersecurity chief Dana Simberkoff also wants to see answers for some of the other open questions about the practicalities of implementing SBOMs — from how to automate their usage to a mechanism for ensuring they don't end up in the hands of attackers — before any SBOM requirements for contractors roll out.
Given that AvePoint's software is used broadly across the U.S. government, she has good reason to pose such questions.
"Conceptually, this is absolutely the right direction for the government to take and for industry to take, as well," said Simberkoff, who is chief risk, privacy and information security officer at the company. "But there are key things that need to be fleshed out."
Still, the current lack of visibility into the security of software is just too serious of a problem to do nothing, she said, counting herself among the strong supporters of the SBOM initiative. "I'm a big believer in not letting the perfect be the enemy of the good."
