From JSON to Clarity: Practical Tools for SBOM Interpretation

From JSON to Clarity: Practical Tools for SBOM Interpretation

Speakers: John Bergland (IBM), Zadia Alden (Supply Chain Manager, IBM)

Conference: VulnCon

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

Overview

In the realm of software supply chain security, Software Bill of Materials (SBOMs) have emerged as a critical artifact, mandated by executive orders and regulations like the Cyber Resilience Act (CRA). However, as John Bergland and Zadia Alden of IBM highlighted in their VulnCon talk, "From JSON to Clarity: Practical Tools for SBOM Interpretation," these technically accurate documents are often operationally underleveraged. The core challenge lies in their raw, flat JSON format, which is dense, varies widely in quality and structure, and is largely inaccessible to non-technical stakeholders who need to understand associated risks. This presentation tackled the pervasive issue of SBOM clarity, demonstrating how simple, AI-powered tools can transform complex data into actionable insights.

The speakers, both seasoned IBM professionals deeply embedded in supply chain security, revealed their practical approach to demystifying SBOMs. Recognizing that the "wild west" of incoming SBOMs often lacks crucial details like dependency relationships or mapped release dates, they focused on building user-friendly front-end web applications. These tools, developed with the assistance of Large Language Models (LLMs), aim to expose and structure the existing data within an SBOM, making it consumable for roles ranging from legal and procurement to development teams. The talk underscored that while AI simplifies tool creation, the true value lies in discerning what information truly matters for business risk and governance.

The presentation introduced five distinct, open-source tools designed to interpret SBOMs, covering critical aspects such as quality assessment, component relationship analysis, CVE age tracking, license compliance, and version drift. By making these tools accessible and easy to share, IBM aims to empower organizations to move beyond mere compliance checkboxing. The overarching message is clear: SBOMs are not just security artifacts but rich sources of information about legal, commercial, and operational risk, provided that organizations have the means to effectively interpret and act upon their contents.

Background

▶ Watch: Introduction: SBOMs are underleveraged and hard to interpret (0:00)

The increasing reliance on open-source software and complex supply chains has made Software Bill of Materials (SBOMs) indispensable for understanding the components within a product. Driven by regulatory mandates, organizations are now frequently receiving or generating SBOMs. However, the practical reality, as articulated by the speakers, is that many recipients find themselves asking, "Great, now what to do?" This sentiment highlights a significant gap: while SBOMs are technically sound data structures, their operational usability remains severely limited.

The fundamental problem stems from the nature of raw SBOM data. Typically delivered as flat JSON files, they are "ugly to interpret" and "technically dense." This inherent complexity is compounded by several issues observed in real-world SBOMs: they "vary widely in structure and quality," often "relationships and dependencies are often absent," and even basic NTIA minimum elements are frequently missing. Furthermore, critical information like mapped release dates for component versions is rarely included, making it impossible to ascertain the age of software in use. This lack of standardized, easily consumable information renders SBOMs underleveraged, transforming a compliance requirement into a significant operational hurdle.

John and Zadia explained that their daily work involves navigating this "wild west" of SBOM quality, particularly when dealing with incoming SBOMs from diverse suppliers. They acknowledged that while advanced SBOM generation and analysis tools exist, the majority of suppliers provide SBOMs at the "absolute opposite end of the spectrum" in terms of maturity and completeness. This disparity led them to focus on simplicity. They leveraged Artificial Intelligence (AI), specifically Large Language Models (LLMs), not to generate more intelligence, but to build simple, targeted web applications. They noted that while an LLM can easily summarize an SBOM, the real challenge is deciding "what actually matters from a business, a risk, and a governance perspective." Tools like IBM's internal "Bob" (leveraging IBM, Anthropic, and Claude models) and public models like Claude proved "incredibly easy and really fun" for non-coders like themselves to develop these front-end tools. The key insight was that the value isn't in generating more data, but in "exposing what's already in the SBOM" once it's structured and normalized, making it clear and actionable for non-technical roles such as legal and procurement.

Key Findings

▶ Watch: Tool 1: SBOM Quality Insights – ensuring data credibility (6:05)

The central finding of this presentation is that the operationalization of SBOMs hinges on effective interpretation, and this can be achieved through simple, targeted tools built with AI. The speakers demonstrated that while the raw JSON format of SBOMs presents significant challenges in terms of density, inconsistency, and missing crucial data, these hurdles can be overcome by focusing on clarity and accessibility for a broad audience, including non-technical stakeholders.

Their core contribution is the development and open-sourcing of five practical tools, each designed to address a specific aspect of SBOM analysis:

1. SBOM Quality Component Relationship Analyzer: This tool establishes a baseline of credibility for an incoming SBOM by assessing its structural integrity, completeness of metadata, and the strength of component identification (e.g., PURLs, CPEs). It highlights missing NTIA elements and structural issues that could impact downstream tooling.
2. SBOM Dependency Analyzer: Directly addressing the common developer question ("We don't even use that library!"), this tool visualizes the often-hidden transitive dependencies. It clearly distinguishes between direct and transitive components, making the chain of dependency visible and clarifying how vulnerabilities or license issues might quietly enter a build.
3. CVE Age Tracker: This tool provides a quick, focused view on the longevity of known vulnerabilities within a codebase. By calculating the age of CVEs from their public disclosure date, it serves as a signal for prioritization, process health, and potential stalled remediation efforts, without aiming to replace comprehensive risk scoring like CVSS.
4. License Analysis: Beyond security, SBOMs carry critical legal and commercial implications. This tool categorizes licenses into risk profiles (high-risk copyleft, permissive, non-commercial, unknown), enabling organizations to quickly determine the legality of using, selling, or distributing specific packages as part of their products.
5. Version Drift Analysis: Addressing the security exposure of outdated software, this tool identifies the age of libraries in use by comparing their release dates to the latest available versions. It flags "dormant" (unmaintained) and "end-of-life" components, highlighting compliance and audit risks associated with unsupported software.

A critical overarching finding was the power of AI to lower the bar for tool development. The speakers, identifying as business-focused rather than expert coders, found LLMs incredibly effective for rapidly prototyping and building functional, simple web apps. This democratization of tool creation means that organizations don't need extensive development teams to start extracting value from their SBOMs. The emphasis was consistently on simplicity, modularity, and shareability (as HTML front-end apps), ensuring the tools are easy to use, understand, and distribute across diverse teams. The value, they concluded, is not in generating more "intelligence," but in effectively "exposing what's already in the SBOM" in a clear, actionable format.

Technical Deep Dive

▶ Watch: Tool 4: License Analysis for legal and commercial risk (22:00)

The core of the presentation revolved around a live demonstration of five distinct, simple, AI-built tools designed to bring clarity to complex SBOM data. Each tool operates as a self-contained, front-end HTML web application, emphasizing ease of use and shareability. IBM primarily focuses on the CycloneDX standard for its internal vulnerability management needs, although some tools support SPDX as well.

1. SBOM Quality Component Relationship Analyzer

This initial tool serves as a gatekeeper, assessing the foundational credibility of an SBOM. Users simply drag and drop their CycloneDX or SPDX file. The tool immediately surfaces key metadata, including format, version, timestamps, and identifiers. It provides component statistics, showing both the total count and deduplicated components, which is crucial for understanding the true scope. A key feature is its ability to highlight component identifier issues. For instance, it flags PURLs (Package URLs) with generic or GitHub ecosystems if they lack corresponding CPEs (Common Platform Enumerations), as this significantly impacts the ability to map to CVEs (Common Vulnerabilities and Exposures).

The tool features multiple tabs for detailed analysis:

• Components tab: Offers a visual summary of the SBOM's contents, including the number of components, suppliers, and licenses, immediately answering "what am I looking at?" without needing to open the raw JSON.
• Analysis tab: Focuses on quality signals. It flags missing NTIA minimum elements, such as supplier information and dependency relationships, which are treated as "supplier governance signals" indicating immaturity in the supplier's SBOM generation process. It also checks for structural issues like duplicate bomb refs or missing dependency information that could cause downstream scanners to fail. Furthermore, it assesses identification strength of PURLs, quantifying how many components might be difficult to map to CVEs due to generic or GitHub-only identifiers. All displayed data can be easily exported to CSV or Excel for further offline analysis or sharing with non-SBOM experts.

2. SBOM Dependency Analyzer

This tool directly addresses the often-hidden risks associated with transitive dependencies. Upon loading an SBOM, it immediately categorizes components into direct and transitive dependencies, providing a clear visual answer to the question of how a vulnerability might be present even if a library isn't directly used. This is particularly vital as many vulnerabilities, outdated code, or license issues "quietly enter a build" through these indirect relationships.

The tool's interface allows users to drill down into individual components. For example, clicking on a component like "chalk" reveals its attributes and, crucially, which specific transitive dependencies it introduces (e.g., "toast string tag"). It also provides a risk assessment for each dependency, noting whether it's a direct top-level (e.g., "low risk") or a deeper transitive one (e.g., "medium risk"). Importantly, it highlights NTIA compliance attributes for each component, revealing issues like an "unknown license" for a transitive dependency, which could be a significant legal concern. This visibility is "extremely helpful for developers" in understanding the full dependency graph and the implications of each component.

3. CVE Age Tracker

Designed for simplicity, this tool focuses on the longevity of known vulnerabilities. Unlike the other tools, it doesn't require an SBOM; users simply copy and paste a list of CVE IDs. The tool then calculates how long each CVE has been publicly known from its public disclosure date. The dashboard displays the total deduplicated CVEs and highlights those older than a configurable threshold (e.g., six months).

While the age itself is not a risk score, it serves as a powerful "supporting signal" for prioritization and understanding "process health." Older vulnerabilities often indicate stalled remediation, unclear ownership, or deferred fixes, and are "more likely to have reliable exploit code." The tool visually clusters CVEs by age and pulls in detailed information (severity, explicit details) directly from NVD (National Vulnerability Database) and CVE.org, eliminating the need for manual lookups.

4. License Analysis (Zadia's Tool)

Recognizing that an SBOM is a legal and commercial artifact as much as a security one, this tool helps assess the legality and commercial viability of using software packages. It features a dark-themed visual dashboard (a contrast to John's white UI) that categorizes licenses from the SBOM into easily understandable risk profiles:

• High-risk: Strong copyleft licenses like GPL and LGPL.
• Caution: Weak copyleft licenses.
• Permissive: Benign licenses like Apache.
• Non-commercial: Licenses restricting commercial use (e.g., EP+ Polyifor for non-commercial use).
• Third-party
• Proprietary
• Unknown: A critical category, as distributing products with unknown licenses poses significant legal risk.

The tool allows users to drill down into each category. For "unknown" licenses, it provides information on why the license couldn't be determined (e.g., not populated, non-standard SPDX ID) and offers "hints and tips" for retrieval. A "retrieve all" option attempts to automatically populate missing license information where possible.

5. Version Drift Analysis (Zadia's Tool)

The final tool tackles the security and compliance risks associated with outdated and unsupported software libraries. It analyzes the age of components by comparing the release date of the version specified in the SBOM with the latest available version's release date.

The dashboard visually categorizes components into:

• Fresh: Less than one year old.
• Aging: One to two years old.
• Critical: Over three years old.
• Dormant: Latest release is over three years old, indicating the project is not actively maintained.
• End-of-life: Libraries that are archived on GitHub, signifying no further support or security patches.

The tool uses the PURL from the SBOM to query sources like GitHub to fetch the latest release dates and determine the archived status. It displays the release date of the version in use, its age, and the latest release date, highlighting any age gap. This provides crucial visibility into "hidden transitive risk" where aging libraries often enter products indirectly, creating significant security exposures and compliance audit flags.

Demo / Proof of Concept

▶ Watch: Tool 5: Version Drift Analysis – identifying aging and EOL libraries (24:30)

The entire presentation served as a comprehensive demonstration and proof of concept for the five AI-powered SBOM interpretation tools developed by John Bergland and Zadia Alden. Each tool was showcased live, emphasizing its simple front-end UI interface and the immediate, actionable insights it provides. The speakers highlighted that these are not complex backend systems but rather HTML web apps with all the code embedded, making them incredibly easy to share and use—a key aspect of their design philosophy.

The demonstration began with the SBOM Quality Component Relationship Analyzer, where an SBOM file (either CycloneDX or SPDX) was dragged and dropped. The interface instantly displayed key metadata, component statistics, and critical flags for missing NTIA elements or problematic PURLs, demonstrating how quickly one can establish the credibility of an SBOM. This was followed by the SBOM Dependency Analyzer, which visually distinguished direct from transitive dependencies, allowing for a drill-down into components like "chalk" to expose how hidden dependencies (e.g., "toast string tag") might introduce risks like an "unknown license."

Next, the CVE Age Tracker was demonstrated by simply pasting a list of CVE IDs. The tool swiftly calculated and displayed the age of these vulnerabilities, highlighting those older than six months and providing a visual clustering, reinforcing that age is a valuable signal for prioritization. Zadia then took over to showcase her tools, starting with the License Analysis tool. With a drag-and-drop of an SBOM, a visually distinct dark-themed dashboard immediately categorized licenses by risk (high-risk, permissive, unknown), demonstrating the rapid identification of legal and commercial exposures. The demo included drilling into "unknown" licenses and the "retrieve all" feature.

Finally, the Version Drift Analysis tool was presented. After loading an SBOM, the tool fetched and displayed the age of libraries, categorizing them into "fresh," "aging," "critical," "dormant," and "end-of-life." The demonstration clearly illustrated how the tool identifies libraries archived on GitHub, providing concrete evidence of unsupported software. Across all five tools, the demo underscored the ease of use, the immediate visual feedback, and the ability to transform raw, intimidating JSON into clear, digestible, and actionable information for a diverse set of users.

Defensive Implications

▶ Watch: Q&A: Addressing SBOM accuracy and industry collaboration (40:30)

The tools and insights presented by John Bergland and Zadia Alden offer a robust framework for improving an organization's defensive posture against software supply chain risks. Their approach moves beyond mere compliance, empowering defenders to actively interpret and leverage SBOM data.

1. Elevate SBOM Quality and Trust:

• Don't blindly trust completeness: Defenders must use tools like the SBOM Quality Component Relationship Analyzer to scrutinize incoming SBOMs. Flagging missing NTIA elements (like supplier information and dependency relationships) is not just a formatting check; it's a supplier governance signal indicating immaturity in the supplier's SBOM generation process. This information should guide vendor conversations and inform procurement decisions.
• Demand better data: By identifying structural issues (e.g., duplicate bomb refs) or weak identification strength (e.g., generic PURLs without CPEs), organizations can push suppliers to provide higher-quality, more actionable SBOMs, which in turn improves the reliability of all downstream security tooling.

2. Uncover Hidden Dependencies and Risks:

• Visualize the full dependency graph: The SBOM Dependency Analyzer is crucial for understanding how vulnerabilities or problematic licenses can enter a product indirectly through transitive dependencies. Development teams can use this to accurately assess the reachability of vulnerabilities and make informed decisions about library usage.
• Proactive risk assessment: By identifying unknown licenses or high-risk transitive components, organizations can proactively address legal or security risks before they become critical issues in production.

3. Prioritize Remediation and Improve Process Health:

• Contextualize CVEs with age: The CVE Age Tracker provides a valuable signal for prioritizing vulnerability remediation. While not a replacement for CVSS or exploit data, identifying CVEs that have been publicly known for an extended period (e.g., over six months) suggests stalled remediation, unclear ownership, or deferred fixes. This insight helps security teams focus on long-standing exposures that are more likely to have reliable exploit code.
• Gauge development team effectiveness: An abundance of older, unaddressed CVEs can indicate areas where internal development processes need improvement, prompting discussions about resource allocation and patch management strategies.

4. Mitigate Legal, Commercial, and Technical Debt:

• Proactive license compliance: The License Analysis tool enables legal and compliance teams to quickly identify high-risk, non-commercial, or unknown licenses. This allows for early intervention, ensuring that products can be legally distributed and sold, avoiding costly legal disputes.
• Address version drift and end-of-life software: The Version Drift Analysis tool highlights aging, dormant, or end-of-life libraries. This is critical for managing technical debt, reducing the attack surface from unpatched vulnerabilities, and ensuring compliance with internal and external audit requirements. Organizations can then plan for timely upgrades or replacements of unsupported components.

5. Foster Continuous Monitoring and Internal Tooling:

• Feed into continuous monitoring: As IBM does, the structured and interpreted SBOM data can be fed into continuous monitoring tools. This enables organizations to be immediately alerted to new security issues impacting components in their products or those from their vendors, facilitating rapid response.
• Empower internal development: The ease of building these AI-powered tools (even for non-programmers) encourages organizations to develop their own targeted solutions. This fosters a culture of innovation and allows for highly customized tools that address specific organizational needs and workflows, moving SBOM interpretation from a niche skill to a widely accessible capability.

By adopting these defensive strategies, organizations can transform SBOMs from a burdensome compliance artifact into a powerful, actionable source of intelligence for enhancing software supply chain security, governance, and operational efficiency.

Key Takeaways

• SBOMs are underleveraged and require interpretation: Despite being technically accurate, raw SBOM data (flat JSON) is often too complex and inconsistent for operational use, leading to a "checkbox compliance" mentality rather than actionable security.
• AI simplifies tool development for clarity: Large Language Models (LLMs) make it "incredibly easy" for non-technical users to build simple, targeted front-end web applications that transform dense SBOM data into clear, consumable insights.
• Value lies in exposing and structuring existing data: The goal is not to generate more intelligence, but to surface and normalize the information already present in an SBOM, making it trustworthy and actionable for various stakeholders.
• Five practical, open-source tools address critical challenges: IBM demonstrated tools for assessing SBOM quality, analyzing direct and transitive dependencies, tracking CVE age, evaluating license risks, and identifying version drift and end-of-life components.
• Simplicity and shareability are paramount: Designing tools as modular, self-contained HTML web apps ensures they are easy to use, share across teams, and quickly provide immediate visual feedback.
• Actionable insights drive better decisions: These tools enable organizations to guide vendor questions, improve supplier governance, prioritize vulnerability remediation, manage legal risks, and proactively address technical debt, moving beyond passive compliance to active risk management.

About the Speaker(s)

John Bergland is a seasoned professional at IBM, bringing 28 years of experience to his role. Based in Boston, he is deeply involved in supply chain security, specifically dealing with a high volume of incoming SBOMs from IBM's suppliers and vendors. His work focuses on understanding and qualifying these external SBOMs in a "real world" context, which he describes as the "wild west" due to their varying quality and structure. John, while not a coder or developer, possesses a strong understanding of the business issues surrounding SBOMs and leverages AI to build simple, effective tools for interpretation.

Zadia Alden serves as a Supply Chain Manager within IBM's supply chain security division, with a primary focus on ensuring the safe use of open-source software across the company. With over 30 years at IBM, Zadia is based in the UK at the Winchester office. Like John, she deals with SBOMs daily and emphasizes their importance beyond just security, recognizing their value for legal and commercial risk assessment. Zadia also highlights her experience as an operations-side professional, not a programmer, who found building AI-powered web apps for SBOM analysis to be "really, really simple" and "fun."