SBOMs in the Real World: Practical Guidance for Managing Three Common SBOM Scenarios

SBOMs in the Real World: Practical Guidance for Managing Three Common SBOM Scenarios

Speakers: Cortez Fraser Jr., Principal Product Manager, FASA

Conference: VulnCon

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

Overview

In an insightful and opinionated presentation at VulnCon, Cortez Fraser Jr., Principal Product Manager at FASA, delved into the evolving landscape of Software Bill of Materials (SBOMs), moving beyond theoretical discussions to practical, real-world applications. The talk, titled "SBOMs in the Real World: Practical Guidance for Managing Three Common SBOM Scenarios," aimed to equip security professionals and developers with actionable strategies for integrating SBOMs into their security postures. Fraser highlighted that while the concept of SBOMs has gained widespread recognition, their effective implementation and utilization remain a significant challenge for many organizations.

Fraser’s presentation was structured around three progressively complex scenarios: the fundamental generation and distribution of SBOMs, their internal consumption for centralized vulnerability management, and their critical role in enforcing supply chain standards with external suppliers. He emphasized the growing regulatory pressures, citing instances like the SolarWinds attack and new mandates such as the Cyber Resilience Act (CRA) and PCI 4.0 DSS, as key drivers for this shift. Beyond compliance, Fraser argued that true value lies in leveraging SBOMs for deeper software supply chain transparency, enabling proactive risk management and more efficient remediation efforts.

A central theme of the talk was challenging common misconceptions and hesitations surrounding SBOM adoption, particularly the fear of intellectual property (IP) disclosure or providing a "blueprint" for attackers. Fraser, known for his strong opinions, confidently debunked these concerns, advocating for greater industry transparency. He presented detailed workflows, technical considerations, and best practices for each scenario, drawing from his extensive experience working with companies at various stages of SBOM maturity. The session underscored that while the journey to full SBOM maturity is complex, it is an undeniable necessity for modern software security.

Background

▶ Watch: Speaker introduction and FASA's SBOM journey (0:00)

The journey of SBOMs from a theoretical concept to a critical component of software security has been significantly accelerated by recent events and regulatory mandates. Cortez Fraser Jr. began by acknowledging the universal awareness of SBOMs, a stark contrast to just two years prior. This progress is largely attributed to a series of high-profile software supply chain attacks, most notably SolarWinds, which exposed the critical need for greater visibility into third-party components. Fraser pointed out that the SolarWinds attack actually targeted a developer environment, highlighting that attack surfaces extend far beyond production code.

Regulatory environments are now a primary driver for SBOM adoption. Fraser cited several key regulations:

• Cyber Resilience Act (CRA): A prominent topic at VulnCon, emphasizing cybersecurity for digital products.
• PCI 4.0 DSS: For the finance sector, which, like many regulations, uses obfuscated terms such as "inventory of bespoke assets" instead of explicitly naming SBOMs.
• FDA Requirements: Particularly for medical device manufacturers needing to provide pre-market and post-market submissions (501ks).
• UNR 155: A significant regulation for the automotive industry, similarly requiring an inventory of assets from Tier 1 and Tier 2 suppliers.

Fraser quickly reviewed the dominant SBOM standards: SPDX and CycloneDX. While acknowledging both, he openly expressed a strong preference for CycloneDX, believing it to be the superior standard. He briefly illustrated a typical JSON-formatted SBOM, noting that while technically an Excel sheet could be an SBOM, JSON is the preferred machine-readable format.

A crucial distinction was made between a Vulnerability Disclosure Report (VDR) and a Vulnerability Exploitability eXchange (VEX) statement. A VDR discloses all known vulnerabilities in an SBOM, while a VEX statement makes an assertion on whether a particular vulnerability is exploitable or impacts the software. Fraser highlighted ongoing industry debates regarding VEX: should it be a historical, never-ending audit log of all past vulnerabilities, or a snapshot of current impact? He strongly advocated for the historical audit trail approach, arguing it provides better completeness and preempts customer inquiries about reported vulnerabilities. He also suggested that VEX should ideally be a standalone document, separate from the static SBOM, because vulnerability assessments are dynamic even if the codebase doesn't change.

The discussion also touched upon unique identifiers for software components. While Package URL (PURL) and Omnibore ID were mentioned positively, Fraser expressed strong dissatisfaction with CPE (Common Platform Enumeration). He argued that CPEs are often not created until a vulnerability is discovered, making them unsuitable for uniquely identifying packages. Furthermore, different organizations may create conflicting CPEs for the same package. He emphasized that the goal should be to uniquely identify the asset, not just the vulnerability, making PURL a far superior standard due to its specific namespace, package, and version attributes. He illustrated this with an example: Glibc 1.3 for Debian and Glibc 1.3 for CentOS are not the same package and can have different vulnerabilities and licenses.

Finally, Fraser underscored the often-overlooked aspect of support status for packages. Knowing if a package is actively maintained, abandoned, or at its end-of-life (EOL) is critical for risk management. He acknowledged the challenge of tracking this for open-source components, where central repositories are scarce, though initiatives like Bumpgen/XL, endoflife.date, and OpenEOX are emerging.

Key Findings

▶ Watch: Regulatory drivers for SBOMs: SolarWinds, CRA, PCI (3:00)

Cortez Fraser Jr.'s talk distilled the practical application of SBOMs into three distinct, progressively advanced scenarios, each presenting its own set of challenges and ideal workflows. These scenarios represent the "key findings" or practical guidance for organizations navigating their SBOM journey.

1. SBOM Generation and Distribution (The Baseline): Fraser identified this as the starting point for over 80% of the industry. The core finding here is that organizations must achieve the capability to consistently generate and distribute accurate SBOMs at key development lifecycle stages—per build, per commit, per deployment, or per release. This foundational step is driven by regulatory compliance (e.g., CRA, FDA) and the indirect pressure from government contractors. Beyond compliance, it provides essential insight into the software supply chain, addressing vulnerabilities and license compliance risks, even revealing security impacts from unexpected license requirements (e.g., forced source code disclosure). This scenario emphasizes the necessity of a full dependency graph, including transitive dependencies, and accurate scoping (e.g., production vs. dev/test, statically vs. dynamically linked).

1. Centralized Vulnerability Management (Internal Consumption): This scenario addresses the complexities faced by large organizations that lack direct source code access across all development teams. The key finding is the need to centralize vulnerability management by consuming SBOMs from various internal teams, even when source code is inaccessible. This enables enterprise-wide decision-making for remediation efforts, promoting "the greatest overall reduction in my security posture with the least amount of refactor effort." Fraser introduced a custom, simplified iteration of SSVC (Stakeholder Specific Vulnerability Categorization) to guide decisions on when to fix a vulnerability immediately, plan for it, or integrate it into routine sprints. This approach emphasizes grouping fixes to maximize impact and minimize the "whack-a-mole" problem of introducing new vulnerabilities with upgrades.

1. Enforcing SBOM Standards on External Suppliers (External Consumption): Fraser passionately declared this his "personal favorite" scenario and the ultimate purpose of SBOMs. The core finding here is the imperative for organizations to not just generate their own SBOMs but to actively demand and validate SBOMs from their external suppliers. This is critical for establishing trust but verify relationships, ensuring supply chain transparency, and identifying unknown risks like dependency confusion or typosquatting. Fraser directly confronted and debunked common industry pushback against sharing SBOMs—the fears of IP disclosure and providing a "blueprint" for threat actors. He argued that true IP lies in how software is used and the data it generates, not in common open-source components. Furthermore, he asserted that threat actors typically perform broad, opportunistic attacks, rendering SBOMs ineffective as targeted attack blueprints. This scenario highlights the importance of consistent SBOM quality (structural and content validation) from suppliers and a robust two-way communication process for remediation.

Together, these three scenarios outline a comprehensive roadmap for organizations to mature their SBOM programs, moving from basic generation to sophisticated, enterprise-wide and supply-chain-wide risk management.

Technical Deep Dive

▶ Watch: Industry-specific SBOM regulations: FDA, Automotive, UNR 155 (4:00)

The technical core of Cortez Fraser Jr.'s talk revolved around the detailed challenges and workflows associated with each of the three SBOM scenarios. He provided specific guidance and strong opinions on best practices, tooling, and common pitfalls.

Scenario 1: SBOM Generation and Distribution

This foundational scenario focuses on how organizations create and share their SBOMs.

Technical Challenges:

• Polyglot Tooling: Modern codebases are diverse, requiring multiple scanning tools to achieve accurate component lists and full dependency graphs across different languages and ecosystems.
• Full Dependency Graph: A common mistake is scoping SBOMs to only direct dependencies. Fraser stressed the absolute necessity of including transitive dependencies and detailed relationships.
• Contextual Labeling: Dependencies need labels indicating their scope (e.g., dev, test, production) and linkage type (e.g., statically linked vs. dynamically linked), as these have vastly different security and licensing implications.
• Embedded Systems: Generating accurate SBOMs for environments without central package managers (e.g., Yocto, Buildroot) is particularly challenging. Unique identifiers like Omnibore ID are emerging, but PURL remains preferred. Fraser reiterated his disdain for CPE in this context.
• Support Status: Tracking whether open-source packages are actively maintained, abandoned, or end-of-life is crucial but often difficult due to a lack of centralized data.

Ideal Workflow:

1. Development & Integration: Developers add new functionality and packages.
2. Pull Request (PR) & Scan: On PR submission, code is scanned by internal, commercial, or homegrown tooling to surface vulnerabilities and licenses.
3. Assessment: Developers assess identified vulnerabilities (e.g., is a CVE exploitable in this context?) and license compliance (e.g., LGPL dynamically linked vs. statically linked). This assessment informs VEX and VDR assertions.
4. Merge, Deploy, Generate SBOM: The build is merged and deployed, and the SBOM is generated.
5. Application-Level SBOM Aggregation: For complex environments with multi-stage builds, monorepos, or complicated architectures, individual repository SBOMs are aggregated into a comprehensive "application-level SBOM."
6. Pinning & Monitoring: The specific commit or release associated with the SBOM is pinned for continuous monitoring and future reference, especially for multiple versions or on-prem/SaaS deployments.
7. Deployment to Production: The final, monitored artifact is deployed.

Fraser suggested that ideally, this workflow should be automated post-assessment, reducing developer overhead.

Best Practices for Distribution:

• Dynamic Analysis: SBOMs are static, but their analysis (especially for vulnerabilities) is dynamic. Organizations need processes to review and share updated analyses.
• Public/Private Sharing: Leverage platforms like the CNCF portal (for Kubernetes) or Red Hat's portal for public sharing, or secure private channels.

Scenario 2: Centralized Vulnerability Management (Internal Consumption)

This scenario addresses how large organizations can effectively manage vulnerabilities across numerous teams, often without direct access to all source code.

Technical Challenges & Concepts:

• Enterprise-wide Remediation: The goal is to achieve the greatest reduction in security posture with the least refactor effort. This requires a holistic view of vulnerabilities across similar tech stacks.
• Custom SSVC: Fraser found SSVC (Stakeholder Specific Vulnerability Categorization) to be theoretically sound but overly complex for practical decision-making. He advocated for organizations to build their own simplified decision trees to classify vulnerabilities as "fix now," "plan next quarter," or "normal sprint."
• PURL vs. CPE: Reemphasizing PURL's superiority, Fraser explained that CPE's creation only upon vulnerability discovery and its inconsistency across different entities make it unreliable for unique package identification. PURL (e.g., pkg:maven/org.apache.commons/commons-lang3@3.9) provides a consistent, unique identifier. He gave the example of Glibc 1.3 for Debian versus CentOS, which are distinct packages despite sharing a version, highlighting why unique identifiers are critical.
• SBOM Generation Point: Fraser strongly advocated for build-time SBOM generation over source-level, deploy-time, or runtime. Build-time captures the most accurate dependency graph and relationships, which are often lost or difficult to infer at runtime. He advised against blocking builds for SBOM generation, suggesting separate, parallel pipelines.

Workflow (SSVC-style Decision Tree):

1. Application-Level SBOM: Start with the aggregated SBOM from Scenario 1.
2. Import to Tooling: Ingest the SBOM into a vulnerability management tool (e.g., Dependency-Track, FASA).
3. Unique Identifier Lookup: Use PURLs to look up licenses and vulnerabilities, rather than relying solely on VEX/VDR from suppliers.
4. Criticality Assessment: Determine application criticality (e.g., crown jewel, externally facing, internal development tool). This guides initial prioritization.
5. Exploitability Context: Assess if the vulnerability is exploitable in the context of usage. This is expensive, so Fraser recommended approximating exploitability using metrics like EPSS (Exploit Prediction Scoring System), EBSS thresholds, or data from VoneCheck (MVD++).
6. Immediate Fix & Impact Analysis:

• Is an immediate fix available?
• Does the fix introduce more vulnerabilities? This "whack-a-mole" problem is common, so tooling should identify the net impact of an upgrade.

1. "BOGO Deals" & Breaking Changes:

• Does the fix remediate other vulnerabilities "for free"?
• Does the fix introduce a breaking change? If so, it requires sprintly or quarterly planning. If not, remediate immediately.

Automated Grouping: Tools can automate this by identifying "quick wins" (easy patches), "high priority" vulnerabilities (based on EPSS thresholds, reachability, CISA KEV list, ExploitDB), and "BOGO deals" (vulnerabilities fixed as a side effect of a larger upgrade).

Scenario 3: Enforcing SBOM Standards on External Suppliers (External Consumption)

This is the most advanced scenario, focusing on the "trust but verify" principle for third-party software.

Motivations:

• Supply Chain Transparency: Validating supplier claims about vulnerability and license compliance.
• Support Status: Ensuring suppliers use actively maintained components.
• Unknown Risks: Identifying threats like dependency confusion or typosquatting in supplier binaries.

Addressing Pushback (Common Misconceptions):

Fraser directly challenged two primary reasons organizations hesitate to share SBOMs:

1. Intellectual Property (IP) Disclosure: He argued that if knowing a list of common open-source or commercial packages allows reverse engineering, the application is "terrible." True IP lies in how packages are used, the data generated, and unique curation, not in components like jQuery or Glibc.
2. Threat Actor Blueprint: Fraser asserted that threat actors typically perform broad, opportunistic attacks using all known exploitable vulnerabilities, not targeted attacks based on an organization's specific SBOM. Sharing an SBOM does not provide a competitive advantage to attackers.

Requirements for Suppliers:

• Unique Identifiers (PURL): Critical for accurate component identification.
• Accurate Scopes/Labels: Understanding production vs. dev/test, static vs. dynamic linking, and support status from supplier SBOMs.

Workflow:

1. Supplier SBOM Generation & Sharing: The supplier generates an application-level SBOM and shares it with the OEM/consumer.
2. OEM SBOM Import & Validation: The OEM imports the SBOM into their tooling and performs two types of checks:

• Structural Issues: Does it conform to the required spec (e.g., CycloneDX), include NIA minimum elements, complete relationships, and VEX/VDR assertions?
• Content/Assessment Issues: Does it violate internal license compliance or vulnerability policies (e.g., critical/high vulnerabilities, EPSS thresholds)?

1. VEX Assertion Check: If a vulnerability is detected, the OEM checks for a corresponding VEX assertion from the supplier.
2. Two-way Communication: If violations or missing information are found, the OEM communicates feedback to the supplier, requiring them to go "back to the drawing board."
3. Data Enrichment (Optional but Powerful): If PURLs are present, the OEM can often enrich missing supplier or manufacturer information on their behalf, allowing focus on policy violations.
4. Continuous Monitoring & VEX Updates: As new vulnerabilities emerge, the supplier must provide updated VEX statements for existing SBOMs, even without new package introductions.
5. Combine & Pin Final Artifact: The OEM combines internal SBOM data with validated supplier SBOMs to produce a final artifact SBOM, which is then pinned and supported.

Demo / Proof of Concept

▶ Watch: Differentiating VEX and VDR: disclosure vs. exploitability (5:30)

While the talk did not feature a live demonstration or specific proof-of-concept execution with a tool, Cortez Fraser Jr. extensively detailed ideal workflows and best practices, often illustrating concepts with diagrams and examples. He frequently referenced "tooling" (both commercial and open-source like Dependency-Track) as essential for automating the complex processes described in each scenario, implying that robust tools are necessary to implement these strategies effectively. He also shared visual examples of "bad" versus "good" SBOM analysis reports, highlighting how proper identification, relationships, and VEX assertions dramatically reduce vulnerability counts by eliminating false positives and duplicates.

Defensive Implications

▶ Watch: Unresolved questions and challenges in VEX implementation (6:00)

Cortez Fraser Jr.'s detailed guidance provides a clear roadmap for defenders seeking to enhance their software supply chain security. The defensive implications span strategic shifts and tactical implementations across the entire software development lifecycle.

1. Prioritize Consistent SBOM Generation: Defenders must establish processes to generate accurate and comprehensive SBOMs at every critical stage – per build, per commit, per deployment, and per release. These SBOMs must include full dependency graphs, encompassing both direct and transitive dependencies, and precise contextual labels (e.g., production, dev, test, statically linked, dynamically linked). This foundational step provides the necessary visibility into the software's composition.
2. Implement Robust VEX Statements: Move beyond simply disclosing vulnerabilities. Defenders should proactively provide VEX (Vulnerability Exploitability eXchange) statements that assert the exploitability status of known vulnerabilities within their specific context. Fraser strongly advocates for a historical audit trail approach to VEX, ensuring that all past and present vulnerability assessments are recorded, preempting customer inquiries and providing a comprehensive security record.
3. Adopt Advanced Vulnerability Prioritization: Shift away from relying solely on CVSS scores. Instead, integrate dynamic metrics like EPSS (Exploit Prediction Scoring System), EBSS thresholds, and data from sources like CISA's Known Exploited Vulnerabilities (KEV) catalog and ExploitDB to prioritize vulnerabilities based on actual exploitability and impact. Implement SSVC-style decision trees to categorize and plan remediation efforts, focusing on "quick wins" and "BOGO deals" that address multiple vulnerabilities with minimal refactor.
4. Centralize Vulnerability Management for Enterprise-Wide Impact: For large organizations with distributed development teams, centralizing SBOM consumption and vulnerability management is crucial. This enables security teams to identify common vulnerable components across the enterprise and plan remediation efforts strategically, maximizing overall risk reduction with the least amount of developer refactoring.
5. Enforce SBOM Standards on External Suppliers: Defenders must actively demand and validate SBOMs from their third-party suppliers. This includes checking for structural integrity (e.g., adherence to CycloneDX or SPDX, NIA minimum elements, complete relationships) and content quality (e.g., accurate component identification, VEX assertions, compliance with internal open-source policies). Establish a two-way communication channel to address identified issues and ensure continuous updates for new vulnerabilities.
6. Leverage Unique Identifiers for Data Enrichment: Emphasize the use of Package URL (PURL) as the primary unique identifier. PURLs enable defenders to enrich supplier SBOMs with missing information (e.g., manufacturer details for FDA submissions) and accurately map vulnerabilities and licenses, reducing the burden on suppliers and increasing the utility of ingested data.
7. Secure SBOM Transmission and Monitoring: Never transmit SBOMs via insecure channels like email. Utilize secure portals, time-based access controls, and robust Role-Based Access Control (RBAC) to manage SBOM distribution. Implement continuous monitoring of all SBOMs (internal and external) for new vulnerabilities that emerge post-release, requiring dynamic updates from suppliers.
8. Challenge Misconceptions and Advocate for Transparency: Defenders should actively debunk the myths surrounding SBOM sharing, specifically the fears of IP disclosure and providing a "blueprint" for threat actors. By fostering a culture of transparency, the entire industry's security posture can improve.
9. Consider Multi-Stage SBOM Generation (Advanced): Ideally, organizations should generate SBOMs at every stage of the SDLC (source, build, deploy, runtime) and perform diffs to identify where packages are introduced. While challenging, this provides unparalleled insight into dependency provenance and simplifies remediation.

By adopting these defensive strategies, organizations can move beyond reactive vulnerability patching to a proactive, transparent, and continuously monitored software supply chain security posture.

Key Takeaways

• SBOMs are a Practical Necessity: Driven by regulatory mandates (e.g., CRA, PCI 4.0 DSS, FDA, UNR 155) and the lessons from supply chain attacks like SolarWinds, SBOMs have transitioned from theoretical concepts to essential tools for managing software risk and achieving transparency.
• Three Core Scenarios for SBOM Maturity: Effective SBOM implementation progresses through generation and distribution, internal consumption for centralized vulnerability management, and external consumption for supplier enforcement. Each scenario builds upon the last, addressing increasing complexity.
• Prioritize Unique Identifiers (PURL): Package URL (PURL) is superior to CPE for uniquely identifying software components, enabling more accurate vulnerability and license lookups. Organizations should standardize on PURL and ensure its inclusion in generated SBOMs.
• Dynamic Vulnerability Prioritization is Key: Move beyond static CVSS scores. Leverage VEX statements and metrics like EPSS to assess actual exploitability in context. Implement SSVC-style decision trees to group fixes and prioritize remediation efforts for maximum impact with minimal refactor.
• Challenge Misconceptions and Embrace Transparency: The fears of intellectual property disclosure or providing a "blueprint" to threat actors via SBOMs are largely unfounded. Greater transparency across the software supply chain is crucial for collective security improvement.
• Automate and Continuously Monitor: Manual SBOM validation and vulnerability assessment are unsustainable. Organizations need robust tooling to automate SBOM generation, structural and content validation, data enrichment, and continuous monitoring for new vulnerabilities, ensuring a dynamic and effective security program.

About the Speaker(s)

Cortez Fraser Jr. is a Principal Product Manager at FASA, a company specializing in comprehensive SBOM lifecycle management, including Software Composition Analysis (SCA) and binary composition analysis. With approximately three years dedicated to his "SBOM journey," Fraser is a passionate advocate for the practical application of SBOMs in the real world.

Prior to his role at FASA, he served as a Cyber Security Architect for GE Power (now Verge Gnova), where he gained significant experience managing security for a vast software ecosystem, overseeing 1,800 developers and 600 applications with a notably small team of only three security professionals. This background has provided him with a deep understanding of the challenges faced by large organizations in implementing effective security measures. Known for his "strong opinions," Fraser brings a confident and analytical perspective to the complex domain of software supply chain security.