Unlocking the Power of SBOMs: A Deep Dive into Risk Management and Cybersecurity Posture

Unlocking the Power of SBOMs: A Deep Dive into Risk Management and Cybersecurity Posture

Speakers: John Bergland, Program Manager, Supply Chain Security Office, IBM; Zardia Alden, CISO Office, IBM UK

Conference: VulnCon

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

Overview

This talk, "Unlocking the Power of SBOMs: A Deep Dive into Risk Management and Cybersecurity Posture," delivered by John Bergland and Zardia Alden from IBM, addresses the critical challenge of operationalizing Software Bill of Materials (SBOM) data to effectively manage cybersecurity risk. Moving beyond the mere generation of SBOMs—often referred to as an "SBOM in a bucket" by the speakers—the presentation outlines a comprehensive strategy for extracting actionable intelligence from these crucial documents. It delves into how IBM, both as a consumer and a producer of software, leverages SBOM analysis to understand and improve the security posture of its offerings and its supply chain.

The session emphasizes that while regulatory mandates are driving the adoption of SBOMs, their true value lies in their analytical application for identifying vulnerabilities, assessing software practices, and prioritizing remediation efforts. John Bergland, a program manager in IBM's supply Chain Security Office, and Zardia Alden from IBM's CISO office, articulate the complexities of navigating the evolving SBOM landscape, including the maturity of standards and tooling, and the constant need to adapt security strategies. Their insights are particularly relevant for organizations grappling with the practical implementation of SBOMs in a dynamic and threat-laden environment, highlighting the tangible benefits of a proactive, data-driven approach to software supply chain security.

The talk underscores the necessity of moving from passive SBOM collection to active risk management, providing a detailed look at IBM's methodologies, automation strategies, and the challenges encountered in fostering effective communication and remediation across a vast vendor ecosystem. It serves as a valuable guide for any organization seeking to harness the full potential of SBOMs to enhance their overall cybersecurity posture and mitigate supply chain risks.

Background

▶ Watch: Operationalizing SBOMs: Beyond just having them (0:30)

The increasing complexity of modern software, coupled with a surge in supply chain attacks, has made transparency into software components an imperative. This landscape is heavily influenced by a growing wave of regulatory mandates and security directives worldwide. Key among these drivers is the Biden executive order issued in May 2021, which significantly propelled the adoption of SBOMs in the United States. In Europe, directives like the NIS directive and the upcoming Cyber Resilience Act (CRA), set to come into full force in 2027, further reinforce the global push for greater transparency in software supply chains.

Despite these regulatory tailwinds, the speakers highlight that the SBOM standards themselves are still maturing and evolving, as is the tooling required to effectively generate, consume, and operationalize them. This creates a "pretty tricky" navigation environment for corporations, balancing increasing compliance requirements with the need to constantly revisit and refine security strategies.

IBM's approach to SBOM analysis is multifaceted, addressing use cases as both a consumer and a provider of software. As a consumer, IBM scrutinizes SBOMs from original equipment manufacturers (OEMs), vendors, and software suppliers to ascertain their security posture. This extends to due diligence during mergers and acquisitions (M&A), involving code scans and reviewing SBOM outputs from target companies. As a software provider, IBM utilizes SBOM analysis internally to identify components, plan remediation, and gain insights into aging libraries within its own offerings. The sheer scale of this effort is evident in the reported trend: IBM's program office analyzed over 500 unique SBOMs in 2022, a number that has seen significant, exponential growth since. This background sets the stage for the critical need for scalable, automated solutions to manage the deluge of SBOM data and translate it into actionable risk intelligence.

Key Findings

▶ Watch: Regulatory mandates driving SBOM adoption worldwide (3:45)

The talk reveals several critical findings that underscore both the challenges and opportunities in operationalizing SBOMs. A standout statistic from IBM's internal analysis indicates that a staggering 80% of identified vulnerabilities could be immediately addressed if all open-source libraries were simply updated to their latest versions. This highlights a fundamental gap in many organizations' vulnerability management practices and points to a significant area for improvement. The speakers emphasize that updating libraries not only incorporates the latest security patches but also ensures that scanning tools can accurately detect newer vulnerabilities.

Beyond just identifying vulnerabilities, IBM places strong emphasis on analyzing the percentages of packages at the latest release level, those that are back-level, and those for which a version cannot be determined. A high percentage of back-level components, especially if significantly outdated, signals potential issues with patching, maintenance, or even the presence of deprecated or out-of-support libraries. Missing unique identifiers like PURLs or CPEs in an SBOM can severely impede accurate analysis, requiring closer manual examination.

A significant portion of the talk is dedicated to the concept of "SBOM noise," which refers to components that appear in an SBOM but are not part of the production code, thus creating distractions for development teams. IBM's analysis reveals substantial prevalence of this noise:

• Non-production code: Found in 22% of analyzed SBOMs, this includes findings from package manager files like requirements.txt or pom.xml, and go.sum files, where dependencies are not actually used in production. The speakers provide a compelling example of an M&A scenario where a go.sum file was used for dev dependencies in one asset but production dependencies in another, preventing blanket exclusions.
• Scanning and configuration issues: Present in 27% of SBOMs, these arise when vendors inadvertently scan test or development code, or misconfigure their scanning tools. Discrepancies between different scanners also contribute to this noise, as no single tool provides a complete picture, potentially leaving blind spots. An example cited involved a critical vulnerability found in a cargo.lock file by IBM's independent scan, which the vendor's tooling, only supporting cargo.toml at the time, had missed.
• Poor housekeeping: This refers to dormant or redundant end-of-life code that remains bundled in offerings, leading to a large number of irrelevant vulnerability findings. A specific example highlighted an end-of-life product bundled with an offering that had not been cleaned up, despite developers being aware of its status.
• Vulnerability data issues: Accounting for 40% of SBOMs analyzed in the last 6-9 months, this category includes CVEs reported for unaffected versions of components, or CVEs that are still in an "analysis," "awaiting analysis," or "reanalysis" state in the National Vulnerability Database (NVD). This discrepancy between IBM's analysis platforms and vendor scanning tools (which may rely solely on NVD updates) creates confusion and necessitates deeper engagement.

These findings collectively emphasize that while SBOMs are foundational, their utility is heavily dependent on their quality, the sophistication of their analysis, and the ability to filter out noise to focus on genuine risks.

Technical Deep Dive

▶ Watch: IBM's practical use cases for SBOM analysis (4:40)

IBM's approach to operationalizing SBOMs is built on a robust, automated architecture designed to process a high volume of incoming data and extract meaningful security insights. The core of this process involves several key technical components and analytical criteria.

The initial step involves ingesting SBOMs from various sources, including third-party suppliers, vendors, OEMs, and intellectual property partners, as well as internal SBOMs generated from M&A code scans. These SBOMs are fed into a centralized platform that leverages a suite of industry-standard and commercial tooling for analysis. Specific tools mentioned for vulnerability scanning include Dependency-Track, Mend, Prisma Cloud, and Twistlock. The speakers also highlight their significant contributions back to the OWASP Foundation, particularly to Dependency-Track, with at least 15 contributions in the last 6-8 months, demonstrating their commitment to open-source community improvement.

The analysis process goes beyond simple vulnerability detection, incorporating several dimensions of risk assessment:

• Severity: Critical and high-severity CVEs are prioritized for immediate remediation. A significant challenge noted is the increasing number of unassigned vulnerabilities in NVD due to backlog, which necessitates looking to multiple data sources for accurate scoring.
• Age of CVE: Older CVEs raise red flags, potentially indicating that a vendor is not actively fixing known issues or that legacy vulnerabilities are resurfacing. The presence of very old vulnerabilities prompts special attention.
• KEV Association: The Known Exploited Vulnerabilities (KEV) catalog is a critical indicator. Any CVE associated with KEV signifies a real-world exploited vulnerability, demanding expedited attention.
• Versioning: Beyond just detecting vulnerabilities, the analysis scrutinizes whether components are significantly back-level, which can imply deprecation or lack of support. This is crucial for understanding the overall maintenance hygiene of an offering.
• CWEs (Common Weakness Enumerations): While not explicitly detailed in the talk, the mention of CWEs as an aggregated data point suggests a broader analysis of common software weaknesses in addition to specific vulnerabilities.

All the collected data—including CVEs, their severity, back-level percentages, CWEs, and KEV associations—is then aggregated. This aggregated data is used to automatically generate a standardized, business-friendly report. This report is designed to be accessible to top executives while also containing sufficient technical detail for security teams.

A particularly innovative aspect of IBM's technical approach is the generation of a VEX (Vulnerability Exploitability eXchange) spreadsheet template. Recognizing that most vendors are not yet equipped to handle pure VEX output, IBM provides this template as an intermediary step. It lays out vulnerability information clearly and includes dropdown menus for vendors to select the status of vulnerabilities (e.g., "not affected," "fixed," "under investigation") in a VEX-standardized format. This allows IBM to process the returned information according to VEX standards, while making it visually intuitive for vendors who may be less familiar with native VEX documents. This strategy has resulted in "tremendous success with standardization" and a 95% reduction in the time required to assess SBOMs due to automation.

The talk also delves into the technical aspects of "SBOM noise" and how it impacts analysis:

• Non-production code issues: The presence of requirements.txt, pom.xml, and go.sum files containing development dependencies that are not part of the final product creates false positives. The challenge with go.sum is particularly complex as some teams use it for production dependencies, preventing blanket exclusions.
• Scanning and configuration issues: Vendors inadvertently pointing scanning tools at incorrect codebases (e.g., test or development code) or misconfiguring them leads to irrelevant findings. The example of a vendor's tool not supporting cargo.lock while IBM's independent scan found a critical vulnerability highlights the need for comprehensive scanning capabilities.
• Vulnerability data discrepancies: The NVD backlog results in CVEs being in various analysis states, leading to situations where IBM's analysis platform reports a CVE, but the vendor is unaware because their tool hasn't been updated with the latest NVD information. Furthermore, CVEs are often reported for versions that are actually unaffected, adding to the noise. This emphasizes the need for better contextual data around CVEs, potentially through automated scraping of additional information.

Overall, the technical deep dive showcases IBM's commitment to sophisticated, automated SBOM analysis, bridging current practical limitations with future-oriented standards like VEX, and continuously refining their processes to tackle the inherent complexities of software supply chain security.

Demo / Proof of Concept

▶ Watch: Key finding: 80% vulnerabilities addressed by updating libraries (7:50)

While the talk does not feature a live software demonstration or a traditional exploit Proof of Concept (PoC), it effectively "demonstrates" IBM's operational processes and the architectural components that enable their SBOM analysis at scale. The primary "proof of concept" presented is the successful implementation and impact of their automated SBOM analysis platform and the VEX spreadsheet template.

The speakers illustrate how incoming SBOMs from diverse sources are processed through a platform utilizing tools like Dependency-Track, Mend, Prisma Cloud, and Twistlock. The output is then aggregated into a standardized, business-friendly report. The innovative aspect, which serves as a key process demonstration, is the VEX spreadsheet template. This template is designed to bridge the gap between vendors' current capabilities and the desired VEX standard. By providing a visually intuitive spreadsheet with dropdown menus for vulnerability status, IBM effectively demonstrates how they enable vendors to provide VEX-compliant information in a format they are comfortable with. This pragmatic approach proves that even without full VEX adoption across the supply chain, standardized information exchange is achievable, leading to a 95% reduction in assessment time. This operational demonstration highlights how IBM has transformed a complex, manual process into an efficient, scalable, and standardized workflow for managing software supply chain risk.

Defensive Implications

▶ Watch: Prioritizing remediation based on SBOM pervasiveness (8:20)

The insights shared by John Bergland and Zardia Alden offer critical defensive implications for both software consumers and producers seeking to bolster their cybersecurity posture. The overarching message is that SBOMs are not merely compliance artifacts but powerful tools for proactive risk management, provided they are properly analyzed and acted upon.

For software consumers, the defensive strategy involves rigorous SBOM scrutiny. Organizations should:

• Prioritize critical and high-severity vulnerabilities identified in vendor SBOMs, demanding remediation before acceptance.
• Examine component versioning, flagging significantly back-level, deprecated, or out-of-support libraries. This indicates potential neglect and increased risk.
• Scrutinize for "SBOM noise," such as non-production code, scanning configuration errors, and inaccurate vulnerability data. This requires engaging vendors to improve their SBOM generation quality.
• Leverage multiple scanning tools to compensate for the limitations of any single scanner and identify blind spots.
• Adopt standardized communication mechanisms like the VEX spreadsheet template to streamline vulnerability exchange and track remediation efforts with vendors. This fosters a more efficient and accountable supply chain relationship.

For software producers (like IBM itself), the defensive implications center on improving the quality and accuracy of their own SBOMs and integrating security earlier in the development lifecycle:

• Practice diligent package manager cleanup by using commands like go tidy and npm prune to ensure that only dependencies actually used in production are included in the SBOM. This directly addresses the "non-production code" noise.
• Actively adopt and promote VEX to provide clear context on vulnerability exploitability, reducing false positives and accelerating remediation. Even partial adoption through templates can yield significant benefits.
• Implement continuous integration of security tools that provide policy alerts and violations at the source. Tools like Mend, Dependabot, and CyberBeats can flag aging libraries or components from "countries of concern" as code is committed, preventing these issues from making it into the final SBOM.
• Scrape additional CVE data from various sources to gain richer context (e.g., affected versions) and mitigate the impact of NVD backlogs or "analysis in progress" states.
• Conduct continuous reviews of SBOMs as part of a continuous release cycle. This ensures that SBOMs remain accurate and reflect the current state of the software, and that vendor SBOMs are re-evaluated as new software is consumed.

The 95% reduction in SBOM assessment time achieved through IBM's automation is a significant defensive win, allowing security teams to keep pace with the exponential growth of SBOMs and focus on actual risks rather than manual processing. Ultimately, the talk advocates for a proactive, automated, and collaborative approach to SBOM management, transforming it from a compliance burden into a strategic asset for enhancing product security and overall cyber hygiene across the software supply chain.

Key Takeaways

• Operationalize SBOMs, don't just collect them: An "SBOM in a bucket is completely useless." The true power of SBOMs lies in their active analysis for risk management, not merely for procurement or compliance.
• Automation is crucial for scale: IBM achieved a 95% reduction in SBOM assessment time through automation, demonstrating its necessity for handling the exponential growth in SBOM volume and maintaining efficiency.
• VEX adoption is key for efficient communication: While full VEX adoption is still maturing, using VEX spreadsheet templates or similar standardized approaches can significantly improve vulnerability information exchange and remediation tracking with vendors.
• Address "SBOM Noise" for accuracy: Non-production code (22%), scanning/config issues (27%), poor housekeeping, and inaccurate vulnerability data (40%) create significant noise, distracting from real risks. Proactive measures are needed to clean up SBOM content.
• Prioritize updating open-source libraries: IBM's internal analysis revealed that 80% of vulnerabilities could be addressed by simply updating open-source libraries to their latest versions, highlighting a critical and often overlooked defensive strategy.
• Integrate security left and continuously: Implement policy alerts at source (e.g., Mend, Dependabot) and conduct continuous SBOM reviews to detect and remediate issues like aging libraries or insecure components early in the development lifecycle.

About the Speaker(s)

John Bergland is a Program Manager within IBM's Supply Chain Security Office. With over 20 years of experience at IBM, John has spent the last three years deeply immersed in the world of SBOMs, handling their reception, production, and analysis on a daily basis. His expertise is rooted in the practical challenges of operationalizing SBOM data for comprehensive risk management.

Zardia Alden is based out of the UK and brings nearly 30 years of experience with IBM. For the past couple of years, she has been a key member of IBM's CISO office, focusing specifically on cybersecurity through SBOM analysis. Prior to this role, Zardia worked in the open-source program office, primarily addressing legal and license compliance, which provided a strong foundation for her current work in software supply chain security.