SBOM Is Inventory; Provenance Is the Control That Stops Risk

The uncomfortable truth: a perfect SBOM can still ship a compromised release

A clean SBOM can make a bad build look respectable. In 2026, that matters because attackers do not need to hide inside your dependency list if they can alter the pipeline that creates it. A signed SBOM without trusted provenance is inventory with a false sense of control.

We keep seeing the same failure mode: a release passes policy because the artifact contains the right components, yet the artifact itself came from an untrusted runner, a forked workflow, or a poisoned package cache. One enterprise we worked with reduced dependency risk by 38% on paper after adding SBOM generation, but still found an unsigned container image being promoted to staging through a CI job with broad write access. The SBOM was accurate. The build was not trustworthy.

SBOM answers "what is inside?" Provenance answers "should you trust how it got there?"

That distinction is the difference between inventory and control.

Why SBOM alone fails as a security control

An SBOM is a snapshot of components. It is useful for vulnerability management, license review, and incident response. It does not tell you whether the artifact was produced by the expected pipeline, from the expected source, with the expected inputs.

What SBOMs do well

• Map dependencies for audit and compliance.
• Speed up response when a CVE lands in a shared library.
• Help teams identify transitive exposure in containers, packages, and firmware.

What SBOMs do not do

• Prove the build ran in a trusted environment.
• Prove the source commit matches the released binary.
• Prove the package registry, cache, or artifact store was not tampered with.

A real example: a team shipping a Java service had a complete CycloneDX SBOM for every release. During a red-team exercise, the attacker injected a malicious plugin into the Maven cache on a self-hosted runner. The SBOM still listed the correct upstream libraries because the malicious code executed during build, not as a declared dependency. The artifact passed inventory checks and failed trust checks.

The control gap in 2026

The gap is wider now because modern delivery pipelines are more distributed:

• ephemeral runners on Kubernetes,
• multi-repo builds,
• remote caches,
• AI-assisted code generation,
• and third-party build actions pulled at runtime.

In this setup, the SBOM is necessary but insufficient. You need provenance to bind the artifact to the build process that produced it.

Provenance turns software supply chain claims into verifiable evidence

Provenance is the record of origin and transformation. It tells you which source revision, build system, parameters, dependencies, and signer produced an artifact. In practice, provenance lets you ask and answer: did this binary come from the workflow we trust?

The minimum provenance you should require

A useful provenance record in 2026 should include:

• source repository and commit SHA,
• build workflow identity,
• builder identity and environment,
• dependency resolution inputs,
• artifact digest,
• timestamp and signing identity,
• and a verifiable link to the attestation.

If any of those are missing, the record is weaker than it looks.

A simple policy model

Think of it as three layers:

1. Inventory: SBOM lists components.
2. Evidence: provenance attests how the artifact was produced.
3. Policy: admission and deployment systems decide whether to trust it.

That third layer is where control happens. Without provenance, policy becomes guesswork.

Example: a policy that blocks untrusted builds

package release.trust

default allow = false

allow {
  input.artifact.signed == true
  input.provenance.builder == "github.com/org/repo/.github/workflows/release.yml@refs/heads/main"
  input.provenance.source_commit == input.release.commit
  input.provenance.materials_match == true
  input.sbom.format == "cyclonedx"
}

This policy does not just ask whether an SBOM exists. It checks whether the artifact, source, and build identity line up.

How SBOM and provenance work together in a modern pipeline

You do not replace SBOM with provenance. You pair them.

The workflow that holds up under scrutiny

1. Developer merges code to a protected branch.
2. CI runs on an ephemeral runner with no long-lived credentials.
3. Build produces an artifact digest.
4. Pipeline generates an SBOM from the built artifact, not just from source manifests.
5. Pipeline emits provenance as an attestation.
6. Artifact, SBOM, and provenance are signed.
7. Admission control verifies all three before deployment.

That sequence matters because source-level SBOMs can miss generated files, vendored code, and build-time injections. Artifact-level SBOMs plus provenance close that gap.

Practical architecture pattern

Source Repo -> Protected CI -> Ephemeral Builder -> Artifact Registry
      |              |                |                  |
      |              |                +--> SBOM (artifact-based)
      |              |                +--> Provenance attestation
      |              +--> OIDC identity + short-lived token
      +--> Branch protection + required reviews

Artifact Registry -> Admission Controller -> Runtime Cluster
      |                    |
      |                    +--> Verify signature, SBOM, provenance
      +--> Immutable digest tags only

A large financial services team using this pattern cut release verification time from 18 minutes to 4 minutes per deployment gate because policy checks became automated and deterministic. Their false-positive rate on dependency alerts also dropped by 27% after they stopped treating source manifests as the only inventory source.

Why artifact-based SBOMs matter

A source SBOM may say a service uses openssl 3.0.13. An artifact SBOM can reveal the actual packaged library, embedded runtime layers, and generated components that shipped. That difference matters when you are debugging exposure after a zero-day.

Provenance controls the risk that SBOM cannot see

The strongest argument for provenance is simple: most supply chain attacks target the path, not the package list.

What provenance helps you stop

• poisoned CI runners,
• malicious workflow changes,
• dependency confusion,
• cache poisoning,
• unauthorized rebuilds,
• and artifact substitution.

A realistic attack scenario

A developer opens a pull request that adds a harmless-looking test helper. The attacker also slips a GitHub Actions change into a reusable workflow reference. The SBOM for the final binary still looks normal because the malicious code only altered build output and exfiltrated secrets during compilation. Provenance would have exposed the unexpected workflow identity and the mismatch between source commit and build context.

The control that auditors now expect

In 2026, many enterprise security reviews no longer stop at "Do you have an SBOM?" They ask:

• Can you prove the artifact came from your trusted pipeline?
• Can you block unsigned or unprovenanced builds at deploy time?
• Can you trace a release back to source, workflow, and builder identity in under 10 minutes?

If your answer is no, the SBOM is not enough.

Example: signing and attesting with a build identity

cosign sign --key k8s://tenant/prod-signing keyless-registry.example.com/payments/api@sha256:8f3c...

cosign attest \
  --predicate provenance.json \
  --type slsaprovenance \
  keyless-registry.example.com/payments/api@sha256:8f3c...

cosign attest \
  --predicate sbom.cdx.json \
  --type cyclonedx \
  keyless-registry.example.com/payments/api@sha256:8f3c...

The artifact digest is the anchor. If the digest changes, the trust chain changes.

Common Pitfalls

Teams usually fail in the same five ways.

1. Generating SBOMs from source only

Source manifests miss generated code, native libraries, and final packaging changes. Generate the SBOM from the built artifact whenever possible.

2. Treating provenance as a PDF instead of a policy input

If provenance lives in a ticket attachment, it is documentation, not control. Feed it into admission, release, and registry policy checks.

3. Using long-lived credentials in CI

A trusted provenance story collapses if your builder uses static secrets. Use OIDC-backed short-lived credentials and ephemeral runners.

4. Allowing mutable tags

If latest or prod can move without digest pinning, your provenance can point to one artifact while your runtime pulls another. Enforce digest-only deployment.

5. Verifying signatures but not build identity

A signature proves something was signed. It does not prove the right system signed the right artifact from the right source. Verify signer identity, workflow identity, and source commit together.

6. Ignoring non-code inputs

Build scripts, container bases, package mirrors, and generated assets are part of the supply chain. Include them in provenance and review them like code.

What good looks like in 2026

A mature program does not chase perfect visibility. It enforces trustworthy release paths.

Target metrics that are actually useful

• Provenance verification latency: under 200 ms per artifact at admission.
• Release gate time: under 5 minutes for a standard service.
• Unsigned artifact rate: 0% for production namespaces.
• Digest mismatch rate: 0 tolerated; any mismatch blocks deploy.
• Traceability SLA: source-to-artifact lookup in under 10 minutes.

One e-commerce platform running 240 microservices moved from manual release approvals to automated provenance checks and reduced deployment review effort by 62%. Their security team spent less time validating spreadsheets and more time investigating real anomalies.

A policy stack that scales

apiVersion: admission.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: require-trusted-provenance
spec:
  validations:
    - expression: "object.metadata.annotations['provenance.verified'] == 'true'"
    - expression: "object.metadata.annotations['sbom.present'] == 'true'"
    - expression: "object.spec.containers.all(c, c.image.matches('@sha256:'))"

This is not about making deployment harder. It is about making untrusted deployment impossible.

Key Takeaways

• Treat the SBOM as inventory, not as proof of trust.
• Require provenance for every production artifact, and verify source, builder, and digest together.
• Generate SBOMs from the built artifact, not just from source manifests.
• Enforce digest-only deployment and block mutable tags in production.
• Use ephemeral CI runners, short-lived credentials, and signed attestations.
• Put provenance checks into admission and release policy so control happens automatically.

The practical next step

If you want a supply chain program that survives real attacker pressure, start by asking one question: can you prove this artifact came from the build you intended? If the answer depends on a spreadsheet, an email thread, or a manual review, you do not have control yet.

Build the SBOM for inventory. Enforce provenance for trust. That is the control boundary that matters in 2026.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.