SBOMs: Navigating the Evolving Landscape of Software Bill of Materials

SBOMs: Navigating the Evolving Landscape of Software Bill of Materials

Speakers: Manoj, Managing Security and Engineering, Predigo

Conference: RSAC 2024

YouTube: https://www.youtube.com/watch?v=NYCNRg7F-c4

Overview

Manoj's talk at RSAC 2024, "SBOMs: Navigating the Evolving Landscape of Software Bill of Materials," delves into the transformative shift in how organizations approach software supply chain transparency. With increasing governmental regulations and a surge in supply chain attacks, the traditional methods of providing assurance—such as terms of use, licenses, and certifications—are proving insufficient. This presentation outlines the critical evolution from a self-regulated, contract-based transparency model to a legally mandated, standardized approach centered around Software Bill of Materials (SBOMs) and Vulnerability Exploitability eXchange (VEX).

The core of the talk emphasizes that digital infrastructure is now recognized as being as critical as physical infrastructure, a paradigm shift driving global regulatory efforts to enforce greater transparency in software development. Manoj, drawing from his experience in the field since the 2021 U.S. Executive Order on supply chain security, provides a mental model for understanding this evolving landscape. He highlights how SBOMs, initially conceived for software components, are expanding to encompass data provenance, infrastructure, and even AI components, thereby offering a comprehensive inventory and paving the way for automated security controls.

This article explores the driving forces behind this evolution, the technical standards and tools facilitating it, and the profound implications for governance, risk, compliance (GRC), and security teams. It underscores the urgent need for organizations to embrace SBOMs not merely as a compliance burden but as a strategic enabler for enhanced security posture, risk quantification, and automated policy enforcement across the entire software development lifecycle (SDLC).

Background

▶ Watch: Introduction and the evolving software supply chain landscape (0:00)

Historically, software transparency and accountability have largely been governed by private contracts and self-attestations. As Manoj explains, the "current version of transparency" involves providing terms of use, licenses, and privacy statements to define user rights, provider accountability, and data handling. Further trust is established through certifications like SOC, High Trust, and ISO. This model, however, places the onus on individual software providers to decide the level of detail they disclose, lacking standardization and a unified legal framework for liability.

The limitations of this approach have become increasingly apparent. Manoj cites a striking statistic from a keynote speaker at RSAC 2024, noting that 40% of attacks are now through exploits on the software supply chain, rather than traditional social engineering. This dramatic shift signifies a reduced cost for attackers to compromise systems via the supply chain, rendering existing transparency insufficient for customers to secure their software or for providers to secure their infrastructure.

This inadequacy has spurred a significant industry shift, moving towards what Manoj terms "2.0" and "3.0" in transparency. The "2.0" phase is characterized by the emergence of legal frameworks that codify liability and mandate the provision of SBOMs and VEX. This includes requirements for a "visual for every customer of your product into the ingredients" and "full transparency into what are the vulnerabilities coming along with it." This enables customers to quantify risk more effectively. The "3.0" phase envisions extending this transparency beyond just software dependencies to track all attack surfaces, including infrastructure, data infrastructure, and components used in AI systems. This broader scope aims to create a comprehensive inventory, enabling the automation of currently manual control execution and implementation.

The primary incentive for this rapid evolution is a wave of regulations worldwide. In the U.S., the May 2021 Executive Order mandated SBOMs and vulnerability information for software supplied to the federal government. This was followed by the FDA and Medical Devices Act in 2022, which specifically required SBOMs, VEX, and end-of-life (EOL) information for software in medical devices, classifying them as critical infrastructure. Similar legislative actions are emerging globally: Germany's IT Security Act, Finland's initiatives, the EU's comprehensive Cyber Resiliency Act, and recent discussions in Australia and Singapore, all underscore a universal recognition of digital infrastructure as critical. This global regulatory push is transforming transparency from an optional, contract-driven choice into a mandatory, legally enforced requirement, fundamentally altering how accountability and liability are assigned in the software ecosystem.

Key Findings

▶ Watch: 40% of attacks now target the software supply chain (3:20)

Manoj's talk highlights several pivotal findings regarding the evolving landscape of software supply chain security and the role of SBOMs:

1. Shift from Private to Codified Liability: The most significant finding is the transition of software liability and transparency from private, contract-based agreements to legally mandated, standardized frameworks. Governments worldwide are enacting regulations (e.g., US Executive Order, EU Cyber Resiliency Act) that compel software producers to provide SBOMs and VEX, thereby codifying liability and accountability in a deterministic manner. This removes the "optional" nature of transparency, making it a required element for software producers, especially when dealing with critical infrastructure or government entities.

1. Digital Infrastructure as Critical Infrastructure: A foundational shift in perspective is the global acknowledgment that digital infrastructure (software, SaaS platforms, IoT) is as critical to national function and everyday life as physical infrastructure (roads, utilities). This recognition is the underlying driver for increased government intervention and regulatory pressure to enhance cyber resiliency through greater transparency.

1. Expansion of SBOM Scope (SBOM 3.0): The concept of an SBOM is rapidly evolving beyond merely listing software components. Manoj introduces "SBOM 3.0," which extends transparency to encompass data provenance, infrastructure configurations, and AI components. This broader scope aims to provide a comprehensive inventory of all artifacts consumed and generated, enabling organizations to track new attack surfaces, particularly those emerging from the explosion of interest in AI.

1. Automation of Security Controls: By codifying artifacts across software, data, and infrastructure, organizations can move from manual control execution to automated control implementation. This high-fidelity inventory allows for the enforcement of security policies as code, reducing manual effort for GRC and security teams and significantly improving incident response times.

1. Immature but Evolving Tooling Landscape: While the regulatory push for SBOMs is strong, the tools for generating, managing, and enforcing policies based on SBOMs are still maturing. Manoj acknowledges that while open-source and commercial tools exist for generation and distribution, robust capabilities for policy codification (e.g., automatically preventing release if build policies are not met) are not yet fully realized. This presents both a challenge and an opportunity for innovation in the security tooling space.

Technical Deep Dive

▶ Watch: Transparency 2.0: Legal framework for SBOMs and product ingredients (4:30)

The technical foundation of this evolving transparency landscape rests on standardized formats and emerging tools, designed to represent and manage software ingredients, vulnerabilities, and development processes in a machine-readable, auditable manner.

1. Standards for Software Ingredients (SBOM Formats):

To represent the components and libraries used in a software product, several key standards are gaining traction:

• SPDX (Software Package Data Exchange): Developed by the Linux Foundation, SPDX is a widely adopted open standard for communicating SBOM information, including components, licenses, copyrights, and security references.
• CycloneDX: An OWASP project, CycloneDX is a lightweight SBOM specification designed for use in application security contexts and supply chain component analysis. It supports a broad range of use cases, including vulnerability management, license compliance, and end-of-life tracking.
• SWID (Software Identification Tags): While not a language to represent ingredients in the same way as SPDX or CycloneDX, SWID tags are included in NIST standards for identifying software. They help uniquely identify software products and versions, which is crucial for asset management and vulnerability tracking.
• OASP (Open Worldwide Application Security Project) and OpenSSF (Open Source Security Foundation): These organizations are central to defining and promoting many of these standards and related tools.

2. Standards for Vulnerabilities (Vulnerability Exchange - VEX):

Once software ingredients are identified, the next critical step is to communicate associated vulnerabilities and their exploitability. This is where Vulnerability Exploitability eXchange (VEX) comes into play:

• CycloneDX VEX Profile: CycloneDX includes a profile specifically for VEX, allowing vendors to assert whether known vulnerabilities affect their product or not, providing context beyond raw CVE data.
• Open VEX (OpenSSF): OpenSSF also provides a standard for VEX, focusing on machine-readable formats to convey vulnerability status (e.g., "affected," "not affected," "fixed," "under investigation"). This helps customers prioritize and understand which vulnerabilities truly pose a risk to their specific deployments.

3. Standards for SDLC Maturity and Attestations:

Beyond just ingredients and vulnerabilities, transparency also extends to the development process itself. Attestations provide machine-readable information about the SDLC, enhancing trust and accountability:

• In-Toto: Supported by OpenSSF, In-Toto is a framework for securing the software supply chain by providing verifiable metadata about each step of the development process (e.g., who built what, what tests were run, what environment was used).
• CycloneDX SDLC Maturity: CycloneDX also offers mechanisms to represent aspects of SDLC maturity.
• NIST SSDF (Secure Software Development Framework): A framework from the National Institute of Standards and Technology that outlines practices for secure software development.
• Salsa (Supply chain Levels for Software Artifacts): An OpenSSF framework that provides a scorecard-like mechanism to assess the maturity and integrity of software artifacts and their supply chains.
• S2C2F (Software Supply Chain Security Compromise Framework): A framework from Microsoft, also supported by OpenSSF, focusing on preventing, detecting, and responding to supply chain compromises.

4. Tools and Ecosystem:

The practical implementation of these standards relies on a growing ecosystem of tools:

• Generation Tools: Tools like CDX gen (for CycloneDX) can generate SBOMs and attestations automatically, capturing details about build processes, pull requests, secure build environments, test execution, and static analysis.
• Signing Tools: To ensure non-repetition and accountability, digital signing processes are crucial. OpenSSF Sigstore provides a service for signing software artifacts and their metadata, allowing for verifiable attestations. CDX gen also includes signing capabilities.
• Distribution: SBOMs and VEX documents are typically distributed via artifact repositories, alongside the executables, libraries, and packages they describe.
• Open Source Software (OSS) Services: Recognizing the challenges for OSS contributors, services are emerging that build OSS packages in secure environments and generate assured SBOMs and vulnerability tracking.
• Management Tools: For consuming and analyzing numerous SBOMs, tools like OWASP Dependency Track are vital. This tool ingests SBOMs, builds a comprehensive graph of dependencies, and visualizes risks, helping organizations quantify and mitigate vulnerabilities across their software portfolio.

5. Gaps and Opportunities:

Despite these advancements, Manoj acknowledges significant gaps. The maturity of tools for policy codification and automated enforcement remains a challenge. For instance, the ability to automatically "gate" a release if specific build policies (e.g., "must be built in a secure environment") are not met, as captured in an SBOM attestation, is still evolving. This points to future opportunities in integrating policy-as-code solutions, such as Open Policy Agent (OPA), directly into the SDLC, enabling automated decision-making based on SBOM data. The discussion during the Q&A further highlighted the varying confidence ratings from SCA tools (15% to 85%), especially for older firmware or custom libraries, necessitating manual verification and continuous improvement efforts with SCA vendors.

Demo / Proof of Concept

▶ Watch: Legal codification of liability and quantifying risk with SBOMs (6:00)

The talk by Manoj did not feature a live demonstration or a specific proof of concept of an SBOM implementation. Instead, the speaker focused on providing a comprehensive overview of the theoretical framework, regulatory drivers, technical standards, and existing tools within the evolving SBOM landscape.

However, Manoj did offer practical advice on how organizations can initiate their SBOM journey, effectively outlining a phased implementation strategy that can serve as a conceptual "mini-demo" or actionable roadmap:

1. Start Small: Identify one critical component or product within your organization.
2. Add SBOM: Implement SBOM generation for this component first.
3. Add Attestation: Integrate attestations to capture details about the software's build process and SDLC maturity.
4. Add VAX: Incorporate Vulnerability Exploitability eXchange (VEX) to communicate the exploitability status of vulnerabilities.
5. Add End-of-Life Information: For critical systems, include end-of-life (EOL) data for components.

This structured approach allows organizations to gradually integrate SBOM practices and gain experience. While no live demo was presented, the speaker referenced tools like OWASP Dependency Track as an example of how organizations can manage and visualize hundreds of SBOMs to quantify risk, providing a conceptual understanding of how such a system would function.

Defensive Implications

▶ Watch: Beyond SBOMs: The promise of Transparency 3.0 (6:30)

The widespread adoption of SBOMs and related transparency frameworks carries significant defensive implications for both GRC personnel and security teams. This paradigm shift offers unprecedented visibility and control, transforming reactive security measures into proactive, automated processes.

For GRC and Governance Teams:

• High-Fidelity Inventory: SBOMs provide a machine-readable, high-fidelity inventory of all software, its dependencies, and even the processes used to build it. This eliminates the manual effort of tracking components, significantly reducing "catch-up" mode and team burn.
• Automated Compliance: With standardized SBOMs, GRC teams can automate checks against regulatory requirements (e.g., Executive Order, Cyber Resiliency Act). The information contained within SBOMs and attestations can be used to prove adherence to secure SDLC practices and vulnerability management policies.
• Streamlined Incident Response: A clear, up-to-date inventory of components allows for much faster identification of affected systems during an incident or when a new critical vulnerability (like Log4Shell) emerges. This drastically reduces the time to respond and mitigate.
• Codified Liability: The legal frameworks pushing SBOMs provide a deterministic way to assign liability. GRC teams can leverage this transparency to understand and manage their organization's legal exposure related to software supply chain risks.
• Policy Enforcement as Code: The ultimate goal is to enable GRC teams to enforce policies programmatically. Instead of manually auditing teams, policies can be embedded into the SDLC, automatically preventing releases if SBOM attestations indicate non-compliance (e.g., "not built in a secure environment"). This moves GRC from a policing function to an enabler of secure development.

For Security Teams:

• Targeted Mitigations: A detailed SBOM allows security teams to precisely identify which components are present in their software and, crucially, which specific versions are in use. This enables highly targeted and efficient vulnerability remediation efforts, avoiding broad, untargeted patching.
• Automated Policy Implementation: Security policies, such as mandating the use of specific secure libraries or disallowing known vulnerable versions, can be automatically checked and enforced using SBOM data. This removes human error and ensures consistent application of security standards across the organization.
• Enhanced Risk Quantification: By combining SBOM data with VEX information, security teams can accurately quantify the actual risk posed by vulnerabilities. A VEX document might indicate that a known CVE in a dependency is not exploitable in a specific product context, allowing teams to de-prioritize non-critical issues and focus on real threats.
• Proactive Vulnerability Management: With SBOMs, security teams gain a proactive stance. They can monitor upstream dependencies for new vulnerabilities and, thanks to the high-fidelity inventory, quickly identify which of their products are affected, even before a public disclosure.
• Managing Transparency Risks: While providing transparency is crucial, security teams must also manage the risk of over-sharing. As discussed in the Q&A, organizations can filter the information provided to customers, sharing only the minimum required by regulation while retaining full internal visibility. This balances the need for external trust with the protection of proprietary build configurations or sensitive internal details.

In essence, SBOMs empower defensive teams by transforming opaque software supply chains into transparent, auditable, and automatable systems, leading to more resilient and secure digital infrastructure.

Key Takeaways

• Digital Infrastructure is Critical: Governments worldwide now consider digital infrastructure as vital as physical infrastructure, driving a global regulatory push for increased transparency in software supply chains.
• Transparency is Becoming Legally Mandated: The era of optional, private contract-based software transparency is ending. Regulations like the US Executive Order and the EU Cyber Resiliency Act are making SBOMs and VEX mandatory, shifting liability from private agreements to codified legal frameworks.
• SBOM Scope is Expanding: The concept of an SBOM is evolving beyond just software components to include infrastructure, data provenance, and even AI components, aiming for a comprehensive inventory of all consumed and generated artifacts.
• Standards are Essential for Interoperability: Standardized formats like SPDX, CycloneDX, VAX (Vulnerability Exploitability eXchange), In-Toto, and frameworks like NIST SSDF and Salsa are crucial for machine-readable transparency and interoperability across the ecosystem.
• Tools are Maturing, But Gaps Remain: While tools exist for SBOM generation (e.g., CDX gen), signing (OpenSSF Sigstore), and management (OWASP Dependency Track), capabilities for automated policy enforcement and robust policy-as-code integration are still developing.
• Start Small and Automate: Organizations should begin by integrating SBOM generation into their SDLC for critical components, gradually adding attestations, VEX, and end-of-life information. This incremental approach facilitates automation of vulnerability management and policy enforcement, reducing manual effort for GRC and security teams.

About the Speaker(s)

Manoj is the Managing Security and Engineering at Predigo, an ML startup. He has been deeply involved in the Software Bill of Materials (SBOM) space for approximately the last three years, specifically since the U.S. Executive Order in 2021 brought increased attention to software supply chain transparency. His expertise spans security assurance and governance, with a particular focus on understanding and mitigating the impacts of evolving regulations and emerging technologies like AI on the software supply chain. Manoj also shares his insights by lecturing students at Western Washington, emphasizing practical approaches to vulnerability management and policy enforcement through SBOMs.