A software bill of materials (SBOM) is a detailed, comprehensive list of all the components within a software application, including the use of open-source software, component dependencies, licenses, and known vulnerabilities. SBOMs provide an inventory of each individual component that comprises the application, much like a list of ingredients in a recipe. SBOMs started gaining traction in 2018 as a collaborative effort by the information security community and have largely been driven by the National Telecommunications and Information Administration (NTIA) and the US government in recent years.
SBOMs are highly important documents that provide critical information for organizations looking to minimize and reduce their operational, legal, and software supply chain risks, but many organizations still face challenges in implementing SBOMs into their existing processes or are unaware of their benefits. This article will examine how SBOMs can help organizations become better informed about the software they use and why SBOMs should be adopted as a best practice.
Find out how UpGuard helps businesses gain better visibility of their software vulnerabilities >
Why Are SBOMs Important?
Because the average business uses upwards of 130 SaaS applications in day-to-day operations and larger enterprises may use over 200 applications daily, SBOMs become even more essential to reducing security risks. The more applications that an organization uses on a daily basis, the more risk exposure the organization faces. If a single application or component were to be breached due to a vulnerability, it could potentially compromise the entire software supply chain.
SBOMs help organizations identify operational and security risks associated with certain software, as well as gain further visibility into software compositions. Organizations can better manage vulnerabilities, comply with licenses, and perform other important software management tasks by knowing exactly what's inside a software product. SBOMs are becoming an increasingly important tool in the world of cybersecurity, software development lifecycles (SDLC), and DevSecOps processes.
In May 2021, the US federal government issued Executive Order 14028, which requires all US government agencies to deal only with software vendors that provide SBOMs. This new law was part of the larger cybersecurity effort to secure the nation’s digital infrastructure and drive more software vendors to ensure products are built securely. EO 14028 also incentivizes vendors to meet federal cybersecurity standards, as government contracts are potentially lucrative opportunities.
Modern software applications and services are built with different components and dependencies from multiple sources. Those components and dependencies might include open-source software, proprietary code, custom APIs, programming language frameworks, and software libraries. The entirety of the sources that make up software applications are considered part of the software supply chain.
A software bill of materials differs from software metadata in that software metadata may provide more information about the broader use and purpose of the application, while SBOMs focus on the individual components within the application and their dependencies.
Organizations also rely on their SBOMs to address:
- Legal compliance
- Cybersecurity performance
- Risk management
- Incident response
- Operational efficiency
- Vulnerability management
What Do SBOMs Include?
The National Telecommunications and Information Administration (NTIA) issued guidance detailing the minimum elements for an SBOM, including the following foundational areas:
- Component names and versions: Each software component must be identified and listed, including its name, version number, license information, supplier name, author, and a timestamp for when the SBOM data was generated. This information allows organizations to ensure they are using the latest and most secure versions of each component. If a component or subcomponent is updated, the SBOM must be updated and reissued.
- Software dependencies: The SBOM must include the dependency tree between software components, including transitive dependencies, to maintain software functionality and to support efficient dependency management practices. If a dependency changes or a component becomes outdated, the SBOM must be updated to reflect such changes.
- Automation: The NTIA recommends minimum levels of automation for SBOM generation and data transfer so other systems can understand and use the generated SBOM data. Because software applications can be extremely complex, the NTIA strongly advises against generating an SBOM using manual processes.
- Processes: SBOMs require ongoing data collection processes that define how SBOMs are generated, how they are accessed, and who has permission to access them.
- Open-source software licenses: If the software uses open-source software licenses, it’s important to document each component's license type, as well as the terms and conditions, to prevent legal issues. Organizations can ensure they adhere to the terms and conditions set by the component's creators by keeping track of all licenses. Additionally, licensing data enables organizations to track open-source code vulnerabilities or exploits and remediate them before they can result in a cyber breach.
- Known vulnerabilities: Listing the known security vulnerabilities for each component helps organizations mitigate potential risks and improve the overall security of their software. This information allows IT teams to prioritize updates and patches to maintain a secure software environment.
Standard SBOM Formats
There are a few standard formats for creating and sharing SBOMs. Standardized formats provide consistency for SBOM data across the software supply chain, promoting full transparency and collaboration between different stakeholders. The most commonly used SBOM formats today include:
- CycloneDX, developed by the Open Web Application Security Project (OWASP)
- Software Identification Tags (SWID), developed by NIST
- Software Package Data Exchange (SPDX), developed by ISO/IEC under ISO/IEC 5962
Benefits of Implementing SBOMs
Implementing SBOMs can be a difficult process, but can provide many benefits that can help organizations better maintain their security and minimize risks long-term, including:
- Enhanced security postures: SBOMs provide further depth and visibility into software components, which helps organizations identify, track, and remediate known vulnerabilities.
- Licensing compliance: SBOMs help organizations meet licensing requirements by keeping track of all proprietary and open-source components in use. This licensing information also helps organizations meet legal requirements and regulatory standards.
- Supply chain transparency: Building software transparency is especially important for organizations as they begin to scale. Understanding the source of each software product allows organizations to properly assess the trustworthiness and security of each component.
- Efficient software audits: Software audits should be performed regularly to assess the product's compliance, effectiveness, criticality, and necessity. SBOMs help facilitate this process by providing a comprehensive list of each component used, saving time and resources needed to complete the audit.
- Effective risk and vulnerability management: Tracking each component used within the software applications allows businesses to identify potential risks and mitigate or remediate them before they can be exploited.
Challenges to Implementing SBOMs
While SBOMs can help a business’ IT ecosystem stay organized, many processes are still being standardized and defined. Because there is still variety to the creation and use of SBOMs, organizations may experience some initial challenges and inefficiencies, such as:
- Complex implementation and maintenance processes: Larger enterprises that use a wide variety and number of software products and codebases may face significant challenges in acquiring SBOMs for each application. In turn, software suppliers are also tasked with additional work when generating SBOMs, especially when the software is updated. Software products that are frequently updated means SBOMs also must be updated frequently.
- Lack of standardization: Because SBOMs are still a relatively new practice, there are still standardization issues, which can lead to inconsistencies between formats and compatibility issues between the types of tools and platforms used during data generation.
- Heavily resource intensive: The large amount of work required to generate and maintain SBOMs means that suppliers must dedicate significant time and resources to the task. In addition, special personnel within each security team will need to be trained, which can be a challenge for smaller organizations with higher priorities. Organizations that use the software will also need dedicated teams or individuals to track down the SBOMs to include them in procurement and auditing processes.
- SBOM data security: Each SBOM document contains critical information about software components, which may lead to new breach opportunities for both the supplier and the organization using the application. SBOM data must be kept confidential and secure, with new internal security processes defining its data security.
- Lack of integration capabilities: Because SBOMs are still not a common practice, integrating its processes with existing software development and deployment may not be possible or can be extremely challenging. However, more software integration capabilities can be achieved as more organizations adopt SBOMs into their processes.
- Vendor participation: With organizations potentially working with hundreds or thousands of vendors that supply software applications, getting third-party providers to adopt new processes and produce updated, accurate SBOMs can prove difficult, especially if they don’t see the benefits or feel that the extra work is unnecessary. In addition, software providers may not want to provide component details if they feel that they are revealing confidential, proprietary information.
