As we explained in a previous post, SBOMs (Software Bill of Materials): Why Do They Matter?, SBOMs are like ingredient labels for software. They list and track all the components, modules, and libraries that were used to build a piece of software, along with their dependency relationships. They include paid, owned, and open-source software components.
SBOMs are critical for ensuring transparency and security in software supply chains. Among other things, they enable organizations to quickly determine if software is impacted by a particular, identified vulnerability. SBOMs are now a requirement under the ISO standard for open-source software. And in May of 2021, President Biden signed an executive order mandating all software vendors to the US government must provide SBOMs for their software.
How Are SBOMs Used Today?
The first empirical study to interview and survey software bill of materials (SBOM) practitioners was released in February 2023. The aim of the report was to investigate how actual SBOM practitioners view the current state of SBOMs.
The researchers applied a mixed qualitative and quantitative methodology, gathering data from 17 interviewees and 65 survey respondents in 15 countries across five continents. While the vast majority of organizations understand the importance of SBOMs, there remain many challenges in adopting and implementing SBOMs as a standard practice.
Here are five key findings from the study:
1. SBOM Adoption Is Still Lagging
A significant amount of widely used software – especially open source software – still has no associated software bill of materials (SBOM).
83% of respondents agreed with the following statement:
"Most existing third-party software or components, either open source or proprietary, are not equipped with SBOMs."
Similarly, 87% of respondents agreed with the statement:
"SBOMs are not generated for all software, even inside a software vendor organization."
The researchers speculate that the lack of SBOMs for open source software may create the impression among software vendors that SBOM adoption is not yet an industry standard, and therefore not critical. Respondents voiced concerns, with 80% viewing limited SBOM adoption as "the most fundamental and imminent concern."
2. SBOM Generation And Regeneration Require More Standardization
While there was broad agreement (85%) that software bill of materials (SBOM) generation can occur at different stages of the development lifecycle, depending on the software and its characteristics, the researchers conclude that SBOMs should “ideally be generated at early stages and then gradually enriched with more information from the latter stages.”
As one respondent put it:
“I do not think we should produce an SBOM as a one-shot process, but rather we should be carrying evidence and partial SBOMs and enriching them in every single operation.”
When it comes to SBOM regeneration, however, a majority (54%) believe most organizations fall short. Software artifacts today are constantly going through changes. SBOMs, however, are not being re-generated to reflect those changes in a timely fashion.
One respondent said that putting out a new SBOM with each new major version of software is “better than nothing,” but added that the ability to generate new SBOMs with each software change is “more of an aspirational goal – it’s not something that will be realized right away.”
Another respondent opined that robust version control was needed for continuous SBOM regeneration to become standard practice.
“You need to version-control your SBOMs, and figure out how to distribute that information to your customers."
3. There Is Still No Consensus On What to Include In SBOMs
Although there are two major software bill of materials (SBOM) industry standards (SPDX and CycloneDX), as well as official recommendations on what SBOM data fields should include at a minimum, 63% of respondents agreed that "in practice, generated SBOMs don’t always meet the minimum bar."
There are two main reasons for this: data availability and software vendor customization. Software vendors sometimes don’t include all the recommended data because the relevant data is not readily available. Some vendors also only include a subset of the minimum suggested data, or customize their minimum requirements to meet their own needs.
As a result of this lacking consensus, one quarter of respondents said their organizations use their own customized, non-standard formats.
4. Many SBOM Tools Lack Maturity
You need the right tools to create and consume software bill of materials (SBOM). The generation process is tedious and prone to error when done manually and, for all intents and purposes, SBOMs are designed for machines to read and interpret.
Unfortunately, available SBOM tools tend to be difficult to use and lack standardization and interoperability. The majority of respondents (65%) agreed that:
"SBOM tools can be hard to use due to various reasons (eg, complexity, aggressivity, lack of generalization)."
73% of respondents also agreed that "tooling interoperability and standardization hinder the usability of SBOM tools." One respondent noted that SBOM tooling is “an area where we need further harmonization and standardization.”
For example, the SBOM data generated for the same component by different tools can come out different. This flies in the face of the purpose of the SBOM format, as one respondent explained:
“The whole point of a hash is that it should be the same [for the same component], so that downstream users can validate it.”
Finally, most respondents (69%) agreed that the integrity of SBOMs generated by existing tools cannot be validated. The researchers stressed that:
“[T]ooling competence is a common concern for generating SBOMs”
...and that...
“More reliable, user-friendly, standard-conformable, and interoperable enterprise-level SBOM tools, especially SBOM consumption tools, are needed.”
5. There Are Serious Security Concerns With Vulnerability Management
Although vulnerability management is a major use case for software bill of materials (SBOM), 73% of respondents agreed that "vulnerability management currently barely considers the actual exploitability." While vulnerabilities should be uncovered, not all vulnerabilities are exploitable, so vulnerability management needs to be strategic.
As one respondent wrote:
“Vulnerability and exploitability are totally different. You can’t simply send a long report to the developers and ask them to update each and every vulnerable dependency that has been flagged. I know the development team might end up ignoring your report, or come back at you saying, ‘Are you able to exploit this vulnerability? No? Then why should I go and update it if you are unable to exploit it?'"
Organizations typically select which vulnerabilities to fix based on criticality. Vulnerability Exploitability eXchange (VEX) documents, produced by software vendors, have emerged as a tailored solution to help SBOM operators distinguish which vulnerabilities pose significant risk and how to best remediate them, while not wasting time patching vulnerabilities that are not exploitable.
However, VEX documents are not always reliable. As one respondent said:
“The ability to differentiate between whether it’s exploitable or not is a hard thing to do in itself, especially if you want to automate it.”
An SBOM tool developer with hacker experience stated:
“I don’t agree that the [vulnerabilities] defined as less exploitable are not valuable. I used to be on the attacker’s side. Hackers can take their time, and they can find a way to put together a lot of things that look very not-exploitable, and at the end of the day, find themselves with very easy and exploitable access.”
The researchers conclude that “better mechanisms are needed to communicate vulnerabilities with limited/undetermined exploitability”.
Overcoming The Challenges
Software bill of materials (SBOM) challenges essentially fall into two buckets:
- Compliance or regulatory
- Identifying and mitigating exposure to risk
As it turns out, even if you have an SBOM indicating that a software package relies on, for example, Log4j, that won't tell you which services within the software are compromised.
How we mitigated the log4j vulnerability "Log4Shell" within 48 hours
For this reason, we recommend that developers focus first on maintaining a meaningful, data-rich inventory of services and underlying libraries. Such an inventory not only serves as valuable input for SBOM generation, but also as a searchable catalog making it possible to quickly identify which services in which products need to be dealt with when an exploitable vulnerability emerges.
LeanIX Value Stream Management
Thankfully, the LeanIX Value Stream Management (VSM) platform can support you in documenting all the components used throughout your tech stack.
VSM connects teams, technology, and processes for efficient software delivery. We enable engineering leadership to eliminate risks, bottlenecks, and inefficiencies while simultaneously improving the flow of software delivery value, including:
- discover and catalog software artifacts
- identify, address and remove inefficiencies
- share knowledge in your development organization
