For the past several years, the security industry has been abuzz with Software Bill of Materials (SBOM). This has been largely driven by Executive Order 14028 Improving the Nation’s Cybersecurity, the software supply chain incidents in late 2020 and prior that were the catalyst, as well as the evangelization efforts spearheaded by the National Telecommunication and Information Administration (NTIA) in the years prior. We’ve seen adoption in the EU Cyber Resilience Act (CRA), FDA Premarket Cybersecurity Guidance, and even version 4.0 of the Payment Card Industry Data Security Standards (PCI DSS) are all asking for SBOM.
These initiatives are creating a wellspring of regulatory activity around SBOM that stand to change the way we manufacture products and communicate transparency in our software, much the same as food safety labeling under The Food, Drug, and Cosmetic Act (FD&C Act) of 1938. And software consumers are now faced with a wealth of information about the software they use that conveys information about potential vulnerabilities, software licensing, integrity and authenticity, provenance and pedigree, and even artificial intelligence (AI) model card and cryptographic libraries and algorithms.
But this is a complex ecosystem to navigate, both for the software supplier, as well as the consumers who rely on them. The tools and processes to work with SBOM, while not new, are rapidly advancing in scale and capability over the last few years. Requirements are starting to find their way into contracting, and for many, this is fresh territory that can be very confusing. And as we get into this brave new world of software transparency, we quickly find ourselves needing a better understanding of how to manage all this new information to produce meaningful value for our stakeholders.
What is an SBOM?
An SBOM is a detailed inventory of all components, libraries, and dependencies used to develop a software product. It serves as a foundational tool for enhancing software supply chain security by providing critical visibility into the software’s composition, helping stakeholders identify potential risks and vulnerabilities. Effective SBOM management involves generating, verifying, correcting, enriching, sharing, and analyzing these inventories at various stages of the software lifecycle. Ultimately, we need to arrive at a high confidence result to drive risk reduction, and there are many personas involved in this process.
The SBOM Lifecycle: A Journey to Maturity
The SBOM lifecycle encompasses several key stages, each contributing to the overall security and reliability of the software supply chain:
- Generate SBOM: The first step involves the development team or third-party SBOM solution providers generating the SBOM. This may also be an entry point for software consumers to request that the SBOM be shared with them. Ideally, the supplier already has what they are asking for, if not, one must be generated. In a perfect world, this occurs with every software release.
- Verify SBOM (Higher Maturity): At higher maturity levels, the SBOM is verified for accuracy and completeness. This involves checking for correct component versions, licensing information, dependency relationships, and conformance to data specifications. This is most effectively performed by the software supplier, though some SBOM solution providers can help. For much the same reason that statements about software exploitability, or least reachability for the affected components, are best made by the software supplier, since they know their software better than anyone!
- Correct SBOM (Higher Maturity): Any errors identified during verification are corrected, ensuring the SBOM accurately represents the software. Some SBOM management solutions such as Manifest Cyber and others perform auto-correction of identified SBOM, but for the most part correction winds up being a manual process for many. In some cases, correction is required because the tools do not support the capability required so it must be adjusted manually. One example frequently used is backported fixes.
- Enrich SBOM (Higher Maturity): Enrichment can include format conversion as well as features like additional vulnerability or threat intelligence. Sometimes people use the term transformation, and there is some overlap with this concept. One area that product security vendors have latched onto is leveraging other product security attributes in conjunction with the SBOM to provide additional value.
- Share SBOM: The SBOM is shared internally within the organization and externally with partners, customers, or regulatory bodies, fostering transparency and trust. It’s important that suppliers have a mechanism to use the SBOM internally for their own risk management, as well as externally with software consumers. The ability to request and share are linked, and the efficiency in this process can have a major impact on the success of the program. This is what facilitates data exchange.
- Consume and Analyze SBOM: We treat consumption and analysis as separate activities but include them in the same lifecycle phase, because you can’t really analyze something you have not ingested and parsed (unless the data exists in a structured format you already can access). The reality is that analysis can mean different things depending on the use case, for instance, vulnerability detection vs licensing compliance. But regardless of your role, you likely are doing this somewhere in your process.
There are a variety of open-source and commercial products that generate SBOM, and the SBOM ecosystems supported by CycloneDX and SPDX both include “Tool Centers” that can help adopters identify potential solutions.
The tool space here is a bit less mature, but we have seen open-source SBOM quality checking solutions from eBay and Interlynk as well as commercial solutions from Cybeats and others. The topic of SBOM quality is quickly building momentum though as more organizations are starting to see that data quality, including issues around software naming, are some of the biggest problems to contend with in making their SBOM program actionable.
A backport is when software is updated downstream from the source, frequently done to eliminate a vulnerability, and then released downstream. This is a new capability added to an older version of the software. If the version number did not change, how would you know that the software changed? This is where concepts like pedigree come into play, but most tools do not natively support these concepts beyond providing a JSON editor or web form to manually edit the SBOM.
For instance, in SEC547: Defending Product Supply Chains, we walk through this lifecycle using open-source tools, and when we arrive at the Correct and Enrich stages, we leverage an open-source tool called Dependency Track from the same folks responsible for CycloneDX to update SBOM artifacts in their web interface and republish the corrected SBOM.
There are good examples of this from firmware analysis tools like Netrise and Finite State that include information about exploitation, exploit mitigations, file system information, credential management and in some cases, even local firewall rules such as iptables for the firmware in question. This enrichment is sometimes included in the SBOM itself, other times it is just a construct of the tools interface, but regardless, the aggregation of this information creates significant security value. The SBOM formats provide a lot of flexibility to enhance this information, and in recent years we have seen format advances that include AI model card, cryptographic metadata, and even other supply chain attestations further enriching this information.
It’s a huge problem when you consider that today people use email, FTP, API, GitHub, SBOM repositories such as Fortress NAESAD, commercial SBOM management tools such as FOSSA and Manifest Cyber and even projects like DBOM as part of the Linux Foundation to facilitate sharing of supply chain data. An effort out of Cisco called Manufacturer Usage Description (MUD) proposes yet another model where you just ask the device itself what it’s SBOM is. More recently, we have seen projects such as the Transparency Exchange API, known as Project Koala from the CycloneDX team to standardize SBOM and supply chain data sharing, using models such as DNS to help align with some of the namespace challenges with SBOM discovery and sharing.
Most tools that ingest SBOM include this capability, and if the generation tools include a graphical user interface (GUI), it is likely analyzing the results as well. It would be a boring application if it just created JSON files! There are also several open-source tools, some of which are command line interfaces like osv-scanner from Google that ingests an SBOM and checks the Google OSV database for known issues such as vulnerabilities and malicious components. Dependency Track, as well as every commercial solution we have mentioned so far, all have some type of analysis capability. You have a lot of options.
How SBOM Enhances Supply Chain Security
Effective SBOM management is vital for several reasons:
- Enhanced Security: By providing detailed visibility into the software's composition, SBOM help identify and mitigate potential vulnerabilities, strengthening the overall security of the software supply chain for all parties.
- Compliance: SBOM support compliance with various regulatory requirements, ensuring that all components meet the necessary standards.
- Transparency: Sharing SBOM with stakeholders fosters transparency, builds trust, and promotes informed decision-making. It’s just the right thing to do.
By investing in robust SBOM practices, you're not just securing your software but your entire supply chain. Stay ahead of the curve and ensure the integrity and security of your software products with our expert insights and comprehensive guide.
Secure your software supply chain today - download your copy of the SBOM Maturity and Process Flow cheat sheet here.
This blog is part of the Mastering Supply Chain Security series. If you missed parts 1 or 2, watch them via the links below:
- Part 1 – Enhanced Vendor Risk Assessments: Maximizing Risk Reduction and Strengthening Vendor Relations
- Part 2 – Building and Scaling SBOM Programs: Navigating the Challenges for Effective Risk Management
Don’t miss part 3 of the series: Supply Chain Security Incident Response: Strategies for Responding to Emerging Threats | October 17 at 1:00 PM ET
Register now or sign up for a demo to see how SEC547 Defending Product Supply Chains can empower you to protect your organization’s supply chain.
