The use cases and lifecycle of Software Bills of Materials (SBOM) are starting to coalesce as software organizations begin making them working artifacts. The White House Cybersecurity Executive Order (EO 14028) initiated a push to improve software supply chain security for software vendors and the federal government. However, the impact is being felt across industries, such as medical device software, where improved security and, particularly, software supply chain security, are becoming key requirements.
This post looks at the lifecycle of the SBOM in the context of the SDLC, pre-and post-production SBOMs, how they differ, and how to apply binary versus source code software composition analysis (SCA).
Source and Binary Software Composition Analysis
Source code analysis tools analyze the actual source code files of an application. They examine the code’s structure, dependencies, and specific functions or libraries used. The scope of the analysis is limited to the sources made available to the tools. Source SCA tools can detect vulnerabilities, licensing issues, and other code-related problems by directly examining the source code. These tools are typically used during development as new code is developed and new open-source or third-party code is incorporated.
Binary SCA tools (like GrammaTech CodeSentry) analyze compiled binary code or executables. They inspect the compiled artifacts without direct access to the original source code. BCA tools focus on identifying open-source components and their versions within binaries. These tools focus on identifying open-source components and their associated vulnerabilities without access to the source code. They rely on signature-based matching or heuristics to compare binary artifacts against known vulnerabilities in their databases. Binary SCA tools are typically used during application deployment and post-release maintenance.
SBOMs Throughout the SDLC
A Software Bill of Materials (SBOM) provides a detailed list of the software’s building blocks, including open-source libraries, third-party components, frameworks, and their associated versions and licenses. The SBOM plays a crucial role throughout the software development lifecycle, both in the pre-production and post-production stages.
Pre-Production SBOMs
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.
Planning and Design: During the planning and design phase, an SBOM helps teams assess the feasibility and security of incorporating specific components into the software. It enables them to evaluate potential risks, licensing requirements, and dependencies that might impact the software’s development.
Development and Coding: Developers use the SBOM to track and manage the open-source components and libraries they incorporate into the software. It helps ensure compliance with licensing obligations, identify potential security vulnerabilities, and monitor component versions and updates. The SBOM assists in maintaining a clean and secure codebase from the early stages of development.
Quality Assurance: The SBOM plays a role in testing and QA activities. It helps development teams identify potential vulnerabilities or outdated components in the software. By referencing the SBOM, they can verify that the software aligns with security standards, legal requirements, and best practices.
Post-Production SBOMS
Post-production, in the context of software development, is the deployment stage where software application components are integrated and shippable to a customer. In most CI/CD pipelines, a deployable application is the end goal of each cycle, and it’s important that SBOM artifacts are created with each. These post-production SBOMs are generated by binary SCA tools because of the larger scope of analysis that includes the application, open source, and third-party libraries.
Deployment and Distribution: Once the software is ready for deployment, the SBOM serves as a reference for the distribution process. It provides insights into the licenses and legal obligations associated with the software’s components. This information ensures compliance with open-source licenses and facilitates proper attribution and distribution.
Vulnerability Management: The SBOM plays a critical role in post-production vulnerability management. By cross-referencing the SBOM with vulnerability databases, organizations can quickly identify and address any security vulnerabilities or patches related to the software’s components. This enables timely updates and reduces the risk of exploitation by potential threats.
Incident Response and Patch Management: In the event of a security incident or the discovery of a vulnerability in a component, the SBOM helps 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: The SBOM is valuable for compliance and auditing purposes. It provides 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.
The Power of Post-Production Binary SCA SBOMs
There is a role for both source-based, pre-production SBOMs and post-production SBOMs generated by binary SCA tools. In fact, both should be used together for a complete solution. However, there are some advantages to as-built, post-production SBOMs.
Verify pre-production SBOMs: It’s critical that open-source licensing and vulnerabilities from pre-production sources match up with the same binary findings. Discrepancies should be documented and assessed. It’s possible that binary SCA tools may detect new dependencies and open source vulnerabilities from source-based analysis due to the increased scope of libraries and other executables.
Detect vulnerabilities in non-source artifacts: Binary SCA tools analyze binary code, libraries, and executables, and it’s possible that more vulnerabilities are found. The increased scope of the analysis provides a more complete picture of the open source dependencies and security risks of the application.
Produce an “as-built” SBOM for customers in the desired format: The post-production SBOM is the complete list of all components in their final form for shipment to a customer. Tools like CodeSentry support standard SBOM formats for easy integration into vulnerability and SBOM management tools.
Complete SBOM for integration into vulnerability, portfolio, and SBOM management systems: Post-production SBOMs provide a complete picture of dependencies and vulnerabilities in the software supply chain. It is this stage of the lifecycle and the type of SBOM that makes the most sense to feed into management systems.
SBOM generation for deployed or legacy applications: Since binary SBOMs work on any executable or library, it’s possible to analyze applications already deployed, including legacy applications. It’s also possible to analyze third-party applications used in conjunction with your application ecosystem. This is an important capability when new vulnerabilities, like Log4J, pop up and exposure to them is unknown.
Summary
Overall, SBOMs are crucial for improving software security, ensuring compliance, and managing vulnerabilities throughout the software development lifecycle. Both pre-production and post-production SBOMs, utilizing source code and binary SCA tools, respectively, contribute to a comprehensive solution.
Pre-production SBOMs are used during the planning, design, development, and coding stages to assess feasibility, manage open-source components, ensure compliance, and perform quality assurance. Post-production SBOMs, generated by binary SCA tools, come into play during deployment and distribution, vulnerability management, incident response, patch management, compliance, and auditing.
The advantages of post-production SBOMs are that they verify pre-production SBOMs, detect vulnerabilities in non-source artifacts, produce a complete as-built SBOM for customers, and facilitate integration into vulnerability, portfolio, and SBOM management systems. Additionally, post-production SBOMs can be generated for deployed or legacy applications, allowing analysis of the entire software supply chain.
