RSAC Tech Talk - SBOM by Allan Friedman

RSAC Tech Talk - SBOM by Allan Friedman

Speakers: Allan Friedman

Conference: RSAC 2024

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

Overview

Allan Friedman's talk at RSAC 2024 delivered a compelling and often humorous call to action for the widespread adoption of the Software Bill of Materials (SBOM). Friedman, representing CISA, framed the current state of software transparency as "bananas"—an unacceptable reality where organizations often have less insight into the components of their critical infrastructure software than they do into the ingredients of a snack cake. The core message is that SBOM is a fundamental concept, now mature enough for immediate implementation across all sectors, serving as a critical enabler for enhanced software supply chain security.

The talk underscored the urgency of addressing software supply chain vulnerabilities, emphasizing that SBOM is not a "silver bullet" but rather a necessary starting point for any meaningful security posture. Friedman highlighted that while SBOM won't solve every problem, it provides the essential visibility required to tackle issues ranging from open-source licensing compliance to rapid response during zero-day vulnerabilities. He passionately argued that any organization failing to leverage SBOM data for automated vulnerability identification is "bad at security" in today's threat landscape.

This presentation served as both an educational primer and a strategic imperative, urging attendees—whether they develop, procure, or operate software—to embrace SBOM. Friedman outlined the current ecosystem, including established data formats, government mandates, and ongoing harmonization efforts. He stressed that the technology and understanding are sufficiently advanced for immediate action, positioning SBOM as a transformative layer of data poised to reshape how we manage digital risk and trustworthiness.

Background

▶ Watch: Introduction to SBOM and its core takeaways (0:00)

The pervasive and intricate nature of modern software development has inadvertently created a profound security challenge: a severe lack of transparency into the constituent components of applications. As Allan Friedman aptly puts it, "it is bananas that we don't know what's in our software." This problem stems from the reality that software is rarely monolithic; instead, it is "assembled" from a myriad of internal and external components. Developers frequently incorporate open-source libraries, proprietary frameworks, and even direct copy-pasted code snippets from sources like Stack Overflow, creating a complex web of dependencies. This assembly process, while efficient for development, obscures the underlying ingredients of the final product.

This opacity creates significant risks across several vectors. Firstly, vulnerability management becomes a formidable task. With an estimated 30,000 new vulnerabilities discovered annually, organizations are constantly exposed to threats stemming from known flaws in their software's dependencies. Without a clear inventory of these components, responding to critical vulnerabilities like Log4j, XZ, or Libwebp becomes a reactive, manual, and often delayed scramble to identify affected systems. Friedman illustrated this with the alarming example of Ivanti products, where publicly discovered components were found to be 14, 15, and even 22 years old, indicating a severe lack of maintenance and inherent risk.

Beyond security, the lack of transparency also poses substantial compliance risks. Many open-source components come with specific licensing requirements (e.g., GPL). Without an accurate inventory, organizations struggle to ensure they are adhering to these licenses, potentially exposing them to legal repercussions, a risk Friedman noted Europeans are generally more adept at managing than Americans. Furthermore, the reliance on external components, particularly open-source ones, introduces a unique dynamic where maintainers often disclaim responsibility for downstream users, famously stating, "I am not your expletive, expletive supply chain." This highlights the need for organizations to proactively understand and manage their own dependencies.

The rise of supply chain attacks further underscores the urgency of SBOM. Friedman suggested that as software development practices improve, attackers are increasingly targeting the "soft underbelly" of the digital infrastructure: the supply chain itself. These attacks can have far-reaching consequences, extending beyond immediate network compromise to critical infrastructure disruption, espionage, and geopolitical instability. Frameworks from the intelligence community and Google acknowledge this shift, recognizing that compromising a widely used component can grant access to countless downstream targets.

In essence, the problem exists because while software "eats the world," the process of its creation and deployment has outpaced the mechanisms for understanding its composition. The Software Bill of Materials (SBOM) emerges as the foundational solution to this long-standing problem, providing the necessary visibility to enable a proactive and robust security posture. Friedman consistently reiterated that SBOM is "necessary, but not sufficient," serving as a starting point and enabler for a wide array of security and compliance activities.

Key Findings

▶ Watch: SBOM is not a silver bullet, but a necessary enabler (3:30)

Allan Friedman's talk presented several critical findings and insights regarding the state and future of SBOM:

1. Maturity and Immediate Actionability: A core finding is that SBOM is no longer an aspirational concept but a "core concept that is reasonably well understood today" and "pretty darn mature." This means organizations can and should "start today" in implementing SBOM practices. The technology, understanding, and tools are sufficiently advanced to begin generating, consuming, and utilizing SBOM data.

1. Foundational Transparency for Supply Chain Security: SBOM is unequivocally positioned as a fundamental enabler for software supply chain security. While not a "silver bullet," it provides the essential "list of ingredients" without which no meaningful security, compliance, or vulnerability management can occur. It addresses the "bananas" problem of not knowing what's in our software, transforming ignorance into actionable visibility.

1. Ubiquitous Applicability Across the Software Lifecycle: Friedman emphasized that SBOM is relevant and beneficial for all stakeholders in the software lifecycle:

• Makers: For secure development processes, identifying technical debt, and managing open-source licensing.
• Buyers: For informed procurement decisions, understanding the supply chain of purchased software.
• Operators (SOCs): For rapid and automated response to zero-day vulnerabilities (e.g., Log4j, XZ, Libwebp) by quickly determining "Am I affected?"

1. Automation as a Mandate: A significant finding is that any security process not inherently built for automation is inefficient and insufficient. SBOM data, being machine-readable, is designed to support automation, allowing for scalable vulnerability scanning, compliance checks, and operational responses. Organizations that cannot automate their vulnerability identification using SBOM data are explicitly deemed "bad at security."

1. Standardization and Interoperability are Advancing: Despite initial "chicken and egg" problems, the SBOM ecosystem is maturing. Two prominent open-source data formats, CycloneDX (from OWASP) and SPDX (from the Linux Foundation), are actively developed and widely adopted. Crucially, the US government, through CISA, DHS, and OpenSSF, is addressing interoperability by developing a translator tool, ensuring that organizations aren't forced to pick a single standard and can work with either format.

1. Government and Regulatory Drivers: A major accelerant for SBOM adoption is government mandate. The 2021 White House Executive Order on Improving the Nation’s Cybersecurity (EO 14028) established a requirement for SBOMs for all software purchased by the US government. Similarly, the FDA now mandates SBOMs for new medical devices. These requirements are driving adoption across critical sectors like financial services, healthcare, energy, and automotive, even among organizations that "will do it when someone makes us."

1. International Harmonization Efforts: CISA is actively leading an international S-BOM working group with allied cybersecurity agencies. The goal is to prevent fragmentation into disparate regional or sector-specific SBOM standards (e.g., European SBOM, Japanese SBOM, medical device SBOM) and instead work towards global harmonization, recognizing that "we all use the same software."

1. Future Directions and Emerging Challenges: While significant progress has been made, Friedman acknowledged ongoing challenges and future areas of work:

• Naming Problem: The difficulty in consistently identifying software components across different contexts remains a hard problem CISA is tackling.
• Hardware BOM (HBOM): Extending transparency to hardware components (e.g., DIMMs, LTE chips) is an emerging area.
• AI Bill of Materials (AI BOM): Applying SBOM principles to AI systems, recognizing that AI is "more than software."
• Cryptographic Bill of Materials (CBOM): Documenting cryptographic algorithms and key material, especially pertinent for the transition to post-quantum encryption.

Technical Deep Dive

▶ Watch: Understanding the scary reality of software supply chains (4:30)

At its core, an SBOM (Software Bill of Materials) is an inventory of the components that make up a piece of software. Allan Friedman graphically represented it as a hierarchical structure: "This is my software. This software uses this software. This software in turn uses this software. It's dependencies all the way down." This nested structure is fundamental, as many critical vulnerabilities (like Log4j) reside deep within transitive dependencies, not just top-level components.

For each identified component, an SBOM typically includes essential metadata to facilitate risk assessment and management. Key information points include:

• Supplier: Identifies the entity or project that created the component (e.g., open-source project, specific vendor).
• Component Name: The recognized name of the software part.
• Version: The specific iteration of the component, crucial for tracking vulnerabilities and updates.
• Identifiers: Unique identifiers that allow for consistent referencing across different databases and tools. Friedman acknowledged that "software identifiers" represent a "hard problem" but one that CISA is actively addressing.

Use Cases Across the Software Lifecycle:

SBOMs provide tangible benefits tailored to different roles:

• Software Makers: For developers and engineering teams, SBOMs are integral to a secure development process. They enable proactive identification of technical debt, such as components that are wildly out of date, no longer supported, or have reached end-of-life. This visibility allows for informed decisions regarding patching, upgrades, or replacement, mitigating future risks. Furthermore, SBOMs are crucial for ensuring open-source licensing compliance, helping organizations avoid legal issues related to GPL or other licenses.
• Software Buyers: Procurement teams can leverage SBOMs to make more informed decisions. By requiring an SBOM from suppliers, buyers gain transparency into the supply chain of the software they acquire, allowing them to assess the security posture and potential risks before integration into their networks.
• Software Operators (SOCs): For security operations centers and network defenders, SBOMs are transformative for vulnerability management and incident response. In the event of a new zero-day vulnerability (e.g., Log4j, XZ, Libwebp), an organization with robust SBOM implementation can use automated tools to quickly query their component inventory and determine, "Am I affected?" This capability drastically reduces response times and improves the accuracy of remediation efforts, moving beyond reactive guesswork. Friedman starkly stated that without this automated capability, an organization is "bad at security."

SBOM Generation Methodologies:

SBOMs can be generated at different stages of the software lifecycle:

• During Build/Development: This is often considered the most authoritative source. Integrating SBOM generation into DevOps pipelines and CI/CD (Continuous Integration/Continuous Delivery) processes allows for capturing dependencies as software is compiled and assembled. Friedman noted that compilers, in particular, can be a "source of truth" as they process all dependencies. This approach ensures an accurate and up-to-date inventory reflecting the actual build.
• Binary Analysis: For legacy systems, embedded devices, or situations where source code is unavailable, binary analysis tools can be employed. These tools reverse-engineer compiled binaries to identify their constituent components. Friedman mentioned that while there are many proprietary tools, there is "only really one open source one" (without naming it). This method is critical for understanding the contents of "blinking boxes" that might be running critical infrastructure in hospitals or industrial control systems.

Standard Data Formats and Interoperability:

To achieve machine readability and automation, SBOMs rely on standardized data formats:

• CycloneDX: Developed by OWASP, it's designed to be lightweight and comprehensive, often used in agile and cloud-native environments.
• SPDX (Software Package Data Exchange): From the Linux Foundation, SPDX is another widely adopted standard, providing a robust framework for documenting software components, licenses, and copyrights.

Friedman acknowledged that while both formats are excellent, actively developed, and have strong communities, they "kind of hate each other." However, the US government is not "picking a winner or a loser." Instead, CISA, in collaboration with DHS and OpenSSF, has developed a translator tool that allows conversion between CycloneDX and SPDX. This crucial development ensures interoperability and prevents format fragmentation from hindering adoption.

Depth of Information:

The utility of an SBOM is directly related to its depth. A "top-level S-BOM" might offer some insight, but for critical vulnerabilities like Log4j, which often appear as deep transitive dependencies, a comprehensive SBOM that captures "dependencies all the way down" is essential.

Minimum Elements for Compliance:

To standardize what constitutes an acceptable SBOM, the US government, following the 2021 White House Executive Order, defined minimum elements. These properties ensure that an SBOM provides sufficient information for government procurement and security assessments. Key elements include not just component details but also metadata about the SBOM itself, such as "who wrote the data" (e.g., supplier, tool, third party). CISA is actively updating these minimum elements, signaling ongoing refinement and adaptation to evolving needs.

In essence, the technical deep dive reveals SBOM as a structured, machine-readable inventory of software components and their dependencies, generated through various means, standardized by open formats, and crucial for automating security, compliance, and operational responses across the entire software lifecycle.

Demo / Proof of Concept

▶ Watch: Demystifying SBOM: understanding its simple structure (8:00)

The talk by Allan Friedman primarily focused on the conceptual framework, strategic importance, and implementation pathways of SBOM, rather than showcasing a live technical demonstration or proof of concept. While Friedman alluded to the existence of tools for processing SBOM data and performing scans to identify vulnerabilities, he did not provide a specific demonstration of these tools in action during the presentation. He emphasized that "we have the tools today to take S-BOM data, put it in a pile, and then do some quick and dirty scans," highlighting the current capability without detailing a specific example.

Defensive Implications

▶ Watch: Why SBOM is crucial for all software roles (9:00)

The widespread adoption and effective utilization of SBOMs present transformative defensive implications for organizations across all sectors. Allan Friedman's talk outlined a clear imperative for action, emphasizing that SBOM is a non-negotiable component of modern cybersecurity.

1. Proactive Vulnerability Management: The most immediate and impactful defensive implication is the ability to conduct proactive and rapid vulnerability identification. Instead of scrambling during a zero-day event like Log4j or XZ, organizations equipped with SBOMs can leverage automated tools to instantly query their software inventory and pinpoint exactly which applications and systems contain the vulnerable component. This drastically reduces the Mean Time To Respond (MTTR) to critical threats, moving from reactive chaos to targeted remediation. Defenders should integrate SBOM consumption into their Vulnerability Management Systems (VMS) and Security Information and Event Management (SIEM) platforms.

1. Enhanced Supply Chain Risk Assessment: For organizations that procure software, SBOMs enable a fundamental shift in vendor risk management. Defenders should mandate that all software suppliers provide SBOMs as part of their contractual obligations. This allows for a granular assessment of the security posture of third-party software before it's deployed, identifying outdated components, known vulnerabilities, or problematic licensing early in the procurement cycle. This proactive vetting can prevent insecure software from entering the environment in the first place.

1. Comprehensive Asset Inventory and Technical Debt Management: SBOMs provide an unparalleled level of detail for software asset inventory. Defenders can use this data to identify and track all components, including open-source libraries and their versions. This visibility is crucial for identifying and prioritizing technical debt—components that are end-of-life, unsupported, or excessively old (like the 14-22 year old components found in Ivanti products). Addressing technical debt reduces the attack surface and improves overall system hygiene.

1. Open Source Licensing Compliance: For legal and compliance teams, SBOMs are invaluable for managing open-source licensing risks. By documenting all open-source components and their associated licenses, organizations can ensure adherence to terms like GPL, mitigating potential legal challenges and financial penalties. This is particularly relevant in regions like Europe, where licensing enforcement is often more stringent.

1. Automation as a Core Strategy: Friedman stressed that "everything we do should focus on automation." Defenders must integrate SBOM generation and consumption into their automated security workflows. This means embedding SBOM creation within CI/CD pipelines for internally developed software and automating the ingestion and analysis of supplier-provided SBOMs. Tools that can parse CycloneDX and SPDX formats and cross-reference them with vulnerability databases (like NVD) are essential for scalable defense. The existence of the CISA/DHS/OpenSSF translator tool further simplifies this by bridging format differences.

1. Future-Proofing for Emerging Threats: The principles of SBOM extend to nascent areas like Hardware Bill of Materials (HBOM), AI Bill of Materials (AI BOM), and Cryptographic Bill of Materials (CBOM). Defenders should monitor these developments and prepare for their eventual integration into a holistic transparency strategy, especially with the advent of post-quantum cryptography, where understanding current cryptographic algorithms will be paramount.

1. Engagement with Standards and Government Initiatives: Organizations should actively engage with CISA's efforts, including monitoring updates to the minimum elements for SBOM and participating in the international SBOM working group. Aligning with these standards ensures that defensive strategies are consistent with evolving best practices and regulatory requirements.

In summary, SBOM is not merely a documentation exercise; it's a strategic defensive tool that empowers organizations with unprecedented visibility and automation capabilities, enabling more effective vulnerability management, supply chain risk mitigation, and overall security posture enhancement. The call to action is clear: "everyone can start today."

Key Takeaways

• SBOM is Mature and Actionable Today: The concept of a Software Bill of Materials is well-understood and sufficiently mature for immediate implementation. Organizations should not delay in adopting SBOM practices.
• Fundamental Enabler, Not a Silver Bullet: SBOM is a necessary starting point for software transparency, enabling crucial security, compliance, and operational functions, but it does not solve all problems on its own.
• Mandated by Government and Regulators: The US White House Executive Order 14028 and FDA requirements are driving widespread adoption of SBOMs, particularly in critical infrastructure and regulated sectors.
• Automation is Critical for Effectiveness: SBOM data, being machine-readable, is designed for automation. Organizations must integrate SBOM generation and consumption into automated security workflows for rapid vulnerability response and efficient risk management.
• Standard Formats and Interoperability: Established open-source formats like CycloneDX (OWASP) and SPDX (Linux Foundation) are widely used, and CISA's translator tool ensures interoperability between them, simplifying adoption.
• Knowing Your Software's Ingredients is an Imperative: It is no longer acceptable to be ignorant of what components make up your software. SBOM provides the essential visibility needed to manage supply chain risks, respond to zero-day vulnerabilities, and ensure compliance.

About the Speaker(s)

Allan Friedman is a prominent voice in the cybersecurity community, particularly recognized for his work on the Software Bill of Materials (SBOM). Representing CISA (Cybersecurity and Infrastructure Security Agency), Friedman serves as a senior advisor, driving initiatives related to software transparency and supply chain security. Throughout his talk, he demonstrated a deep understanding of the technical, policy, and market dynamics surrounding SBOM. While he humorously admitted to not being a coder himself, his passion for the subject and his ability to articulate complex concepts in an engaging and accessible manner were evident. He actively works to foster collaboration between government, industry, and open-source communities to advance SBOM adoption and standards harmonization globally. Friedman's role at CISA positions him at the forefront of shaping the future of software supply chain security, influencing policy and implementation efforts across the United States and internationally.