Software bill of materials (SBOM) use cases are used both by software product consumers and software producers, which deploy software products while producing SBOMs for their customers. Often, the producers are also consumers of SBOMs as they pull from open source and other third-party code to build their products and every third-party component should include its own SBOM.
In this post, we explain the different SBOM use types from pre-deployment to production. Then we explain the advantages of post-production SBOMs generated with Binary Composition Analysis (BCA) against third-party products and components used by developers of said products when source code is unavailable. BCA-generated SBOMs verify components carried over from pre-production SBOMs and create a complete product SBOM that benefits both product developers and consumers. These post-production SBOMs, generated by tools like CodeSentry, should support leading standard formats for easy integration into vulnerability databases, vulnerability management, and SBOM management systems.
Producer Use Cases
Product companies that take security seriously should expect SBOMs from all the software components they plan to use to evaluate before being integrated into products. During development planning and integration, product vendors consume SBOM data to determine if the third-party components are safe enough for use in their products. In deployment, product developers produce SBOMs. That means there could be hundreds of SBOMs tied to a single product. So the SBOM data and associated vulnerabilities must be expressed in a common syntax that consumers and developers can understand and prioritize based on severity of risk, and manage throughout the product lifecycle.
Pre-Production
As the name implies, pre-production SBOMs are used during the design and development phases of software development when new sources are created or added from outside the organization. In this case, the development team is essentially a consumer of SBOMs for any third-party components, which they use to plan their security risk management strategies. Pre-production SBOMs are particularly useful for the requirements analysis, planning, implementation, and testing stages of product development. See the graphic below.
Pre-production and post-production SBOMs within the SDLC.
Use cases for pre-production SBOMs include:
Planning and Design: SBOMs help teams assess the feasibility and security of incorporating specific components into the software.
Development and Coding: Similar to the planning and design stages, developers use SBOMs to track and manage open-source components and libraries they incorporate into the software. This helps ensure compliance with licensing obligations, identify potential security vulnerabilities, and monitor component versions and updates.
Quality Assurance: SBOMs help development teams identify potential vulnerabilities or outdated components in the software before shipping. By referencing the SBOM, developers can verify that the software aligns with security standards, legal requirements, and best practices and use them to provide documentation for regulators and the end consumer.
Post-Production
Post-production is the deployment stage where software application components are integrated and shipped to a customer. In most CI/CD pipelines, a deployable application is the end goal of each cycle, and SBOM artifacts must be created with each cycle. These post-production SBOMs are generated by binary composition analysis (BCA) tools to accommodate the larger scope of analysis covering applications, open source, and third-party libraries.[DR1]
The SBOM produced during the software development process plays a critical role in post-production vulnerability management. By cross-referencing the post-production SBOM with vulnerability databases, the product company and its customers can quickly identify and address the severity of security vulnerabilities or patches related to the software’s components. This enables timely updates and reduces the risk of exploitation by potential threats.
Use cases for post-production SBOMs include:
Deployment and Distribution: SBOMs serve as a reference for the distribution process by providing insights into the licenses and legal obligations associated with the software’s components.
Vulnerability Management: By cross-referencing the SBOM with vulnerability databases such as VEX (Vulnerability and Exploitability Exchange), organizations can quickly identify and address any security vulnerabilities or patches related to the software’s components.
Incident Response and Patch Management: SBOMs help organizations assess the impact on their software. They can identify the affected versions and components, analyze the potential risks, and apply appropriate patches or updates to mitigate vulnerabilities.
Compliance and Auditing: SBOMs provide a transparent record of the software’s components, licenses, and dependencies. Organizations can demonstrate adherence to licensing obligations, compliance frameworks, and regulatory requirements, ensuring transparency and accountability in their software supply chain.
Consumer Use Cases
As the term supply chain implies, there is a link between producers and consumers from top to bottom. However, for large-scale end consumers of software, the SBOM is part of a complex procurement process, particularly, for example, within US government systems.
SBOM use cases for software consumers include:
Vulnerability Management: With an SBOM, consumers can easily identify and track the software components and versions used in their systems. This helps them stay informed about any vulnerabilities associated with those components and take timely actions, such as applying patches or updates.
Supply Chain Security: SBOMs provide transparency into the supply chain of software. Organizations can use SBOMs to verify the origin and authenticity of software components, which reduces the risk of using compromised or malicious components.
License Compliance: SBOMs provide a clear inventory of all software components and their associated licenses. This ensures compliance with licensing agreements and avoids legal issues related to unauthorized use or distribution.
Patch and Update Management: SBOMs help software consumers identify which components need updates or patches. This streamlines the update process, making it easier to address vulnerabilities and ensure that their software is up-to-date.
Asset Inventory and Management: SBOMs provide a comprehensive list of software components used in a system, assisting in creating and maintaining an accurate inventory of their software assets and aiding in overall asset management and lifecycle planning.
Risk Management: SBOMs help organizations analyze the potential risks associated with different software components, including vulnerabilities, license issues, and dependencies. This information enables informed decision-making and risk mitigation strategies.
Incident Response: In the event of a security incident, SBOMs help companies quickly identify and assess the affected software components. This facilitates a more efficient and targeted response to contain and remediate the incident.
The Role of BCA Tools Like CodeSentry in SBOM Use Cases
Binary composition analysis tools like CodeSentry are fundamentally different from source-based tools since they don’t require source code for SBOM generation to provide a complete picture of all of the dependencies (and related vulnerabilities) in a binary software product.
The advantages of post-production BCA SBOMs include verifying pre-production SBOMs to ensure consistency, detecting vulnerabilities in non-source artifacts through binary code analysis, and producing an “as-built” SBOM for software consumers. These post-production SBOMs, generated by tools like CodeSentry, support standard formats for easy integration into vulnerability and SBOM management systems.
The flexibility of BCA SBOMs also allows for the analysis of deployed or legacy applications, including third-party applications acquired by development organizations. This is powerful as it allows companies to quickly assess and mitigate emerging vulnerabilities like Log4J in real-world scenarios.
For additional resources, see also our July post on SBOM types and our December SBOM predictions post announcing even newer types of BOMs being proposed to cover the software supply chain for high-risk embedded systems such as auto and aerospace.
