TL;DR
An SBOM (Software Bill of Materials) is a point-in-time inventory of the components inside a software artifact.
A PBOM (Pipeline Bill of Materials) (a standard originated by OX Security) is a continuously updated, signed ledger of everything that produced that artifact: pipeline definitions, runner identity, build arguments, artifact signatures, and full version lineage from first commit to production.
The key difference is that a SBOM tells you what’s in your software; a PBOM tells you how it was built and whether it can be trusted
SBOM vs PBOM: At a Glance
| Capability | SBOM | PBOM |
| Component inventory | ✓ | ✓ (included) |
| Point-in-time snapshot | ✓ | — |
| Continuous, dynamic updates | — | ✓ |
| Pipeline execution lineage | — | ✓ |
| Runner identity & build arguments | — | ✓ |
| Artifact integrity verification | — | ✓ |
| Ghost build / non-deterministic detection | — | ✓ |
| Dev-process integrity (unreviewed commits, anomalies) | — | ✓ |
| Feeds risk prioritization engine | — | ✓ |
| SAST / SCA findings in context | Partial | ✓ |
| Compliance evidence (CISA SSDF, EU CRA) | Partial | ✓ |
Software supply chain security has a visibility problem. SBOMs gave security teams something genuinely useful: a structured inventory of every component inside a software artifact. But knowing what’s inside an artifact and knowing whether it can be trusted are two different things.
The build process that produced it sits entirely outside what an SBOM captures. And that gap is exactly where the most sophisticated supply chain attacks of the last five years have landed.
That’s the problem the Pipeline Bill of Materials (PBOM) was built to solve. Originated by OX Security, the PBOM extends transparency from the artifact to the entire assembly process—a signed, continuously updated record of every pipeline step, runner, build argument, and artifact signature from first commit to production.
In this post, we’ll show how the two standards differ, and why modern supply chain security requires both.
What Is an SBOM?
A Software Bill of Materials is a structured, machine-readable inventory of the components that make up a software product: open-source libraries, third-party dependencies, frameworks, and their known relationships.
Think of it as a nutrition label for software. It tells you what’s inside, but not where the food was manufactured or whether the hygiene of the factory was compromised.
SBOMs are typically produced in one of two formats: CycloneDX (developed by OWASP, optimized for supply chain component analysis) or SPDX (developed by the Linux Foundation, focused on standardized data exchange). Both are widely accepted across compliance frameworks.
The Regulatory Baseline
The SBOM mandate has teeth. A cluster of regulatory frameworks now makes transparency a procurement and compliance requirement, not a best practice:
- Executive Order 14028 (May 2021) directed federal agencies to require SBOMs from software vendors selling to the US government. While EO 14028 was formally rescinded by subsequent directives, the compliance behaviors it established (SBOM production, secure software attestation, and supply chain transparency) continue to shape federal procurement and commercial standards.
- CISA Minimum Elements (2025 draft) builds on the original 2021 NTIA baseline by adding hash, license, and generation-context fields, and reflects how SBOM tooling has matured. The comment period closed October 2025; organizations in federal or critical-infrastructure supply chains should treat the updated elements as the working standard.
- EU Cyber Resilience Act (CRA) legally requires SBOMs for digital products sold in EU markets, with enforcement timelines coming into effect in stages through 2027.
- NIST SP 800-218 (SSDF) and related frameworks increasingly reference build provenance and artifact integrity alongside component transparency.
The NTIA minimum elements (supplier name, component name, version, unique identifiers, dependency relationship, SBOM author, and timestamp) remain the baseline, but the direction is clear: regulators want more data, more frequently, with machine-readable formats and verifiable provenance.
Why SBOMs Alone Fall Short in 2026
SBOMs gave security teams something they’d never had before: visibility into what’s inside their software. In 2021, that was a significant step. In 2026, it’s necessary but no longer sufficient.
The static snapshot problem. A traditional SBOM is generated at a point in time, usually at build or release. But software pipelines are not static. A base image update can silently change your production binary without a single code commit. A shared pipeline template update can alter build logic across hundreds of services with no pull request and no trace in your repository. Your SBOM can show green while your deployed artifact is different from what was reviewed.
The AI-generated code gap. AI coding assistants now contribute to a significant and growing share of production code. That code may introduce dependencies, license entanglements, or vulnerable patterns that weren’t explicitly authored by your engineers—and that won’t show up in any SBOM generated before the AI output is consumed. Sonatype’s research shows that 80% of dependencies go overlooked for over a year even when safer versions are available, and AI-accelerated development is adding new dependencies faster than most teams can track.
The pipeline attack surface. The most sophisticated supply chain attacks no longer target your source code directly—they target the build process itself. SolarWinds, Codecov, and XZ Utils all demonstrate the same pattern: compromise the mechanism that assembles and delivers software, not the software itself. An SBOM captures the result. It cannot tell you whether the factory that produced it was clean.
Regulatory trajectory. As noted above, CISA’s 2025 updated minimum elements and the EU CRA are demanding build provenance and artifact integrity data that SBOMs in their current form cannot supply. A compliance-only SBOM strategy will require revision.
What Is a PBOM?
The Pipeline Bill of Materials (PBOM) is a standard originated by OX Security that we believe every software organization should adopt. It mandates a real-time, signed ledger of software lineage capturing not just what’s in a software artifact, but every pipeline step, runner, build argument, environment variable, artifact signature, and deployment target that produced it, from the first line of code to production release.
Where an SBOM answers “what is in this software?”, a PBOM answers “how was this software built, by whom, using what, and can any of that be verified?”
A PBOM includes a traditional SBOM as a component. It does not replace it. It completes it.
Key properties of the PBOM standard:
- Continuously updated, not generated at a point in time
- Signed per build, creating a verifiable chain of custody
- Captures full version lineage: all branches, build hashes, pull requests, artifact signatures, SLSA-relevant provenance data
- Monitors CI/CD integrity: pipeline definitions, runner identity, unauthorized configuration changes
- Feeds directly into risk prioritization: findings are evaluated against what actually ran, not inferred from static snapshots
PBOM vs SBOM: In Depth
The comparison table above captures the functional differences. Here’s the prose version.
An SBOM tells you that your application depends on log4j 2.14.1. A PBOM tells you that log4j 2.14.1 was pulled into a specific build on a specific runner, that the artifact was signed with a specific key, that the pipeline definition that ran that build hasn’t changed since the last verified version, and that the resulting artifact matches what was deployed to production. The SBOM is the ingredient list. The PBOM is the full chain of custody.
The practical implication: when log4j 2.15.0 ships with a critical patch, an SBOM can tell you which components need updating. A PBOM can tell you which deployed artifacts are actually affected based on what was genuinely built into them, not what was supposed to be built into them. That distinction determines whether your remediation is targeted or speculative.
The second major difference is temporal. Most SBOMs are snapshots; PBOMs are continuous records. A software supply chain is not a static object. It’s a living system of pipelines, registries, runners, and dependencies that changes constantly. Any security signal derived from a point-in-time view of that system is decaying from the moment it’s generated. The PBOM moves with the system.
The third difference is coverage. SBOMs cover application-layer dependencies. PBOMs cover the full attack surface: code, open-source components, secrets, IaC configurations, container layers, cloud workloads, and the development process itself including anomalous commit patterns and unreviewed code.
Anatomy of a PBOM: What’s Inside
The PBOM is a composite ledger. Its components map to the full software delivery surface.
Code Security (SAST)
Every build captures static analysis results in context, not as a standalone scan report, but as part of the build record. This means SAST findings are tied to specific versions, specific pipeline runs, and specific deployment targets. A vulnerability found in a branch that was never deployed doesn’t require the same response as one found in what’s actually running in production.
Open-Source Security / Software Composition Analysis (SCA)
The PBOM records every open-source component that was actually resolved and pulled into each build, including transitive dependencies and the specific registries they were pulled from. This closes the gap between “what my manifest declares” and “what was actually fetched”—a gap that mutable dependency tags and compromised registries can silently exploit.
Secrets, IaC, Container, and Cloud
Build environment variables, IaC templates, container base images, and cloud configuration are captured as part of the build record. Changes to any of these between builds are flagged as drift because they represent real changes to your attack surface, even when no code was modified.
Dev-Process Integrity
The PBOM includes signals from the development process itself: unreviewed commits, anomalous push patterns, force-pushes to protected branches, and identity anomalies. The XZ Utils attack succeeded in part because a malicious actor spent nearly two years building trust as a maintainer before introducing the backdoor into the build process. Process integrity signals exist precisely to surface these patterns before they reach production.
Artifact Signatures and Build Hashes
Every artifact in the PBOM ledger carries a signature and build hash, enabling verification that what’s running in production matches what was reviewed and approved. Ghost builds (artifacts produced outside the official pipeline) are detectable because they won’t appear in the ledger.
Incidents the PBOM Standard Was Built to Address
Well known supply chain incidents that spurred development of the PBOM include:
SolarWinds (2020). Attackers compromised the build system used to produce Orion software updates, injecting malicious code upstream of the artifact signing process. The software component inventory was clean. The build process was not. A PBOM approach would have captured the deviation in build execution and flagged artifacts produced by the compromised pipeline.
Codecov (2021). Attackers modified the Codecov bash uploader script that many organizations pull directly into their CI pipelines. Downstream consumers had no visibility into the fact that a pipeline tool they trusted had been tampered with. PBOM-level monitoring of pipeline tool integrity would have detected the modification before it ran.
XZ Utils (2024). In one of the most sophisticated open-source supply chain attacks on record, a threat actor spent nearly two years contributing to the XZ Utils project under a pseudonym, systematically building trust and eventually gaining maintainer access.
The malicious payload was embedded during the build process, included in release tarballs but not in the public GitHub repository, deployed only in specific environments to avoid detection.
The attack targeted OpenSSH via liblzma, achieving a CVSS score of 10. An SBOM of the affected packages wouldn’t have revealed the tampered build artifact. PBOM-level artifact integrity verification and build hash comparison would surface exactly this class of discrepancy: the same source, a different binary.
The AI Dimension: AIBOM, MLBOM, and PBOM
AI-generated code and AI model artifacts create a new layer of supply chain risk that neither traditional SBOMs nor most security tooling was designed to address.
AI models are increasingly deployed like software dependencies, built, versioned, and pushed to model registries via CI/CD pipelines and consumed via MCP servers, which introduce their own AI supply chain security risk.
Many pipelines lack any PBOM or SBOM validation for these artifacts, leaving no verifiable lineage for how a model was trained, what data influenced it, or whether an artifact was tampered with during packaging.
Emerging concepts like AIBOM (AI Bill of Materials) and MLBOM (Machine Learning Bill of Materials) attempt to extend SBOM-style transparency to AI model artifacts, capturing training data provenance, model architecture, license entanglements, and version lineage. These aren’t yet standardized, but they describe a real and growing gap.
The PBOM approach applies here directly. By correlating PBOM and SBOM data with pipeline events across model training and packaging, security teams gain verifiable lineage for every model artifact, and the ability to detect anomalous artifacts before they progress further in the pipeline.
AI-generated code, produced in the vibe coding workflows now common in enterprise development, that introduces new dependencies, unexpected licenses, or vulnerable patterns also becomes visible as part of the PBOM’s continuous code tracking.
For organizations adopting AI coding assistants at scale, PBOM-level pipeline visibility is how you know what was actually built and deployed.
PBOM vs SLSA: Complementary, Not Competing
SLSA (Supply-chain Levels for Software Artifacts) is a framework developed by Google and the OpenSSF that defines a graduated set of build integrity requirements. It establishes provenance attestations at four levels—focused primarily on how builds are performed and whether provenance can be verified.
PBOM and SLSA pursue overlapping goals through different mechanisms. SLSA defines what good looks like as a framework; PBOM is the continuous operational record that makes that verification possible at scale. SLSA provenance is one input the PBOM captures and tracks.
Organizations pursuing SLSA Level 2 or Level 3 compliance will find that PBOM lineage data provides much of the evidence SLSA attestations require—without a separate manual process.
The short version: SLSA gives you the standard; PBOM gives you the continuous, automated record that meets it.
Where PBOM Fits Today: From Inventory to Platform
The SBOM established that transparency is a security requirement. The PBOM extends that principle from the artifact to the entire assembly process. Together, they form the foundation of modern software supply chain security.
But neither is an end in itself. The value of PBOM data compounds when it feeds a broader security platform that can correlate build lineage with SAST findings, SCA results, runtime signals, and reachability analysis to surface findings that reflect what’s actually deployed (cutting through the alert fatigue that defines most AppSec workflows today) not what’s theoretically possible from reading a codebase.
That’s the role OX plays. The OX Platform generates and continuously maintains both SBOMs and PBOMs as a byproduct of existing pipeline activity, then feeds that lineage into OX’s risk prioritization engine.
The result: SAST, SCA, and runtime findings evaluated against actual execution paths. Reachability that reflects what’s running in production. False positives reduced because the context is real, not inferred.
For teams building toward ASPM maturity, SBOM/PBOM integration isn’t a separate project—it’s the data layer that makes every other security signal meaningful.
For a deeper dive into SBOM security practices and tooling in 2026, see SBOM Security in 2026.
FAQ
No. A PBOM includes a traditional SBOM as one component of a larger build record. Think of the SBOM as capturing what’s inside an artifact; the PBOM captures how that artifact was produced and whether it can be trusted. You need both: the SBOM satisfies component transparency requirements; the PBOM closes the pipeline visibility gap that SBOMs leave open.
An SBOM is a point-in-time inventory of software components. A PBOM is a continuously updated, signed ledger of the entire build process that produced those components, including pipeline definitions, runner identity, build arguments, artifact signatures, environment variables, and deployment lineage.
The SBOM tells you what shipped. The PBOM tells you how it was built and whether that process was trustworthy.
The PBOM standard was originated by OX Security. The term Pipeline Bill of Materials and the underlying technical approach (real-time, signed build ledger with full software lineage from code commit to production) are OX’s contribution to the software supply chain security space.
SLSA (Supply-chain Levels for Software Artifacts) is a framework that defines graduated build integrity requirements, including provenance attestations. PBOM is the operational record that captures the data those attestations describe.
They are complementary: SLSA defines the standard; PBOM provides the continuously maintained evidence that satisfies it. SLSA provenance is one artifact the PBOM captures and tracks.
Frameworks like CISA’s 2025 updated SBOM Minimum Elements, the EU Cyber Resilience Act, and CISA SSDF are increasingly requiring organizations to demonstrate build provenance and artifact integrity, not just component inventories.
While none of these frameworks explicitly mandates a PBOM by name, the evidence they require maps closely to what a PBOM produces: signed build records, artifact verification, and traceable chain of custody from code to deployment.
A PBOM approach makes compliance evidence a continuously maintained record rather than a manual collection exercise.
Yes. This is precisely the attack surface a PBOM is designed to surface. Because the PBOM records runner identity, pipeline definitions, build arguments, and artifact signatures for every build, deviations from expected execution are detectable.
If a build produces a different binary from the same commit—a ghost build—the PBOM ledger surfaces the discrepancy.
If a pipeline tool or runner is compromised between builds, the configuration drift is captured. These are the exact attack vectors behind SolarWinds, Codecov, and XZ Utils and they are invisible to tools that only inspect the final artifact.
See OX PBOM in Action
Your scanner sees what shipped. OX sees how it was built.
