Introduction

Software Bill of Materials (SBOMs) have become the go-to compliance artifact in container security conversations. Mandated by the U.S. Executive Order on Cybersecurity, embedded in federal procurement requirements, on track to become mandatory across the EU under the Cyber Resilience Act (CRA) by 2027, and increasingly referenced in India's CERT-In cybersecurity advisories, SBOMs are undeniably important.

But here's the uncomfortable truth: an SBOM tells you what's in a container, not whether you can trust it. That distinction matters because modern container trust depends on integrity, provenance, and runtime behavior, not just inventory.

If you've ever shipped a container image to production with a freshly generated SBOM and believed that box was checked, you're not alone. Treating SBOM compliance as container trust is one of the most dangerous oversimplifications in modern DevSecOps. This post breaks down exactly where SBOMs stop being useful, what the real trust gap looks like, and what a complete container trust posture actually requires.

An SBOM is an inventory artifact. Container trust is an integrity problem. Confusing the two leads to a false sense of security.

What an SBOM Actually Is (and Isn't)

An SBOM is a structured, machine-readable inventory of every software component in a given artifact — including libraries, packages, licenses, version numbers, and dependency relationships.

Think of it as a nutrition label for software. It answers one question: what ingredients are in here?

When applied to containers, SBOMs are typically generated either during the build process or by scanning image layers post-build. Tools produce outputs in two primary open standards:

SPDX vs. CycloneDX: Key Differences

Both formats are widely adopted, NTIA-compliant, and supported by modern tooling – but they serve different primary purposes:

For most DevSecOps teams, CycloneDX is the more operationally useful format because it maps directly into vulnerability intelligence pipelines. SPDX tends to shine in regulated environments where license auditing is a legal obligation.

This is genuinely valuable. Before SBOMs, the contents of many container images were effectively a black box. Today, teams can quickly identify whether a disclosed vulnerability affects production images. But an SBOM is still a static snapshot. It says nothing about:

• Whether the image was tampered with after the SBOM was generated

• How the image was built, or whether that build process was trustworthy

• What happens to the application at runtime

• Whether the provenance of each component can be cryptographically verified

• The security of the build environment itself

This gap between inventory and trust is not a minor implementation detail. It is a fundamental architectural limitation.

The Container Vulnerability Reality Check

The numbers make the urgency clear.

A 2024 analysis found that 87% of container images running in production carried critical or high-severity vulnerabilities — up from 75% the year prior. A related report found that the average container image carried 604 known vulnerabilities, with more than 45% of those CVEs between two and ten or more years old.

Meanwhile, software supply chain attacks are accelerating. The OSC&R 2025 Supply Chain Threat Report documented a 188% year-over-year increase in malicious packages across npm, PyPI, and Maven Central, pushing the cumulative total past 845,000 confirmed malicious packages.

The Warehouse Analogy

Shipping a container with an SBOM but without integrity controls is like labelling a

box with its contents while leaving the warehouse unlocked and unguarded. The label

tells you what should be inside — it doesn't tell you whether anyone tampered with

the contents after it was packed.

Why SBOMs Break Down as a Trust Mechanism

1. SBOMs Are Snapshots, Not Seals

The most fundamental limitation is temporal. An SBOM captures what was present at scan time but provides no mechanism to detect whether the image was modified after the scan and before deployment.

Without cryptographic signing and verification tied to the exact image digest, an SBOM is just a document. There is no way to know whether the image has been tampered with between generation and runtime unless trust is tied to additional verification controls.

2. Build-Time Blind Spots: The SBOM Tool Gap

Not all SBOM generation tools are created equal, and most have significant coverage gaps in multi-stage builds. Here is how the most commonly used tools compare:

Traditional tools reconstruct what exists. CleanSBOM reflects what was intentionally built.

The key issue is structural: most tools scan the final stage of a multi-stage Dockerfile by default, which means packages installed in earlier build stages may be excluded from the generated SBOM. While tooling such as Docker BuildKit does support expanding coverage to multi-stage builds through explicit configuration, this is not the out-of-the-box behaviour for most teams.

For complex images using multi-stage Dockerfiles, this creates a real blind spot. A final-stage inventory may be accurate for the shipped layers while still missing important context from the build path. SBOM analysis has to be part of a broader workflow — one that accounts for what happened before the final stage.

3. Provenance Is Not the Same as Inventory

An SBOM tells you what is present. Provenance tells you where it came from and how it was created. These are different security questions entirely.

A compromised CI/CD pipeline can alter an existing package without changing its version number, inject malicious code into a legitimate build step, or replace a trusted binary while leaving the package name and version in the SBOM unchanged — exactly as happened in high-profile supply chain incidents where build tooling was targeted rather than source code.

This is exactly why software supply chain failures rank as A03 in the OWASP Top 10:2025. Accurate inventory does not prove trustworthy origin, and no SBOM format, however complete, can close that gap without building provenance attestations.

4. Signing Keys Can Be Compromised

Many teams address the snapshot problem by signing their SBOMs. That is a meaningful improvement, but it introduces a new dependency: the trustworthiness of the signing key itself.

If a signing key is compromised, every SBOM signed with it becomes suspect. OpenSSF has argued that attestations strengthen trust by validating build processes and runtime integrity, which underscores that signing is not enough by itself.

Signing Without Verifiable Trust Context Is Fragile

Many teams address SBOM integrity by signing artifacts. While this improves tamper resistance, it introduces a new dependency: the trustworthiness of the signing system itself.

 If a signing key is exposed or misused, any artifact signed with that key can appear valid. In practice, the strength of signing depends heavily on how keys are generated, stored, rotated, and audited. Keys embedded in CI pipelines or accessible through environment variables significantly weaken this model.

 More importantly, a valid signature confirms that an artifact was signed, but not that it was produced by a trustworthy process. It does not capture build context, source integrity, or dependency provenance.

Modern approaches are beginning to address this by combining signing with identity-based verification and transparency logs, but signatures in isolation remain insufficient.

5. Runtime Behavior Is Outside SBOM Scope

Even a perfectly accurate, cryptographically signed SBOM tells you nothing about what the container does when it runs. It cannot surface privilege escalation, unexpected network behavior, secret probing, lateral movement, or cryptomining activity in production.

Containers averaged 4.8 misconfigurations per image in 2024. And 67% of organisations reported delaying application deployment due to security concerns related to containers and Kubernetes, most of which are runtime and configuration concerns rather than inventory concerns.

Runtime monitoring and image verification need to work together, not as separate checkboxes.

What Actually Establishes Container Trust

A complete container trust posture requires multiple layers of control across build, deploy, and runtime. Each layer answers a different security question, and no single layer, including SBOMs, is sufficient on its own. Here is how those layers stack:

Layer 1: SBOM + Vulnerability Intelligence

Start with standardised SBOM generation at build time using CycloneDX or SPDX, then feed those outputs into continuously updated vulnerability intelligence. This gives you visibility into what is inside each image and whether new disclosures affect it later.

The right approach is to treat SBOMs as actionable evidence rather than static paperwork — feeding them into automated triage, policy gates, and drift detection. CleanStart’s SBOM is built around exactly this model: enriching SBOM outputs with contextual intelligence so teams can act on them, not just file them.

Layer 2: Image Signing and Verification

Sign every container image at build time using tools like Cosign, and verify signatures at the Kubernetes admission layer before deployment. This ties trust to the exact image digest and ensures that what was built is what actually runs.

This is the integrity layer. Without it, your SBOM is a description of an artifact you cannot verify hasn't changed since it was generated.

Layer 3: Build Provenance Attestations

Adopt SLSA-aligned provenance attestations so teams can verify source repository, commit SHA, build system, and build parameters for every image. This gives you provenance — not just inventory.

A signed provenance attestation proves how the image was built, not just what it contains. Together with a signed SBOM, it closes the build-time trust gap that inventory alone cannot address.

Layer 4: Runtime Security Monitoring

Deploy runtime security tooling that can detect anomalous syscalls, privilege escalation attempts, suspicious network connections, and unexpected filesystem changes.

Image verification tells you what went into the container. Runtime monitoring tells you what it actually does once running. Both are required for a complete trust model. Open-source tooling such as Falco operationalises this layer by correlating runtime events back to image provenance.

Layer 5: Continuous Compliance and Drift Detection

Trust is not a one-time check. New CVEs, policy drift, and changing exploit conditions can alter the risk profile of an approved image weeks after it passed initial gates.

Teams need continuous re-evaluation of SBOM data, provenance, signatures, and runtime posture — not a periodic audit cycle. CleanStart's container security resources cover how to build this kind of always-on trust pipeline.

The Compliance Trap

There is a particularly dangerous pattern in regulated environments: teams start treating SBOM generation as the objective rather than as an artifact in a broader trust model.

By mid-2024, approximately 200 new SBOMs were being published per day — up from 68 per day in early 2022. But this pace still lags far behind the growth of new software components entering the ecosystem. Volume is not the same as value.

Generating an SBOM to satisfy an auditor is not the same as building a trustworthy container pipeline. Teams that check the SBOM box without addressing signing, attestations, and runtime monitoring may be compliant on paper while still exposed in practice.

The Right Approach

Treat compliance as an output of stronger engineering — not as a goal in itself.

When your build pipeline enforces signing, generates verified provenance, and monitors

runtime behaviour, compliance artifacts follow naturally. The audit trail becomes a

byproduct of doing things right, not a deliverable manufactured separately.

A Practical Starting Point

If you are a Platform Engineering or SRE team trying to move from SBOM compliance to genuine container trust, the most practical path is a phased rollout:

• Ensure every image build generates a signed SBOM attached to the image manifest. Choose your format based on primary use case — CycloneDX for CVE correlation, SPDX for license auditing. Start with hardened baseline images to reduce your initial attack surface.

• Enforce image signature verification at the Kubernetes admission layer using Kyverno or OPA Gatekeeper so unsigned images cannot reach production.

• Implement SLSA-aligned build provenance attestations for your most critical services. Tools like SLSA GitHub Generator or Tekton Chains automate attestation generation inside existing pipelines.

• Add runtime monitoring and define expected workload behavior so deviations trigger alerts. Connect image provenance to runtime events so any anomaly can be traced back to the exact build that produced it.

Conclusion

SBOMs are foundational, but a foundation is not the whole system. They provide visibility into container contents, which is critical in an ecosystem where vulnerable and malicious components are widespread.

But visibility is not trust.

Trust requires assurance that images have not been tampered with, evidence of how they were built, and confidence in how they behave at runtime. An SBOM alone answers only one of those questions.

Treating SBOM generation as the end of container security creates a false sense of completion. Treating it as the starting layer of a broader trust model creates a path toward verifiable security.