SBOMs Are Great for Supply Chain Security but Buyers Beware
Two major events have served to help bring software bill of materials (SBOMs) further to the forefront as a potential way for organizations to begin to secure their supply chains. The Apache Log4j’s Log4Shell disaster — which will likely pose problems for years to come by setting the stage to become one of the most widespread supply chain attacks in history — and the realization how it could have been prevented had a proper SBOM been put in place. In May, President Biden issued Executive Order 14028 in May which mandates that IT providers must provide an SBOM in order to work with the U.S. Federal Government. Consequently, organizations are now increasingly looking to integrate SBOMs into their DevSecOps processes.
At the very least, SBOMs will serve as a principal component in any secure software development framework (SDF) by providing a complete library of all libraries used in any applications, with a complete history of all code sources and timelines. “An SBOM is all about adding transparency to the software deliverables by including the list of software components and dependencies,” Alvaro Iradier Muro, product analyst and software engineer at Sysdig. “Without an SBOM, there is reduced visibility into a software’s dependencies, possible open source or commercial license concerns, known vulnerabilities, or other potentially malicious elements. Organizations and users assume risk when they deliver or use software lacking SBOMs and don’t perform the extra analysis as due diligence.”
But while the adoption of SBOMs is at the very least positive for boosting security, considerable work must be done before they can begin to provide even a dent in preventing supply chain attacks and detecting vulnerabilities. SBOMs thus do seem to offer a solution about what ails supply chain security, and at the very least, should serve as a principle component in any security plan, challenges impeding their adoption remain.
The main thing to consider first before the challenges are described is to detail what an SBOM needs to do. “We usually describe the SBOM in general terms as a list of ingredients — you can consume food without worrying about the composition, but in case of allergies, nutritional concerns, etc., you want to understand what is inside the product,” Muro said. “For a software application, service, package, etc., it is exactly the same. So SBOM is not the entire solution for supply chain security, but it is a critical part of securing the digital supply chain.“
Caveat Emptor
The main things to be on guard for when selecting an SBOM provider that Muro communicated include:
- How some analysis tools only scan what’s inside a binary and produce a list of components. “The efficacy of this approach depends heavily on the capability of the binary analysis and can still result in gaps. Ideally, every supplier should provide the SBOM for every piece of software it delivers to its consumers,” Muro said. “The consumer of that piece of software would use composition analysis to produce the SBOM for its own output that includes the original SBOM plus the description of the artifacts that are added as part of customization and delivery.” The SBOM for the final deliverable in the supply chain should contain a comprehensive, accurate list of components and versions involved in producing that deliverable. “That means that every single software supplier must provide that comprehensive, accurate SBOM for any commercial or open-source software,” Muro said. “Otherwise, the final SBOM document is inaccurate or incomplete.”
- How there are competing SBOM standards, including CycloneDx, SPDX and SWID Tag. “These SBOM formats don’t all contain the same information either. Most organizations expect that an SBOM contains dependency lists, known vulnerabilities (CVE-IDs), and software license information,” Muro said. “This makes it harder to converge into a common solution.”
- While counterintuitive in some ways, DevSecOps teams must be aware that the SBOM itself is a digital document that needs to be secured. “No matter how accurate and comprehensive it is, organizations or suppliers need to make sure that the SBOM is not compromised. This is typically accomplished with integration checking and digital signatures to ensure authenticity and prevent tampering, but it requires additional tooling and process to achieve,” Muro said. “Many organizations have barely scratched the surface with gathering or maintaining SBOMs, let alone digging into this level of supply chain integrity. SBOMs can add much transparency to the software supply chain, but at the same time, they also introduce additional challenges that organizations must address with new tooling or processes.”
After taking these caveats into consideration, even the best SBOM provider serves little purpose if the organization has not adopted proper DevSecOps processes. “The most common operational element being discussed today is the usage of SBOM to communicate new vulnerabilities within components in the software supply chain for the given application. Such knowledge is obviously valuable, but if your organization doesn’t have a process to consume it, then there is minimal benefit from having an SBOM and associated vulnerability information,” Tim Mackey, principal security strategist at the Mountain View-based Synopsys Cybersecurity Research Center, told the New Stack. “It is this lack of process that is the biggest challenge as while procurement teams can request SBOMs from all their suppliers, if there isn’t a well-defined process to act upon the information in the SBOM, then all that’s happened is you’ve now one more file in a directory. It’s also important to note that SBOMs are only one component of a well-defined software supply chain risk management process, but they aren’t the ‘silver bullet of operations management.’”
SLSA Spice
SBOMs will certainly not cover all of the ground for organizations to secure their supply chains. In addition to their own best practices that should provide security monitoring and checkers across CI/CD and cover runtime during the post-deployment stage, it is also wise to complement SBOMs with Supply-Chain Levels for Software Artifacts (SLSA is pronounced as “salsa”). SLSA provides a framework and roadmap so that the industry can start adhering to the implementation of SBOMs and other security good practices for securing the software supply chain. “This also includes setting standards or levels for certifications as well as requirements for software providers,” Muro said.
-
Source: Chainguard
Again, even the implementation of both an SBOM and SLSA, while they target supply chain protection, are but two components for supply chain protection. “You can’t just buy something, plug it in and solve everything,” Dan Lorenc, co-founder and CEO, Chainguard who co-created the SLSA as well as Sigstore security projects, told The New Stack. “When you break the supply chain problem down, SLSA is focused on one area and SBOM another and SLSA is focused on another and there are a couple of dozen problems that you’ve got to solve and SBOM only targets one of them. So, there are a lot of problems there and then there are a lot of problems beyond this problem.” Or even if we do get that solved and there’s perfect despawns and everybody has that we still have to worry about.”
The adoption of SBOMs and SLSA, while not yet mainstream, represents a promising beginning, Rick Holland, chief information security officer and vice president of strategy at Digital Shadows, a provider of digital-risk protection solutions, told The New Stack. “SLSA’s complement SBOMs: whereas the SBOM provides the ingredients, the SLSA details how the ingredients were made in a safe way and SLSAs make SBOMs better. SBOMs coupled with SLSAs could be leveraged as a competitive differentiator by software companies,” Holland said. “Not only do you get updates on the software components used to deliver a product, but you get assurances that the software was produced securely.”
Nor are SBOMs a “panacea but a step in the right direction,” Holland said. “In a world where vendors don’t report or aren’t even aware of all the software used in their solutions, defenders must fall back on detection and response,” Holland said.
