Contextual SBOMs: Unlocking Precise Vulnerability Management with Build-Time Content Intelligence

Contextual SBOMs: Unlocking Precise Vulnerability Management with Build-Time Content Intelligence

Speakers: Przemyslaw "Rogue" Roguski, Red Hat

Conference: VulnCon

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

Overview

In the rapidly evolving landscape of software supply chain security, Software Bill of Materials (SBOMs) have emerged as a foundational element for transparency and risk management. However, as Przemyslaw "Rogue" Roguski, a distinguished expert from Red Hat, elucidated at VulnCon 2026, the promise of traditional SBOMs often falls short in the face of modern, complex container builds. His talk, "Contextual SBOMs: Unlocking Precise Vulnerability Management with Build-Time Content Intelligence," addressed a critical gap: while standard SBOMs list components, they fail to provide the crucial provenance information necessary for efficient and actionable vulnerability remediation.

Roguski's presentation introduced the innovative concept of contextual SBOMs, an advanced form of SBOM that meticulously captures the origin of every artifact by analyzing the intricate steps of the build process. By mapping each component to its specific build action and the image that generated it, contextual SBOMs empower security and engineering teams to move beyond the "unknown origin loop" – where vulnerabilities are identified but ownership and remediation pathways remain obscure. This paradigm shift enables a more precise, automated, and cost-effective approach to vulnerability management, directly impacting security posture and operational efficiency.

The core problem, as Roguski articulated, is that vulnerability scanning is not the same as provenance analysis. Modern container images are complex assemblies, often built through multi-stage processes involving multiple base images, builder images, and application layers. Without knowing why a vulnerable component is present and who introduced it, remediation efforts become a chaotic, resource-intensive guessing game. Contextual SBOMs aim to resolve this by integrating build-time intelligence directly into the SBOM, thereby transforming a static inventory into a dynamic, actionable map of the software supply chain.

Background

▶ Watch: Introduction: The problem with modern container security (0:00)

The journey towards robust software supply chain security has seen significant progress, with SBOMs becoming a cornerstone. Driven by regulations like the EU Cyber Resilient Act and frameworks such as NIST SSDF, SBOMs are increasingly mandated across industries. The ecosystem boasts mature standards like SPDX and CycloneDX, alongside a plethora of tools for generation, analysis, and verification. These advancements offer a machine-readable inventory of software components, enabling rapid CVE identification and initial vulnerability prioritization.

However, Roguski highlighted a fundamental disconnect between what traditional SBOMs promise and what they deliver in real-world scenarios, particularly concerning containerized applications. Standard Software Composition Analysis (SCA) tools, when applied to a container image, can identify vulnerable components, their versions, matching CVEs, CVSS scores, and sometimes even patch availability. Yet, they consistently fail to answer critical questions for SecOps teams:

• Who is responsible for this artifact?
• Why is this artifact present in the image?
• Is it part of my application code, the base image, or a builder image?
• Do I need to act now, or wait for an upstream maintainer?
• Which CI/CD pipeline needs to be updated?

This lack of provenance information leads to the "unknown origin loop." For instance, if a container image built on a UBI 9 Python base includes a vulnerable HTTP package, a flat SBOM will confirm its presence. But without context, it's unclear whether the application owner, the base image maintainer, or a builder stage is responsible for the fix. This ambiguity translates into significant operational costs: teams spend valuable time identifying ownership, initiating unnecessary rebuilds, and struggling with remediation prioritization, ultimately impacting Service Level Agreements (SLAs).

The complexity stems from the modern container build reality. Production container images are rarely built from a single source. Instead, they are assembled through multi-stage builds, typically involving:

1. Builder stages: Used to compile source code or prepare assets (e.g., golang:latest to compile a Go application).
2. Base images: Providing the foundational operating system and core libraries (e.g., UBI Python).
3. Application layers: Where specific application code and dependencies are installed.

Content flows between these stages via instructions like COPY in a Dockerfile or is inherited directly from base images. A single container image can thus contain hundreds of packages maintained by diverse teams. Traditional SBOMs, which primarily use the default contains relationship, merely confirm the presence of an artifact without elucidating its origin or provenance. This data gap is precisely what contextual SBOMs aim to bridge, by shifting the focus from mere inventory to a precise, build-aware map of the software supply chain.

Key Findings

▶ Watch: Introducing Contextual SBOMs: Capturing artifact origin (11:00)

The central finding presented by Rogue is the critical need for and the architectural concept of contextual SBOMs. These are not merely enhanced SBOMs; they represent a fundamental shift in how software components are understood and managed within complex build environments. Contextual SBOMs move beyond a flat list of artifacts by capturing the origin of every single component, mapping it precisely to the build steps and the intermediate images created during those steps.

The core innovation lies in leveraging more granular relationships within the SPDX standard, specifically:

• contains: Still used to map specific artifacts to the image itself, as in traditional SBOMs.
• descendant of: Used to establish relationships between base images and the images built upon them. For example, an application image is a descendant of its UBI base image.
• built tool of: Employed to link artifacts from builder images to the final application image. This relationship clarifies when a component originated in a builder stage and was subsequently copied or integrated into the final product.

By meticulously monitoring every step of the build process, contextual SBOMs provide a clear, interconnected picture of the software supply chain. This structured approach immediately answers critical questions that traditional SBOMs leave unanswered:

• In which specific build step was this vulnerable artifact introduced?
• Is it an inherent part of the base image?
• Was it copied from a builder image?
• Was it compiled from sources during a builder stage, bringing its own dependencies?

This immediate clarity regarding artifact provenance allows teams to pinpoint ownership of remediation work from the outset. It dictates the correct rebuild sequence, ensuring that fixes are applied efficiently and only to affected components, thereby avoiding unnecessary rebuilds and accelerating patch delivery to end-users. The contextual SBOM transforms an isolated, static view of software components into a dynamic, precise map, which is essential for actionable vulnerability management in modern CI/CD pipelines.

Technical Deep Dive

▶ Watch: Advanced example: Tracking artifacts through multi-stage builds (16:00)

The technical implementation of contextual SBOMs hinges on a meticulous monitoring of the build process and the intelligent application of SPDX relationships. Rogue detailed how this works by tracing the lifecycle of artifacts through multi-stage container builds.

At its core, a contextual SBOM is generated by observing every instruction in a Dockerfile or similar build script. For each step, it identifies the artifacts introduced, modified, or copied, and establishes their relationship to the resulting image layer. This contrasts sharply with traditional SCA tools that merely analyze the final image or a basic SBOM generated post-build.

Consider a typical container build scenario:

In this example, a traditional SBOM of the final image would list hello (the compiled application), curl (copied from the builder), numpy (installed in the final stage), and all components inherited from ubi9/python-39. However, it would not tell you where curl came from or who owns hello's dependencies.

A contextual SBOM, by contrast, would capture the following:

1. Base Image Contextualization:

• The final application image is a descendant of ubi9/python-39.
• All packages contained within ubi9/python-39 (e.g., the vulnerable HTTP package discussed) are precisely identified as belonging to this base image. If HTTP is vulnerable, the contextual SBOM immediately points to the UBI maintainers as the responsible party. This allows for automated alerting to the base image owner and pre-configuration of the application's CI/CD pipeline to rebuild once a patched UBI image is available, without requiring manual intervention from the application team.

1. Multi-Stage Builder Contextualization:

• The final application image has a built tool of relationship with the golang:latest builder image.
• During the builder stage, the process observes:
• The initial golang:latest image, noting its internal components (e.g., specific Go standard library versions, and crucially, the curl binary pre-installed within it).
• The COPY . . and RUN go build -o hello . steps. These create an intermediate image layer containing the compiled hello application and any associated dependencies (e.g., mylibrary). This intermediate image is a descendant of the golang:latest builder.
• When COPY --from=builder /usr/bin/curl /usr/bin/curl is executed, the contextual SBOM registers that this specific curl binary originated from the golang:latest builder. Similarly, COPY --from=builder /app/hello . links the hello binary and its dependencies back to the intermediate builder layer where it was compiled.

This granular tracking allows for incredibly precise vulnerability management. If curl is found to be vulnerable, the contextual SBOM immediately reveals it was part of the golang:latest builder image. The remediation responsibility falls squarely on the owners of the Golang builder image. Furthermore, the contextual SBOM can inform whether applications using that builder need to be rebuilt. If curl was part of the builder but not copied to the final application layer, then the application doesn't need a rebuild, saving considerable time and resources. Conversely, if a vulnerability affects mylibrary, a dependency of the hello application, the contextual SBOM pinpoints that the issue lies within the application's source code, directing the application owners to fix their code, bypassing unnecessary alerts to base image or builder owners.

The most challenging aspect of this approach is matching packages across different SPDX documents or build stages. This requires highly consistent unique identifiers. Contextual SBOMs heavily rely on:

• Package URLs (PURLs): A standardized way to identify software packages.
• Checksums / Digest Hashes: For file integrity and identification.
• Package Verification Codes (PVCs): SPDX's unique identifier for content.

However, a significant challenge remains with custom binaries or files that lack these standard unique identifiers. In such cases, the system might have to rely on less precise methods like file names, leading to an "uncertain state" flag. Rogue issued a call to action to the broader SBOM tooling ecosystem to invest in improving this area, as consistent identifiers are paramount for 100% accuracy in contextual SBOMs.

Demo / Proof of Concept

▶ Watch: Impact summary: Precise remediation, automation, and challenges (22:00)

While a live, interactive demonstration of contextual SBOMs was not presented on slides during the talk, Przemyslaw Roguski affirmed that the underlying logic and implementation are part of the Hermeto public project. This project serves as a practical proof of concept, demonstrating how build monitoring can be integrated into CI/CD pipelines to generate and leverage contextual SBOMs.

Attendees interested in adopting this approach can either directly utilize the Hermeto project or adapt its core logic to their existing CI/CD environments. This involves incorporating build-time monitoring into every step of the build sequence to mimic the detailed artifact tracking and relationship mapping that contextual SBOMs require. Although a visual walkthrough was not part of the presentation, the existence of the Hermeto project underscores the technical feasibility and practical application of the contextual SBOM concept.

Defensive Implications

▶ Watch: Q&A: Handling complex multi-stage build relationships (30:00)

The adoption of contextual SBOMs presents profound defensive implications for organizations grappling with software supply chain security, particularly in containerized environments. By providing precise provenance information, these advanced SBOMs enable a strategic shift from reactive, broad-stroke remediation to targeted, efficient, and automated responses.

1. Precise Vulnerability Ownership and Remediation: Contextual SBOMs eliminate the "unknown origin loop" by clearly identifying who owns a vulnerable artifact. If a CVE impacts a package, the SBOM immediately indicates whether it's part of the base image (e.g., UBI 9 Python), a builder image (e.g., golang:latest), or a dependency of the application's custom code. This allows security teams to alert only the responsible team, preventing the wasteful "ping-pong" of responsibility and ensuring that remediation efforts are directed effectively.

1. Optimized and Targeted Rebuilds: Understanding the exact origin of a vulnerable component dictates the correct remediation sequence and scope. For instance, if a curl binary from a Golang builder image is vulnerable, but it was not copied into the final application image, the application does not need to be rebuilt. This prevents unnecessary rebuilds across hundreds or thousands of applications, saving significant computational resources, time, and developer effort. When a base image is patched, contextual SBOMs enable dependent application pipelines to automatically trigger rebuilds, ensuring the fix propagates efficiently.

1. Enhanced Automation in CI/CD Pipelines: The detailed, machine-readable provenance data within contextual SBOMs is ideal for integration into CI/CD workflows. Pipelines can be configured to automatically:

• Identify affected components and their owners.
• Trigger upstream fixes (e.g., by notifying a base image team).
• Initiate downstream rebuilds of dependent components only when necessary and in the correct sequence.
• Inform application owners of vulnerabilities without requiring immediate action from them, if the fix is upstream (e.g., "You are affected, but no action needed; a new base image will be available soon, and your pipeline is ready to rebuild"). This "no worries" communication improves developer experience and reduces alert fatigue.

1. Reduced Remediation Time and Improved SLAs: By streamlining the identification of ownership and the remediation process, contextual SBOMs directly contribute to faster vulnerability response times. This translates into better adherence to security SLAs, reduced exposure windows, and ultimately, a stronger security posture against emerging threats. The elimination of guesswork and manual investigations drastically cuts down the time from detection to resolution.

1. Comprehensive Layered Product Awareness: For organizations managing complex product portfolios with interdependencies (e.g., multiple container images relying on shared base images or builder images), contextual SBOMs provide a clear map of these relationships. This allows for a holistic understanding of how a vulnerability in one component can cascade across multiple products, enabling coordinated and efficient remediation strategies across the entire product ecosystem.

1. Cost Savings and Resource Optimization: The avoidance of unnecessary investigations, rebuilds, and cross-team communications directly reduces operational costs. Teams can focus their efforts on actual remediation tasks, rather than provenance discovery, leading to more efficient use of engineering and security resources.

In essence, contextual SBOMs empower defenders to transform vulnerability management from a chaotic, reactive process into a precise, proactive, and largely automated function, significantly bolstering software supply chain resilience.

Key Takeaways

• Flat SBOMs are Insufficient for Actionable Vulnerability Management: While necessary for compliance and initial inventory, traditional SBOMs lack the crucial provenance information required for precise and efficient vulnerability remediation in modern, multi-stage container builds.
• Contextual SBOMs Provide Missing Provenance: By meticulously monitoring build steps and leveraging advanced SPDX relationships (like descendant of and built tool of), contextual SBOMs map every artifact to its origin, transforming a static list into a dynamic supply chain graph.
• Enables Precise Ownership and Remediation Sequences: Contextual SBOMs allow security teams to immediately identify the responsible party (base image owner, builder owner, application developer) and determine the correct, optimized sequence for vulnerability fixes and rebuilds.
• Facilitates Full Automation in CI/CD Pipelines: The granular provenance data supports automated decision-making in CI/CD, enabling pipelines to trigger upstream fixes, initiate targeted downstream rebuilds, and communicate effectively without human intervention.
• Requires Consistent Artifact Identifiers: The accuracy of contextual SBOMs heavily relies on robust and unique identifiers like PURLs, checksums, and Package Verification Codes; further ecosystem investment is needed for custom binaries and files.
• Demands Contextual SBOM-Aware Tooling: To fully realize the benefits, the industry needs to develop and adopt tooling capable of generating, analyzing, and acting upon the rich, contextual information provided by these advanced SBOMs, as demonstrated by projects like Hermeto.

About the Speaker(s)

Przemyslaw "Rogue" Roguski is a security expert from Red Hat. His work primarily focuses on the critical areas of containers security and software supply chain, a domain where he actively contributes to developing innovative solutions. As highlighted in his VulnCon 2026 presentation, Roguski is deeply involved in addressing the practical challenges faced by security and engineering teams in managing vulnerabilities within complex build environments. His expertise lies in transforming theoretical security concepts into actionable strategies, such as the contextual SBOMs, to enhance the precision and automation of vulnerability management processes.