While software bills of materials (SBOMs) promise to help streamline software vulnerability mitigation and software supply chain security efforts, in order for enterprises to succeed, they must pick the right SBOM data exchange standard for their use cases and understand how to consume several SBOM standards when necessary.
"Having a software bill of materials (SBOM) is crucial for cybersecurity as it provides a breakdown of the software components utilized by your organization," said Rafay Baloch, CEO and Founder at RedSecLabs. However, it's not just about having an SBOM, Baloch continued. It's about picking the [right] format and using the SBOM constructively.
Essentially, SBOMs are comprehensive inventories that detail all the components within a software application. These components include open-source libraries as well as third-party software components and libraries. Improving transparency into third-party software components, dependencies, and vulnerabilities has become increasingly important as threats to software, including supply chain attacks, continue to grow and evolve, as do regulatory requirements.
Recent federal mandates drive SBOM adoption, including the U.S. Executive Order on Improving the Nation's Cybersecurity. This directive requires federal agencies and their contractors to provide SBOMs for the software they develop or procure, underscoring the need to enhance software supply chain transparency.
Implementing an effective SBOM strategy comes with its challenges. Organizations must navigate competing standards and best practices to find the right approach. The National Telecommunications and Information Administration (NTIA) and the Cybersecurity and Infrastructure Security Agency (CISA) have identified three primary SBOM formats:
SPDX (Software Package Data Exchange): A well-established standard that provides a comprehensive framework for describing software components, their licenses, and related metadata. Major tech companies such as Microsoft widely support it.
CycloneDX: A lightweight standard designed for application security contexts. It focuses on providing clear visibility into software dependencies and is particularly useful for supply chain component analysis.
SWID (Software Identification Tags): While not a full-fledged SBOM, this standard is used primarily to identify installed software products, firmware, and other components. It helps in managing licenses and compliance across various platforms. Due to its simplicity, some experts advise organizations looking to start with SBOMs here.
The SBOM standards decision is far from straightforward as enterprises work with vendors on providing the SBOM in a format they can work with or is required by a regulatory body. Each standard offers unique strengths and caters to different use cases. Experts note that factors such as ecosystem compatibility, software complexity, and specific industry requirements drive these choices. For instance, larger enterprises with complex software ecosystems may lean toward the comprehensive SPDX standard, which provides a robust framework for describing software components and their metadata. In contrast, organizations prioritizing application security contexts might opt for the more lightweight CycloneDX standard, known for its ability to provide clear visibility into software dependencies.
There's no clear answer on the best SBOM standard available or how organizations should contend with competing standards. During a recent panel held by the Advanced Technology Academic Research Center (ATARC), guests were mixed on whether organizations should choose one particular standard or use several, below. Luci Holemans, air traffic organization cybersecurity manager at the Federal Aviation Administration, said that whether an organization decides SPDX or CycloneDX depends on their specific use case and security requirements.
"If you look into those different standards, it [depends upon] how granular you need to be and how much information you require. It's very dependent on your environment. For more critical services, you would probably want to use something with a high granularity and visibility," she advised.
However, Kashif Zaidi, senior director of solution architect at Aqua Security, said enterprises should standardize on one SBOM format. "I tell our customers: just choose one or the other and make sure you stick with it and standardize on it,” Zaidi said.
Charles Livingston, cybersecurity risk management branch chief at the U.S. Department of Health and Human Services, and Chris Hughes, CEO at Aquia, advised different approaches. Livingston said he doesn't think one SBOM standard will provide everything an organization needs. Livingston also advised organizations struggling with SBOMs to start with SWID. While it's not as granular as CycloneDX or SPDX, it's more straightforward to implement. "We have to start somewhere," he said.
Finally, Hughes said organizations might be best served by focusing not on what standard to choose but on what elements must be tracked and ensuring an organization can work with both.
"As a consumer [of SBOMs], you're going to receive both [standards] depending on your supplier base. So, the tooling that can read either standard will be critical. And a lot of the modern tools are starting to work interchangeably with either format," Hughes said.
"I think we're going to see both formats potentially exist for some time. Honestly, maybe that's good and healthy competition to drive our SBOM format processes forward," he added.
Selecting the right SBOM is further influenced by the need for integration with existing vulnerability management and asset management workflows, scalability to meet future demands, and the level of support and documentation available. As regulatory pressures mount and the importance of software transparency grows, the choice of SBOM standard is becoming an increasingly strategic decision that can significantly impact an organization's ability to manage risks and ensure compliance.
"Based on my experience, SPDX stands out as a choice since it effectively deals with open source licensing information, whereas CycloneDX is exceptional at identifying vulnerabilities," said Baloch, adding that SWID, on the other hand, is particularly valuable for managing software inventories.
"Some enterprises use all three formats, especially when dealing with [complex] software environments. It's similar to having various tools in a toolbox—each has its use," Baloch added.
When adopting several formats, organizations can focus on the primary benefits of each. Security teams can leverage the multi-format SBOMs to assess risks when new vulnerabilities emerge. At the same time, legal and compliance departments utilize the rich license and copyright information provided by SPDX SBOMs for regulatory compliance. Additionally, procurement teams use these standardized SBOMs to manage supplier relationships better and assess software supply chain risks.
Baloch added that the effective strategy for those also building SBOMs to track their internal development is to align one's SBOM with their security objectives and incorporate it into the software development and delivery pipeline processes.
"By doing this, it ensures your SBOM progresses alongside your software development efforts while maintaining security," he said. And advised organizations to stay focused on the fact that it's not about generating SBOMs for the sake of generating SBOMs but taking action based on its findings, addressing vulnerabilities promptly, and avoiding unresolved security weaknesses.
Experts advised that best management practices should be implemented after selecting a standard to maximize SBOM benefit. Regular updates are essential to maintain accuracy and reflect the current state of the software. Automation is key to reducing manual errors and improving efficiency while facilitating continuous monitoring of vulnerabilities.
For organizations opting to build or consume two or three of the primary standards, tools are getting more straightforward over time as improved tools become available, such as the ability to embed SBOM generation tools directly into development pipelines, ensuring that every software build produces SBOMs in all three formats. This streamlines the process and creates consistency in the elements included across SBOM formats. This way, various teams—security, legal, compliance, procurement—all have a comprehensive set of the data they need. The same processes can be used to consume SBOMs created by third parties.
Tools that help organizations support multiple SBOM standards include Syft. This open-source tool generates SBOMs in SPDX and CycloneDX formats, as well as the CycloneDX CLI tool (allows conversion from SPDX to CycloneDX) and the SPDX prototype conversion tool (that converts CycloneDX to SPDX).
This strategy enables some companies to apply each standard to its strengths strategically. CycloneDX, with its cybersecurity focus, is being utilized for in-depth supply chain component analysis. SPDX, known for its thoroughness, is the go-to for comprehensive cataloging and license compliance. Meanwhile, SWID tags find their niche in unique software identification, particularly in government-related contexts. To address the challenge of working with multiple formats, some companies are designating a primary SBOM format for internal use while maintaining the capability to generate other formats as needed. This flexibility allows organizations to cater to tools and systems with specific format preferences or requirements.
Software supply chain security, regulatory requirements, and software complexity will continue evolving. By adopting SBOMs and incorporating SBOM management best practices today, a foundation can be built to enhance software risk mitigations significantly.
George V. Hulme is an award-winning journalist and internationally recognized information security and business technology writer. He has covered business, technology, and IT security topics for more than 20 years. His work has appeared in CSOOnline, ComputerWorld, InformationWeek, Security Boulevard, and dozens of other technology publications. He is also a founding editor at DevOps.com.
