Software Bills of Material (SBOMs) – All the right ingredients, but something is still missing
TL;DR:
- The hype for SBOMs (Software bills of material) in the application security community and in the government is widespread—reaching a boiling point
- While SBOMs are trying to solve an undeniable problem the industry faces, we are skeptical of the current, regulatorily driven approach for SBOMs
- Rather than being a security solution, we see the regulatory requirement to provide SBOMs as a compliance solution, which while well meaning, is likely to create barriers to startup innovation in this space
- With the existing regulatory approach, we expect existing players and specialized consultants to be in the best position to succeed in the space
- There could be space for startups to disrupt the incumbents, but we think they will have to create a solution that goes further than the regulations require, such that it is attractive to a broad audience
Context
Log4Shell showed that open-source software in a proprietary software stack can have long-lived, high risk vulnerabilities. The software supply chain attack on the US government through SolarWinds showed the same for third party software.
SBOMs seek to address this by making those vulnerabilities apparent—if you know the ingredients of your software, you can make better decisions about your software. Relevant XKCD. SBOMs, as a solution, are snowballing in popularity. We heard application security engineers literally chanting “SBOM! SBOM!” at CloudNativeSecurityCon 2023.
The promise of SBOMs
Initial excitement for SBOMs is easy to understand—software compositions transparency should put a consumer or buyer in a better position to:
- Conduct diligence on the software they are acquiring or using (by checking versions, patches, etc. against known vulnerabilities)
- Negotiate with suppliers on remediating known vulnerabilities
- Respond quickly if a vulnerability is found
The open source application security community is creating and rallying around two standardized SBOM formats (SPDX and CycloneDX). In part, these standards aim to ensure that the SBOM they create will be consumable by their users; and programmatic approaches to generating and consuming SBOMs become possible.
The U.S. Government has already demonstrated its support for SBOMs, passing an amendment to the Food, Drug & Cosmetic Act in December 2022 that requires sponsors of certain new medical devices to include an SBOM with their premarket application. The White House has also, through EO 2021-10460 and the NIST guidance enacting it, and through its March 2023 National Cybersecurity Strategy, directed Federal agencies to require those selling “critical software” to the Federal Government to provide SBOMs. The government is to require a vendor’s attestation of adherence to cybersecurity standards (which have so far included SBOMs, see NIST guidance on EO14028) in vendor contracts, and they explicitly mention that their policy includes seeking to enforce contractual adherence through the DOJ under the False Claims Act.
The White House further proposed to work with Congress to develop legislation that would prevent large market players from contractually disclaiming liability for cybersecurity attacks (a common practice currently) unless they abide by safe-harbor provisions based around the same cybersecurity standards as imposed on government vendors.
We will be following to see whether and how these NIST guidelines are enforced, and what legislation might arise out of the White House’s Cybersecurity Strategy. In the meantime, we expect consultancies to jump at the opportunity to give CISOs the comfort of compliance and give large security companies another product line to sell to their existing customers.
We think SBOMs are attractive, but not yet, and not like this
SBOM support is narrow, and most of their value is already captured. Whilst we think the open-source security communication is firmly on team SBOM, the broader open-source development community doesn’t seem to be. We view one issue as mainly a burden-shifting one: who should do the work, and who should pay for it? Some arguments we have seen against SBOM requirements center around the creation of additional “chore” work that primarily benefits corporate users of the application—both from a creating/maintaining an SBOM perspective, and from being required to quickly patch software if dependencies become vulnerable. These are soft criticisms.
The harder criticism, as we see it, come from security industry professionals (vendors and buyers) who seem bearish about SBOM adoption generating value in their business. Vendors we spoke to told us that even though they have heard of SBOMs, they haven’t been required to produce one, or don’t expect to be required to produce one in the next year. Buyers have spoken about the requirement being a formality, with SBOMs not being seen to be adding more than an extra check-box step in vendor onboarding.
Why is there such a disconnect between SBOM proponents and skeptics? SBOM skeptics argue that:
- Existing SBOMs don’t generate enough value to be wanted:
- They are largely static, largely one-off
- They only generate real value during vendor negotiation (rather than during the whole software life-cycle)
- They don’t give a buyer more visibility over their own use of open source when compared to existing dependency mapping and vulnerability scanning
- They don’t increase the motivation for vendors to patch security vulnerabilities—if a vulnerability is known and high priority, reputational risks serve as an acute enough motivator
- And if SBOMs aren’t wanted, but nonetheless required, they will tend to become less meaningful and valuable over time
- Where vendors are required by rule (as opposed to organic demand) to satisfy a particular requirement, they may wind up doing the bare minimum to ‘check a box’ rather than truly trying to add value. The resulting ‘bare minimum’ can then depress demand, since it doesn’t provide value, leading to a vicious cycle. In our experience, vendors and buyers who are regulatorily compelled have historically done the bare minimum to “check a box”, reducing the incentive to provide value, reducing demand—a viscous cycle. Where these box-checking exercises occur in highly regulated industries dominated by large incumbents, they may spread slowly through those industries’ chain of contractors and subcontractors, and face pushback especially from smaller, regional contractors in the chain who feel the regulatory burden more acutely
What’s driving our hesitancy: We believe that security standards that are regulation-driven have a tendency to be satisfied with the least amount of effort; we believe security industry professionals may not perceive any real value in SBOMs; and we’re concerned about a lack of time-certainty for regulatory and industry adoption.
Even mandatory rollout will be slow
If key decision makers remain skeptical of the value being generated by SBOMs, we expect that even mandatory adoption will be slow. Further, we think the industries that will be affected by the first tranche of SBOM regulation—Defense, Critical Infrastructure and healthcare/medical devices—are cautious, with buyers (and the vendors that service them) who tend to be conservative:
- We expect them to await regulatory certainty before pulling any triggers
- We expect them to be cost-driven, rather than feature-driven
Altogether, that makes us think this will be a hard market to innovate in.
SBOM first adopters will prefer existing players
We believe that the requirement for SBOMs in Defense, critical infrastructure, and healthcare and the medical device industries will tend to create a bias in favor of large existing players in the software industry and specialized consultancies, because of the specific contractual and regulatory requirements those industries work with. We think this is especially true for the foundational elements of SBOM adoption: their creation, storage, and sharing. However, we still think there may be an opportunity around subsequent plays that build off of this foundation—in operationalization and automation of SBOM-related value drivers such as notification and risk management. This could be an area where startups can compete and drive value.
What’s your take? Let’s talk
Please reach out if you…
- Are thinking about how SBOMs can be more than a box checking exercise
- Are building an SBOM that is dynamically updating, created with automation in mind, and is designed to interface with other elements of the security lifecycle
- Think our skepticism is misplaced and want to tell us why