With the rising security risks from insecure open-source components, malware inside proprietary tools, risky configuration codes, and others, organizations are increasing their demand for solutions to secure their end-to-end software supply chains.  A Software Bill of Material is an inventory of all of the components that exist within a software resource such as third-party libraries & modules and simplifies the process of identifying components that developers integrate directly into an application by importing them into its source code as well as dependencies. SBOM is essential for securing software supply chains by providing a detailed inventory of all application components, including third-party libraries and dependencies. This visibility helps organizations mitigate risks associated with vulnerabilities in these components, which could be exploited by malicious actors. SBOMs adhere to structured formats like SPDX, CycloneDX, or CPE, facilitating accurate documentation and compliance with regulatory requirements.

Automated SBOM generation during the Software Delivery Lifecycle (SDLC) ensures efficiency and thoroughness in identifying software components from the outset of development. The importance of SBOMs has been underscored by regulatory mandates following high-profile supply chain incidents, emphasizing their role as a standard security practice across industries. Ultimately, SBOMs enable organizations to proactively manage risks, protect against emerging threats like zero-day vulnerabilities, and maintain trust in their software environments reliant on third-party software.

Considering the vastness & complexity of this topic, I attended a webinar by Mike McGuire, Senior Software Solutions Manager at Synopsys where he provided an overview of SBOM types, their architecture, benefits, limitations, and essential management practices. The highlights of the blog are as follows:

Understanding SBOM Types

According to McGuire, there are six types of SBOMs, as recognized by CISA (Cybersecurity and Infrastructure Security Agency):

1. Plan SBOM: Designed during the planning phase of software development, this SBOM outlines the planned components and is derived from specifications or concepts. It's created manually.
2. Develop SBOM: Generated during the development phase, this SBOM sources information from development environments, source files, and dependencies used to build the software artifact. It involves mainly automated processes with some manual clarifications.
3. Build SBOM: Created as part of the build process, this SBOM utilizes source files, dependencies, built components, and potentially other SBOMs. It is generated through automated means.
4. Test SBOM: This SBOM is derived from the analysis of artifacts post-build and is often referred to as a "third-party SBOM." It primarily involves automated methods and tooling.
5. Release SBOM: Deployed during the release phase, this SBOM represents the inventory of software present on a system. It includes other SBOMs, analysis of configuration options, and examines execution behaviour. It's manually recorded.
6. Configure SBOM: Also known as a "runtime SBOM," this captures elements present in a system, external call-outs, and dynamically loaded components during runtime. It's generated through automated processes and tooling.

Benefits and Limitations of SBOMs

Each type of SBOM offers distinct benefits and limitations:

• Plan SBOM: Benefits include early issue resolution and defining development parameters, but it may differ vastly from the final product.
• Develop SBOM: Enables early issue resolution without needing build tool access, but it can be overly inclusive or exclusive.
• Build SBOM: Provides an accurate representation of artifacts but may miss indirect or runtime components.
• Test SBOM: Requires no access to source code or build environment, but can be prone to errors.
• Release SBOM: Identifies installed software but may interfere with install processes.
• Configure SBOM: Provides real-time information on active components but involves overhead and runtime for accuracy.

Best Practices in SBOM Management

McGuire emphasized several key practices for effective SBOM management:

• Software Composition Analysis: Essential for identifying open-source dependencies, custom components, base images, and third-party libraries.
• Security Considerations: Evaluating vulnerability severity, compliance with OWASP and SANS standards, and ensuring fixability.
• Compliance Checks: Assessing license compatibility, adhering to approved/prohibited licenses, and integrating into workflow triggers.
• Quality Assessment: Reviewing version history, and development activity, and validating components and versions.

SBOM Lifecycle Management Process

To ensure robust management throughout the SBOM lifecycle, McGuire highlighted these critical steps:

• Creation/Maintenance: Governance and compliance, tool enablement, generation, integration within SDLC, and attestation.
• Storage: Mechanisms for storage and archival processes.
• Consumption: Processes for vendor consumption, vulnerability, and risk management workflows.
• Sharing: External and internal processes for SBOM integrity and legal considerations.
• Searchability: Establishing search processes across assets and building dashboards by product and version.

Analyst’s Comment: Software Bill of Materials (SBOM) serves as a foundational asset in modern software security and compliance strategies. Effective SBOM management, including rigorous software composition analysis and meticulous governance, empowers organizations to navigate complex digital landscapes with confidence. It enables proactive risk mitigation, preserves software integrity, and fosters transparency, essential for safeguarding against emerging threats and maintaining trust in software supply chains. The webinar provided a comprehensive overview  of SBOM and highlighted the importance of understanding & implementing crucial management practices essential for organizations aiming to enhance software transparency, security, and compliance within the development & operational processes".

Author: Nikhilesh Naik | Principal Industry Analyst at Quadrant Knowledge Solutions