SBOM Is Necessary. SBOM Is Not Enough. Meet PBOM.
The Software Bill of Materials movement won the policy battle. EU CRA mandates them. US Executive Order 14028 mandates them. Every government procurement framework requires them. Every supply chain security vendor talks about them.
An SBOM is necessary. It is also, by itself, structurally insufficient against the supply chain attacks that the SBOM movement was supposed to prevent.
This post explains why, and what comes next: the Production Bill of Materials, or PBOM.
// what an sbom actually tells you
An SBOM is a manifest of components that were intended to be in a build. Generated typically at CI time, signed at release, stored as an artifact, distributed with the product.
The intended uses are clear. Vulnerability triage — when CVE-2026-X is announced for library Y, every SBOM that lists library Y is a potential exposure. Compliance — regulators can verify that products meet their declared component lists. Supply chain analysis — organizations can map their dependency graphs and identify concentration risk.
The SBOM is generated from the source. It reflects what the build process was supposed to produce. It is, fundamentally, a document about intent.
// why intent is not enough
Look at the supply chain attacks of 2025 and 2026 and notice a pattern.
The PyTorch Lightning compromise of April 2026 — the malicious version 2.6.2 was published directly to PyPI by an attacker with the maintainer's credentials. The Lightning team confirmed: "An attacker with access to our PyPI credentials cloned our open source code, injected a malicious payload, and pushed those tampered builds directly to PyPI as malicious versions, bypassing our source control entirely."
The Bitwarden CLI npm compromise of late April 2026 — same pattern. The malicious code went directly to npm. The GitHub repository was clean throughout.
The Trivy GitHub Action compromise — TeamPCP force-pushed tags to point at malicious code. The repository's main branch was unaffected. The release tags were the attack surface.
In all of these cases, an SBOM generated from source would be clean. The malicious artifact was introduced at the registry level, not the source level. The downstream consumer's SBOM, generated against the source they pulled, would also be clean. Because the SBOM is a document about intent, and the attacker bypassed the intent layer entirely.
The attacker is not in your source. The attacker is in your runtime.
// the pbom concept
A Production Bill of Materials is a manifest of what is actually running. Generated at runtime, by inspecting deployed processes, loaded libraries, container layers, and active configurations.
Where the SBOM answers "what was supposed to be in this build?", the PBOM answers "what is actually executing right now?"
The two should match. When they do not, something is wrong. Either the deployment was corrupted, the supply chain was compromised, or the build process was tampered with. The reconciliation between SBOM and PBOM is the actual security signal.
// how a pbom is constructed
Several techniques contribute to PBOM generation. The current state of the practice combines them.
For containerized workloads, the running container's image layers can be inspected to enumerate installed packages, files, and binaries. Tools like Syft, Trivy, and Grype can generate this from a running container or its image. The output is a list of components that were actually present at deploy time, which may differ from what was specified in the Dockerfile if the base image was updated, if a layer was rebuilt, or if a registry-level compromise occurred.
eBPF-based runtime inspection can enumerate the libraries actually loaded by running processes, the network connections they make, and the files they access. This catches dynamically loaded dependencies that may not appear in static analysis. Tools like Tetragon, Falco, and the runtime modes of several ASPM platforms produce this signal.
Sigstore and similar attestation frameworks let you verify at deployment time that the artifact you are pulling matches a trusted signing identity. The verification step itself produces a record of what was actually pulled, which becomes part of the PBOM. npm install with --provenance and Docker pull with cosign verification both contribute to this.
For Kubernetes and similar orchestrators, the deployed pod specs, image digests, and configmaps can be captured at deploy time. These are immutable references to what was actually scheduled, regardless of what the Helm chart or Terraform module said. Reconciling deployed manifests against their source-controlled definitions is part of the PBOM workflow.
// the reconciliation gap
SBOM and PBOM should agree. When they do not, you have a signal worth investigating.
Common patterns of divergence:
- Image base layer was updated after the SBOM was generated. New CVEs may apply that the original SBOM did not capture.
- A dependency was introduced via a transitive update that bypassed the lockfile. This is rarer with modern lockfiles but still occurs.
- Configuration management injected an additional component at deploy time — sidecars, agents, monitoring tools that the SBOM did not include.
- The package registry returned a different artifact than the SBOM was generated against. This is the supply chain compromise case. It is the most important signal in the list.
- A runtime download — a model file, a binary blob, a configuration pulled from a remote source — added components after the build phase. This is increasingly common with AI workloads that download model weights at runtime.
The practical operational pattern: alert on PBOM-SBOM divergence at a configurable threshold, investigate the divergences, and update either the SBOM generation process or the deployment process to reduce future divergence.
// what to actually do
The full PBOM concept is not yet a single product category. Its components are spread across runtime security tools, container scanners, eBPF observability, and ASPM platforms. Adopting the concept in practice looks like this:
- Continue generating SBOMs in CI. This is required for compliance and remains the baseline document.
- Add Sigstore or equivalent attestation verification at deploy time. The deploy pipeline should refuse to deploy artifacts that do not verify.
- Add container image scanning at registry pull time, not just at build time. Re-scan deployed images periodically to catch new CVEs in already-deployed components.
- Capture deployment manifests with image digests at deploy time. Store them as immutable records.
- If runtime instrumentation is feasible — eBPF, Tetragon, Falco — capture the actual loaded libraries and accessed files. Compare against expected.
- Define what "divergence" means for your environment. Set thresholds. Build alerting.
// the larger principle
The supply chain security conversation has been dominated by source-based controls. Pin dependencies, lock versions, scan source, generate SBOMs. All of this matters. None of this catches an attacker who pushes malicious artifacts to the registry directly.
The PBOM concept extends the security model to include runtime. The defender does not assume that the artifact in production matches the manifest in source control. The defender verifies it, continuously, and alerts on divergence.
This is more work than just generating SBOMs. It is also the work that closes the gap between "we documented our intent" and "we know what is actually running."
SBOM is the table stakes. PBOM is where the actual defense lives. The 2026 supply chain attacks have made the distinction concrete. The defensive industry is starting to catch up. The teams that move first will pay less to attackers in the meantime.
