PBOM vs SBOM: What’s the Difference, and Why Does It Matter in 2026?
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.
A PBOM does not replace an SBOM. It contains one, as a component of a larger build record.
An SBOM identifies known vulnerable components inside a finished package; a PBOM surfaces build-path tampering, unauthorized script execution, and unapproved runner behavior as they occur.
Compliance frameworks including the EU CRA, whose reporting obligations begin on 11 September 2026, and NIST SSDF increasingly require verifiable build provenance rather than static inventories alone.
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
✓
Install-time lifecycle-hook auditing
—
✓
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 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.
Join us as we uncover 30+ disclosures and 10+ CVEs and explore what this new reality means for security leaders
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, and its reporting obligations begin on 11 September 2026. From that date a manufacturer must submit an early warning within 24 hours of becoming aware of an actively exploited vulnerability or severe incident, a full notification within 72 hours, and a final report within 14 days of a corrective measure becoming available, or within a month for a severe incident. Reporting to that clock means knowing exactly how each affected build was produced, and that is evidence a static inventory cannot supply.
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
In 2021, having that inventory was a significant step forward. 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. Dependency hygiene already lags where fixes exist: Sonatype’s 2026 research traces nearly 1.8 billion avoidable downloads of vulnerable versions in 2025 to four Java components alone, each with a fix already published. AI-accelerated development compounds that, adding dependencies faster than most teams can track and drawing version choices from training data that lags the fixes.
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. The newest variant of that pattern is install-time execution: npm lifecycle scripts that fire inside the build runner the moment dependencies are installed, before any static scanner runs, as the Shai-Hulud worm has demonstrated at scale. 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 how much of that can be verified?”
A PBOM includes a traditional SBOM as a component, rather than replacing 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
Three things separate an SBOM from a PBOM in practice: what each one tells you, how current that information stays, and how much of the pipeline it covers.
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 starts decaying 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.
Shai-Hulud (2025 onward)
A self-replicating npm worm that targets package lifecycle hooks inside CI/CD build environments rather than the source code of the packages it travels through. Its install-time scripts fire when dependencies are pulled onto a build runner, executing before static scanners run, then harvest environment variables and credentials and republish infected versions of other packages using the maintainer tokens they steal.
CISA recorded over 500 compromised npm packages in September 2025, and the worm has kept evolving since: OX research tracked an outbreak in August 2026 that compromised more than 440 npm packages, reaching downstream projects with an estimated two billion monthly downloads. An SBOM of an affected build lists clean dependencies. A PBOM records the lifecycle-hook execution and the credential access on the runner itself.
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.
In practice, that provenance is expressed through in-toto attestations: cryptographically signed metadata declarations proving that specific build steps, source commits, and environments produced a given artifact. Taken individually, each attestation is a snapshot. The PBOM is what binds them together, linking every attestation to the runner, pipeline definition, and build arguments that generated it, so a team can verify that what runs in production matches the recorded build.
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.
Common Mistakes: Where Supply Chain Security Programs Fail
Programs that invest heavily in supply chain security still tend to fail in the same three places, each of them a misreading of what a given control actually covers.
The SBOM False Sense of Security
A clean dependency list is evidence about components, not about the environment that assembled them. If the runner was compromised, or a malicious lifecycle hook executed during package installation, the inventory still comes back clean.
Treating Provenance as Passive Compliance
Signed attestations generated for an auditor’s checklist carry no defensive value on their own. They become a control only when they are validated at deployment gates and used to block builds that cannot be verified.
Collecting Disconnected Attestations
Isolated signatures with no cryptographic link back to source commits, pipeline configurations, and secret accesses cannot be reassembled into a chain of custody during an incident investigation – precisely when the evidence is needed most.
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.
Neither, however, 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, tracing software from the initial developer commit through CI/CD build runners to production runtime, then feeds that lineage into OX’s risk prioritization engine.
The result is that SAST, SCA, and runtime findings get evaluated against actual execution paths, reachability reflects what’s running in production, and false positives drop because the context is real, not inferred.
For teams consolidating AppSec onto a single platform, 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.
Your scanner can tell you what shipped. OX Code records how it was built: the runners, build arguments, secret accesses and signatures behind every artifact, maintained as a byproduct of the pipelines you already run. Book a demo to see a PBOM assembled against your own repositories.
FAQs
Is a PBOM a replacement for an SBOM?
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.
What’s the difference between a PBOM and an SBOM?
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.
Who created the PBOM standard?
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.
How does PBOM relate to SLSA provenance?
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.
How does a PBOM differ from traditional CI/CD audit logging?
Traditional CI/CD logs are text-based, unverified, and vulnerable to post-hoc manipulation or runner tampering. A PBOM binds execution logs, environment parameters, and secret usage with cryptographic signatures and immutable attestations, creating a tamper-evident record across the entire development lifecycle.
Does my organization need a PBOM for compliance?
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. The nearest deadline is the CRA’s reporting regime, which applies from 11 September 2026 and sets 24-hour, 72-hour and 14-day clocks that are only realistic where build provenance is captured continuously rather than reconstructed after the fact.
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 a traceable chain of custody from code to deployment, maintained continuously rather than assembled by hand.
Can a PBOM detect supply chain attacks targeting CI/CD pipelines?
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 More
The post PBOM vs SBOM: What’s the Difference, and Why Does It Matter in 2026? appeared first on OX Security.