The Life of an SBOM: Where does it go and what do organizations do to it and with it?

The Life of an SBOM: Where does it go and what do organizations do to it and with it?

Speakers: Anita D'Amico (Vigilant Ops); Ken Zalevsky (Bayer)

Conference: BSides NYC

YouTube: https://www.youtube.com/watch?v=tv9N7dPLYvQ

Overview

In an era of increasing software supply chain attacks and regulatory scrutiny, the Software Bill of Materials (SBOM) has emerged as a critical tool for transparency and risk management. This talk, presented by industry veterans Anita D'Amico and Ken Zalevsky, delves into the often-overlooked "life" of an SBOM beyond its initial generation. They explore the complex journey an SBOM takes from producer to consumer, highlighting the operational challenges and strategic opportunities for leveraging this data to enhance security, compliance, and maintainability across diverse industries.

The presentation addresses a fundamental question posed by many in the industry: once an organization receives an SBOM, what exactly are they supposed to do with it? D'Amico and Zalevsky synthesize insights from leading cybersecurity agencies like CISA, NSA, and NIST to outline a comprehensive framework for SBOM lifecycle management, also known as SBOM operations. Their discussion moves beyond the "check-the-box" mentality, illustrating how sophisticated processing, analysis, and integration of SBOM data can transform it into an actionable asset for both software producers and consumers, particularly in highly regulated sectors such as medical technology and government contracting.

The talk underscores the dynamic, multi-stakeholder nature of SBOM utilization, involving everyone from software release engineers and AppSec teams to procurement officers and field service representatives. By dissecting the essential and advanced operations, the speakers reveal how SBOMs can be verified, enriched with vulnerability data, merged into complex system-level views, and tailored for specific audiences, ultimately enabling more proactive defense against cyber threats and more robust compliance postures.

Background

▶ Watch: Introduction and audience questions about SBOM utility (0:00)

The motivation for generating and consuming Software Bills of Materials (SBOMs) has escalated significantly in recent years, driven by a confluence of executive mandates, regulatory requirements, and a growing awareness of software supply chain risks. A pivotal moment was the U.S. Executive Order 14028, issued in May 2021, which mandated SBOMs for government contractors, signaling a clear governmental push towards greater software transparency. This was closely followed by sector-specific regulations, such as the FDA's final guidance at the end of 2023, which now requires pre-market submissions for medical devices to include SBOMs. These mandates highlight a broader industry shift towards demanding greater visibility into the components that make up commercial software.

At its core, an SBOM is an inventory of the software components that comprise a system. The National Telecommunications and Information Administration (NTIA) has established a minimum set of requirements for an SBOM, which includes the supplier name, component name, and component version. These elements are crucial for identifying and tracking software components. SBOMs are typically formatted using industry standards such as SPDX (Software Package Data Exchange) and CycloneDX, with SWID (Software Identification Tagging) also recognized. However, a critical point emphasized by the speakers is that vulnerabilities are notably absent from the NTIA's minimum data elements. This means that a raw SBOM, while foundational, is not inherently actionable for security purposes. Organizations must perform additional operations to derive security intelligence from it.

The challenge lies in transitioning from merely generating an SBOM to effectively consuming and managing it throughout its lifecycle. This emerging field, termed SBOM lifecycle management or SBOM operations, aims to address the complexities of integrating SBOMs into existing security and operational workflows. It involves a dynamic interplay between software producers, distributors, and consumers, each with distinct needs and responsibilities. The speakers synthesized information from CISA, NSA, and NIST to construct a holistic view of these operations, acknowledging that the industry is still in its nascent stages of developing a standardized vernacular and best practices for this critical area.

Key Findings

▶ Watch: Regulatory push and motivation for SBOM adoption (4:00)

The central finding presented by D'Amico and Zalevsky is that the true value of an SBOM is unlocked not merely through its generation, but through its comprehensive lifecycle management and operationalization. This involves a sophisticated, multi-stage process that extends far beyond a simple "check-the-box" compliance exercise. They delineate three primary phases: software production, dissemination/sharing, and software consumption, each with its own set of critical operations and stakeholders.

One of the most significant contributions is the emphasis on differentiating between build SBOMs and deployed SBOMs. A build SBOM is generated during the software development and CI/CD pipeline, reflecting the components intended to be in the software. A deployed SBOM, however, is generated from a device or system in the field, capturing the actual components running, which may include runtime dependencies or reflect "drift" from the original build due to patches or other modifications. The speakers introduce the concept of a comprehensive SBOM, which merges both build and deployed SBOMs to provide a complete and accurate picture of all software components and their associated vulnerabilities, thus preventing blind spots.

Another key finding revolves around the criticality of transitive dependencies. Software components frequently rely on other components, which in turn rely on still others, creating a deep chain of dependencies. Without understanding these transitive relationships (e.g., if component A depends on B, and B depends on C, then A indirectly depends on C), organizations cannot accurately assess the impact of a vulnerability in a deeply nested component. This reachability analysis is vital for effective vulnerability management. The complexity further escalates with Sys-SBOMs (systems of SBOMs), where an overall system (like a car's infotainment system or an OR monitoring system) comprises multiple sub-systems, each with its own SBOM, necessitating a hierarchical merging capability.

The talk also highlights specific use cases that underscore the importance of advanced SBOM operations:

• Software Development: Comparing SBOMs to identify differences between software builds or versions, and to detect critical components appearing across multiple system parts.
• Risk Management: Assessing licensing, security, and policy compliance risks.
• Procurement: Using SBOMs to inform purchasing decisions, with some consumers now demanding vulnerability analyses and even end-of-life (EOL) information before acquisition.
• Incident Response: Rapidly identifying affected assets during critical vulnerabilities like Log4j by querying SBOMs across an entire inventory.
• Medical Technology: Supporting FDA pre-market submissions, continuously monitoring fielded devices for drift and vulnerabilities, and proactively planning for post-market updates. Ken Zalevsky cited an example where the FDA issued a warning against a Hospira pump due to unaddressed critical vulnerabilities, leading to its removal from many hospitals, demonstrating the severe consequences of neglecting device security. The average hospital takes 277 days to respond to a vulnerability, largely due to a lack of transparency, making SBOMs a crucial tool for accelerating this response.

Finally, the speakers pointed to the emerging need for SBOM clearinghouses or repositories, particularly within specific industry verticals like automotive or healthcare (e.g., ISACs), to centralize and streamline the dissemination and consumption of SBOMs, moving beyond the current ad-hoc email-based sharing.

Technical Deep Dive

▶ Watch: Defining SBOMs and their minimum required elements (5:00)

The technical core of SBOM lifecycle management revolves around several sophisticated operations designed to transform raw component lists into actionable security intelligence.

1. SBOM Generation and Verification:

The journey begins with generating SBOMs, distinguishing between build SBOMs (created during the CI/CD pipeline) and deployed SBOMs (generated from devices in the field to capture runtime dependencies and drift). Once generated, SBOMs must be verified against standards like NTIA's minimum elements, ensuring they are complete and adhere to acceptable formats (SPDX, CycloneDX, SWID). This verification process is foundational for ensuring the integrity and usability of the SBOM data. In regulated industries, this often includes a rigorous review and approval process to certify the SBOM's accuracy before release.

2. Managing Transitive Dependencies:

A critical technical challenge is the comprehensive identification and management of transitive dependencies. As software components often rely on other components, which in turn rely on still others, a vulnerability in a deeply nested component can have a cascading impact. The analogy of "A depends on B, and B depends on C, therefore A depends on C" illustrates this. Without mapping these hidden dependencies, an organization cannot accurately assess the true attack surface. Effective SBOM solutions perform reachability analysis to trace these chains, ensuring that vulnerabilities in any part of the dependency tree are identified and attributed to the top-level application.

3. Comprehensive SBOMs and Drift Detection:

The concept of a comprehensive SBOM is a technical advancement that addresses the "drift" between software as it’s built and as it’s deployed. By merging the build SBOM with a deployed SBOM, generated from the actual running system, organizations can detect discrepancies, such as unrecorded updates, missing security patches, or unexpected runtime libraries. This combined view provides a more accurate and complete inventory, crucial for field service operations in sectors like medical technology, where technicians can compare the "should be" (build SBOM) with the "is" (deployed SBOM) to diagnose and rectify issues on a $2 million scanner in a hospital.

4. Advanced SBOM Operations for Actionability:

Beyond basic generation and storage, advanced SBOM operations are crucial for making SBOMs actionable:

• Audit Trails and Certification: All actions taken on an SBOM—from initial generation to vulnerability dispositioning—must be recorded in an audit trail. This trail supports a review and approval workflow, leading to a "verified" or "certified" SBOM that has undergone rigorous scrutiny, rather than merely being an engineering output. This is particularly vital in highly regulated environments.
• Vulnerability Dispositioning: Since raw SBOMs typically lack vulnerability information, advanced systems integrate with vulnerability databases (like NVD) and proprietary sources. Engineers can then disposition identified vulnerabilities, ranking them by severity (e.g., CVSS score), exploitability, and actual impact within the specific software context. This process eliminates "noise" for consumers, providing a curated list of relevant vulnerabilities and their mitigation strategies.
• Merging Multiple SBOMs (Sys-SBOMs): For complex systems composed of multiple sub-components (e.g., an infotainment system in a car, or an OR monitoring system with separate heart rate, oxygen, and blood pressure modules), the ability to merge multiple SBOMs into a hierarchical Sys-SBOM is essential. This creates a unified, system-level view of all software components, allowing for holistic risk assessment.
• Tailoring SBOMs for Dissemination: While producers may maintain an "enriched SBOM" internally with all details, they often need to tailor the SBOM for external consumption. This involves deciding how many levels of transitive dependencies to expose, redacting proprietary supplier information, or only sharing vulnerabilities above a certain severity threshold. This ensures appropriate information sharing without over-exposing sensitive internal data.
• Consumer-Side Intelligence: Sophisticated consumers leverage SBOMs by storing them centrally, sorting them by supplier or component, and performing simple scoring (e.g., averaging CVSS scores for components within an SBOM) to assess product risk. This data feeds into vendor risk management and GRC (Governance, Risk, and Compliance) systems, allowing for policy enforcement (e.g., rejecting software with CVSS scores over 7) and even influencing purchasing decisions (e.g., demanding support discounts for products without SBOMs).

5. Continuous Vulnerability Monitoring:

The dynamic nature of vulnerabilities requires that SBOMs are not a static artifact. Continuous vulnerability monitoring is essential. Even if the software version remains constant, new vulnerabilities (CVEs) are constantly discovered against existing components. An effective SBOM management system continuously scans SBOM components against up-to-date vulnerability feeds, alerting both producers and consumers to newly emerging threats that impact their software inventory.

Demo / Proof of Concept

▶ Watch: Crucial: SBOM minimum data doesn't include vulnerabilities (6:08)

While the presentation did not include a live demonstration of a specific tool, the speakers extensively described the capabilities and functionalities of an SBOM management platform, using Vigilant Ops (where Anita D'Amico is involved and Ken Zalevsky launched) as an example of a solution addressing these challenges. They outlined how such a platform would operate to implement the advanced SBOM lifecycle management concepts discussed.

The described capabilities of such a system include:

• Import and Generation: The ability to import SBOMs from various manufacturers and to generate an organization's own SBOMs directly within the tool.
• Centralized Management: A structured environment to pull all SBOMs into a unified management structure.
• Automated Analysis: Tools for automated vulnerability analysis, including the dispositioning of vulnerabilities based on criteria like exploitability and impact.
• Review and Approval Workflows: A built-in system to facilitate the rigorous review and approval processes required, especially in regulated industries, ensuring SBOM verification and certification.
• Merging Capabilities: Functionality to merge multiple SBOMs, including hierarchical merging for complex systems (Sys-SBOMs), as demonstrated by Vigilant Ops' approach to combining SBOMs from various sub-components into a comprehensive system view.
• Tailoring and Dissemination: Features to tailor SBOMs before sharing, allowing producers to control the depth of information (e.g., number of transitive dependency levels) and redact proprietary data.
• Compliance Engine: A robust compliance engine that allows consumers to set rules, such as automatically flagging or rejecting software with components exceeding a certain CVSS score (e.g., CVSS over 7), and to communicate these policy violations back to vendors.
• Continuous Monitoring: Integration with vulnerability databases and other sources to provide continuous monitoring of components for new vulnerabilities, correlating them with existing SBOMs.

These described functionalities serve as a conceptual proof-of-concept for how a dedicated SBOM management solution can operationalize the complex processes detailed in the talk, moving the industry beyond manual, email-based sharing and static analysis.

Defensive Implications

▶ Watch: Making SBOMs actionable: Introducing SBOM lifecycle management (7:30)

The detailed exploration of SBOM lifecycle management offers critical insights for both software producers and consumers looking to bolster their defensive postures against supply chain attacks and improve overall security hygiene.

For Software Producers:

• Generate Comprehensive SBOMs: Go beyond basic build SBOMs. Implement processes to generate deployed SBOMs from fielded devices and merge them with build SBOMs to create comprehensive SBOMs. This holistic view is crucial for identifying all vulnerabilities, including those introduced by runtime dependencies or field-level drift.
• Map Transitive Dependencies: Ensure SBOM generation tools capture all levels of transitive dependencies. Understanding the full dependency tree is paramount for accurate vulnerability assessment and reachability analysis.
• Implement Rigorous Verification and Certification: Establish clear review and approval processes for SBOMs. This includes verifying compliance with NTIA minimum elements and industry formats (SPDX, CycloneDX) and maintaining detailed audit trails of all modifications and dispositions. Aim for "verified" or "certified" SBOMs, especially in regulated environments.
• Proactive Vulnerability Dispositioning: Don't just list vulnerabilities. Actively disposition them by assessing exploitability, impact, and mitigation status. This allows producers to provide consumers with actionable intelligence, reducing "noise" and fostering trust.
• Automate Dissemination: Move away from manual SBOM sharing. Invest in automated direct push or pull mechanisms to securely deliver SBOMs to consumers, ensuring timely updates and better integrity.
• Consider Tailoring: Develop capabilities to tailor SBOMs for different consumer needs, providing relevant security information without over-exposing proprietary details.

For Software Consumers:

• Demand Detailed SBOMs: When acquiring software, specifically request SBOMs that include transitive dependencies beyond the first level. Inquire about the vendor's SBOM generation and verification processes.
• Integrate SBOMs into Asset Management: Treat SBOMs as a critical data source for asset management systems. Linking SBOM components to deployed assets provides a richer, more complete picture of the installed software base and its associated risks.
• Establish Policy-Driven Consumption: Implement compliance engines to automatically evaluate incoming SBOMs against predefined security policies (e.g., rejecting software with components having CVSS scores over 7). This allows for automated pushback to vendors on unacceptable risk levels.
• Continuous Vulnerability Monitoring: SBOMs are not static. Implement systems for continuous vulnerability monitoring that regularly check SBOM components against new CVEs, enabling rapid identification and response to emerging threats like Log4j. The average 277-day hospital response time to vulnerabilities underscores this necessity.
• Leverage for Vendor Risk Management: Utilize SBOM data (e.g., average CVSS scores per SBOM, vendor compliance with policies) to inform and enhance vendor risk management and GRC systems. This can influence purchasing decisions and even support contract negotiations (e.g., demanding support discounts if SBOMs are not provided).
• Plan for End-of-Life: Request and track end-of-life (EOL) information for components within SBOMs to mitigate long-term maintainability risks, a growing concern for procurement officers.

By adopting these defensive strategies, organizations can transform SBOMs from a mere compliance burden into a powerful tool for proactive security, informed decision-making, and robust supply chain resilience.

Key Takeaways

• SBOMs are foundational but require processing: While increasingly mandated (e.g., EO 14028, FDA guidance), raw SBOMs with NTIA's minimum elements are not inherently actionable for security; they lack vulnerability information and require further processing.
• SBOM lifecycle management is critical for value extraction: The true power of SBOMs lies in comprehensive SBOM operations, which span generation, verification, dissemination, and sophisticated consumption, involving multiple stakeholders across the software supply chain.
• Comprehensive SBOMs and transitive dependencies are essential: Merging build SBOMs with deployed SBOMs creates a comprehensive SBOM that accounts for "drift" and runtime dependencies. Understanding transitive dependencies is crucial for accurate vulnerability assessment and reachability analysis.
• Advanced operations transform SBOMs into intelligence: Verification, audit trails, vulnerability dispositioning, hierarchical merging (Sys-SBOMs), and tailoring are advanced operations that convert raw SBOM data into curated, actionable security intelligence for both producers and consumers.
• Continuous monitoring and policy enforcement are vital: SBOMs enable continuous vulnerability monitoring against newly disclosed CVEs and facilitate policy-driven consumption (e.g., rejecting software with CVSS scores over 7). They are powerful tools for vendor risk management and incident response.
• The industry is evolving towards automation and clearinghouses: The shift is towards automated SBOM management solutions and the emergence of SBOM clearinghouses (e.g., ISACs) to streamline secure sharing and consumption across industry verticals, moving beyond current manual processes.

About the Speaker(s)

Ken Zalevsky brings over two decades of experience in medical technology cybersecurity. He spent 20 years running the medical device cybersecurity function at Bayer, gaining extensive front-line experience in one of the most highly regulated industries. His insights in the talk are particularly valuable for understanding the practical applications and challenges of SBOMs in healthcare, including FDA regulations and post-market surveillance.

Anita D'Amico is a seasoned expert in software supply chain security. She previously led the software supply chain security product strategy at Synopsys Software Integrity Group, which includes well-known tools like BlackDuck, Coverity, and Defensics. Having retired from Synopsys, she now works with small businesses, such as Vigilant Ops, that specialize in SBOM management, bringing a wealth of knowledge on product strategy and the emerging market of SBOM operations.