A software bill of materials you cannot query under pressure is paperwork, not protection. Most of the SBOMs I encounter in enterprise environments are exactly that: a compliance artefact that was generated once, stored somewhere, and has not been touched since. When the next Log4Shell-class vulnerability lands, that organisation will spend three to five days doing manually what a queryable, integrated SBOM should answer in under ten minutes.
The gap between "we have an SBOM" and "we can act on our SBOM" is wider than most engineering leaders realise — and closing it is the actual work.
Why You Almost Certainly Have a Dead SBOM
The trigger for most SBOM programmes is a compliance requirement. The EU Cyber Resilience Act, NIS2, DORA for financial services, and a growing number of US federal procurement mandates all reference SBOM in some form. The path of least resistance is to generate one — syft, cdxgen, or Trivy's SBOM output mode, pointed at your container images or dependency manifests — tick the box, and move on.
That file, in CycloneDX or SPDX format, is sitting in an S3 bucket or attached to a release artefact. It is accurate as of the moment it was generated. It has no integration with your vulnerability management tooling. It has no queryable API. Nobody on your security team has run a search against it in the past six months. And it is not updated when a transitive dependency changes, which in most ecosystems happens continuously.
That is the default state. It satisfies the letter of most compliance requirements. It provides no operational value.
The transitive dependency blindspot
A typical containerised application has between 200 and 600 direct and transitive dependencies. Your SBOM generated at release time captures that snapshot. By the time a CVE lands three months later, one or more of those transitive dependencies may have changed — through a base image update, a package manager lock file update, or a dependency of a dependency being patched. A static SBOM that is not regenerated continuously is not a bill of materials. It is a receipt.
What SLSA Actually Requires (and Where Organisations Stop)
SLSA — Supply-chain Levels for Software Artifacts — is a Google-originated framework now under the OpenSSF. It defines four levels of supply chain integrity, from basic provenance (Level 1) to fully hermetic, reproducible, auditable builds (Level 4). The levels matter because they describe what an attacker has to compromise to inject malicious code into your software supply chain.
| SLSA Level | What It Guarantees | Typical State I Find |
|---|---|---|
| L1 — Provenance | Build provenance exists; who built what and when | Most teams reach this with GitHub Actions or similar |
| L2 — Hosted build | Build runs on a hosted, managed service; provenance is signed | Maybe 40% of enterprise pipelines |
| L3 — Hardened build | Build is isolated, non-falsifiable provenance, ephemeral environment | Under 20% — this is where most programmes stall |
| L4 — Reproducible | Build is fully hermetic; reproducible bit-for-bit; two-party review | Less than 5% — primarily OS and critical infrastructure projects |
The reason organisations stall at L2 or early L3 is that the jump from "we sign our provenance" to "our build environment is genuinely isolated and tamper-evident" requires infrastructure changes that cut across multiple teams. CI/CD, secrets management, dependency pinning, and artifact storage all need to be in scope simultaneously. That's a cross-functional project, not a security team checklist.
The Three SLSA Gaps I Find Most Consistently
Gap 1: Unsigned or weakly-signed provenance. Many teams generate SBOM provenance but don't cryptographically sign it using Sigstore/cosign or equivalent. Unsigned provenance asserts nothing. An attacker who compromises your build system can generate their own provenance document. The signature is what makes the assertion non-falsifiable.
Gap 2: Pinned-but-unverified dependencies. Pinning a dependency version in package-lock.json or requirements.txt is not supply chain security. It pins the version identifier, not the content hash. A compromised package registry that serves different content for the same version identifier will bypass version pinning. Content-addressed pinning — using hash digests — is what L3 requires and what almost nobody actually does for transitive dependencies.
Gap 3: No CI gate on SBOM vulnerability status. Even organisations that generate good SBOMs and have them integrated with a vulnerability management tool rarely gate their CI pipeline on SBOM vulnerability status. The SBOM is consulted reactively, not used as a deployment gate. That means a known critical CVE in a dependency can ship to production unimpeded.
What an Operational SBOM Programme Actually Looks Like
The difference between a dead SBOM and an operational one is integration and automation. Here is the architecture I implement when rebuilding a client's supply chain posture:
Every build, not every release. SBOM generated from final build artefact (container image or binary), not from source manifests. CycloneDX format with component hashes, not just version identifiers. Signed using cosign with a Sigstore transparency log entry.
SBOM attached to the OCI artefact in your registry (AWS ECR, Azure ACR, Harbor) using OCI Referrers API. Not stored as a file in S3. The attachment means the SBOM travels with the image and can be queried by any tooling that understands OCI Referrers.
Grype or Trivy continuously scanning SBOM inventory against NVD, OSV, and GitHub Advisory Database. Not at scan time only — on new CVE publication. When a new CVE is published that matches a component in any current SBOM, a ticket is created automatically with affected services, severity, and fix availability.
Deployment pipeline queries SBOM vulnerability status before promoting to production. Critical CVEs with available fixes: block. Critical CVEs without fix: alert and require manual exception with documented risk acceptance. High CVEs: alert, log, allow with ticket creation. Medium and below: log only.
The deployment system verifies the SLSA provenance attestation before running the image. Provenance must chain to a known, signed build in your CI system. An image without verifiable provenance cannot be deployed to production. This is the control that closes the "compromise the registry" attack vector.
The "Are We Affected?" Test
Here is the test I run on every client's SBOM programme. I pick a historical CVE — typically Log4Shell (CVE-2021-44228), Spring4Shell (CVE-2022-22965), or a recent OpenSSL vulnerability — and I ask: "Show me which of your production services are running a version of this component. Show me the answer in five minutes."
The answer tells me everything. Organisations with an operational SBOM programme can pull that query from their vulnerability management tool's SBOM index in under two minutes. Organisations with a compliance SBOM need to start from their CI logs, run a scan against each service's last known image, and hope the image hasn't been updated since the SBOM was generated.
The five-minute test is also a board-level conversation. When I present SBOM maturity assessments to boards or risk committees, I frame it as: "If the next Log4Shell lands tomorrow, how long before your CISO can tell you which products are affected with high confidence?" The honest answer at most organisations is "two to five days." The target answer is "before the morning standup."
SBOM is an insurance policy with a known payout delay
The value of an operational SBOM programme is almost entirely realised during a critical vulnerability response. The cost is paid continuously in tooling and process. The economics only make sense if you're realistic about the payout scenario: a high-severity, widely-exploited vulnerability where your ability to respond in hours rather than days determines whether you have a manageable incident or a regulatory event. For any company operating under DORA, NIS2, or handling personal data at scale, that scenario is not hypothetical.
The SLSA Level That Actually Matters
For most commercial software organisations — SaaS, financial services platforms, industrial software — the practical target is SLSA L3. Not L4; L4 is for operating systems and the Linux kernel. L3 means your build provenance is signed, your build environments are ephemeral and isolated, and you can demonstrate a chain of custody from source commit to deployed artefact.
Getting from L1 to L3 typically takes three to six months of focused work, depending on the complexity of your CI/CD landscape. The investment is front-loaded in the build system refactor. The operational overhead, once established, is low.
What I find consistently: organisations that invest in reaching genuine SLSA L3 with an integrated SBOM programme handle critical vulnerability events at a fraction of the cost — in engineering time, regulatory exposure, and customer communication overhead — compared to organisations that stopped at compliance-level SBOM generation.
| Scenario | Compliance SBOM (Static) | Operational SBOM (L3) |
|---|---|---|
| New critical CVE published | Manual scan of known services, 2–5 days | Automated alert with affected services, under 30 min |
| "Are we affected?" to board | Estimate with caveats, 24–48 hours | Definitive answer, same day |
| Patch verification | Manual confirmation per service | Automated via post-patch SBOM diff |
| Audit evidence (DORA/NIS2) | Static documents, manual assembly | API-queryable, timestamped provenance chain |
| Incident blast radius | Unknown until manual investigation | Bounded to known component graph immediately |
The difference is not primarily technical. It is architectural: the decision to treat SBOM as operational infrastructure rather than a compliance document.
Where to Start
If your current SBOM programme is static and compliance-driven, the highest-leverage starting point is not SLSA L4 or full hermetic builds. It is:
- Switch to continuous SBOM generation at build time (not release time), attached to your OCI artefacts.
- Integrate your SBOM inventory with a vulnerability scanner that monitors for new CVE publications against your component graph.
- Add a CI gate that blocks promotion of artefacts with critical CVEs that have available fixes.
That gets you from "we have an SBOM" to "our SBOM is doing something" in four to six weeks. The SLSA provenance signing and build isolation follow as the next phase. But the operational integration is what delivers the actual risk reduction — and it is what most organisations have not done.
If you're running a platform under NIS2, DORA, or CRA scope and you're not certain whether your SBOM programme would survive a "are we affected?" test under a critical CVE event, let's talk — book a 30-minute discovery call. I'll give you an honest read on where the gaps are and what closing them actually requires.