Software Bills of Materials (SBOMs) are a detailed inventory of all the components—open source, proprietary, and third-party—used within a software application. SBOMs play a key role in ensuring software integrity, managing security risks, and strengthening software supply chain security.
As SBOM requirements expand around the globe, organizations need to be able to generate SBOMs quickly and efficiently to minimize development lifecycle overhead. Depending on the type of software projects you develop and maintain, there are different types of SBOM generation techniques that will work best in different scenarios. Additionally, the way an SBOM is generated affects its accuracy and completeness and your visibility into software vulnerabilities.
Here, we break down the three main types of SBOMs, why SBOMs are important for vulnerability identification and management, and special considerations for C/C++ projects.
Binary-Based SBOMs: The Pre-Packaged View
Binary-based SBOMs are generated by analyzing compiled software, focusing on the final product rather than the source code or build process. The approach works by examining the binary to identify its components and dependencies.
Binary-based SBOMs are useful for legacy software and older systems where source code is either unavailable or inaccessible. They also enable the analysis of third-party software components without requiring access to their source code.
However, relying solely on binary analysis often results in SBOMs that lack critical details that can only be captured during the build process, the most notable example being the existence of statically linked libraries. Some auxiliary data is also lost during compilation, making it difficult to trace the origin and history of certain components due to limited provenance information.
The lack of visibility often leads to a high rate of false positives, as accurately determining the contents of a binary without insight into the actual build is inherently challenging. While valuable in specific scenarios, binary-based SBOMs are less precise compared to other SBOM generation methods.
Key takeaway: Binary-based SBOMs provide a practical solution for managing legacy systems or third-party components. However, they typically lack the depth and accuracy of SBOMs generated from source code or during the build process, often resulting in less detail and a higher likelihood of false positives.
Source Code SBOMs: A Static View with Broad Coverage
Source code-based SBOMs are generated by analyzing a software’s source tree for a specific target, offering a comprehensive view of the components involved in the development process. This method has several notable advantages.
First, it provides complete visibility into the source code, ensuring a thorough inventory of all potential components that could be included in the software. It also offers direct access to valuable metadata, such as licensing and copyright information, which is critical for compliance and legal requirements. Additionally, analyzing source code is less computationally intensive than its more involved build-time SBOM counterpart, as it involves simpler, less resource-demanding operations.
However, the source code-based approach comes with its own set of challenges. A key issue lies in the complexity of build configurations. Since this method examines the source tree rather than the final software build, it may fail to accurately reflect the configurations used to generate the actual binaries. This misalignment can result in discrepancies between the SBOM and the final product. Conditional compilation further complicates matters, as accounting for different compilation paths in large, complex codebases with multiple configurations can be particularly challenging.
Another limitation is its inability to capture runtime dependencies—external components that are dynamically fetched during the software’s operation. Consequently, source code-based SBOMs often over-report, including components that may not make it into the final binary and creating unnecessary noise. This can lead to false positives, where components that are in the source code are flagged even though they will not be in the final build and so do not present any business risk.
Key takeaway: Source code-based SBOMs provide greater visibility into all components of a codebase, making them valuable for compliance, licensing, and early development analysis. However, they still miss out on providing the complete picture of the final product and have a strong chance of false positives by not accounting for build configurations and runtime dependencies.
Build-Time SBOMs: The Complete Picture
Build-time SBOMs are considered the most accurate and efficient method for tracking software components because they are generated during the compilation process, providing a detailed and reliable view of all the components included in the final software build.
Build-time SBOMs execute against the precise components that will be in the build and only contain the relevant libraries and the specific sub-components used in said libraries during the building of the compiled output. Build-time SBOMs are also able to capture all external or linked resources that are only included at build time.
The precision of build-time SBOMs reduces alert fatigue and saves engineering teams time by minimizing false positives and eliminating the need to investigate reported vulnerabilities on components that will not be in the final build and that do not present a risk to production.
When implementing build-time SBOMs, look for solutions that easily integrate into your CI/CD pipeline and existing development workflows. For them to be useful, they must fit smoothly into automated workflows without adding extra complexity or causing delays. Also consider performance. Build-time SBOMs increase accuracy, but should not come at the cost of slowing down build times significantly.
Key takeaway: Build-time SBOMs offer the most precise and comprehensive tracking of software components, making them essential for strengthening software supply chain security and minimizing false positives. They can also be created for legacy software where the source code is readily available. To maximize their impact, choose solutions that seamlessly integrate into your CI/CD pipeline.
Choosing Your SBOM Generation Tool: Implications for Vulnerability Identification
The type of SBOM you choose can significantly impact your software security efforts. When selecting an SBOM generation tool, consider your specific needs, access to source code, and desired accuracy level. For most modern development environments, build-time SBOMs will provide the most value and the clearest picture of your software’s actual composition.
A complete and accurate picture of your software’s composition enables more effective vulnerability identification and risk management, allowing you to:
- Maintain strong software supply chain security
- Efficiently identify and address vulnerabilities
- Deliver more secure products
- Meet SBOM regulatory compliance requirements
SBOM Generation for C/C++ Projects
Generating SBOMs for C/C++ projects is challenging because of the complexity and legacy nature of these ecosystems. It is not simple to gather the data and information needed to create comprehensive and accurate SBOMs.
The typical approach is to use package-based component mapping. However, unlike modern languages like Python or Rust, C/C++ doesn’t have a widely adopted package manager, making it difficult to automatically track dependencies.
Without the availability of package managers, each C/C++ SBOM generator has to take an unorthodox approach to SBOM generation, whether it’s by relying on the compiler’s use of files during the build process, the generation of symbols during compilation, or methods yet to be developed. However, each method provides absolute clarity into the build process as it is happening, resulting in high fidelity with no package manager required.
A build-time approach is ideal for real-time and embedded software, giving visibility into your software components with a full dependency tree.
Build-Time SBOMs Lead the Way in Modern Software Security and Compliance
Selecting the right SBOM generation method is vital for ensuring secure and compliant software products. The key to success is choosing an SBOM generation strategy that fits your specific needs, factoring in elements like source code accessibility, development processes, and desired accuracy.
No matter the approach, adopting strong SBOM practices is essential to meet regulatory standards, effectively manage vulnerabilities, and deliver secure, resilient software.
