A signed software artefact that nobody verifies protects you as much as an unsigned one: not at all. The same goes for an SBOM (Software Bill of Materials) generated on every build and never checked against a policy: it documents the supply chain, it does not secure it. Verifiable provenance — a dependency inventory, build attestations, a cryptographic signature — becomes a control only the moment some point in the chain rejects what fails verification. Take away that rejection and it stays paperwork for compliance.

The problem

December 2021, CVE-2021-44228 (Log4Shell): a string such as ${jndi:ldap://…} written to the logs by Apache Log4j 2 opens the way to remote code execution, with a CVSS score of 10.0. The affected versions run from 2.0-beta9 to 2.14.1; the first one to carry the mitigation is 2.15.0. The operational question for thousands of organisations — which of our systems use Log4j, in which versions, including as a transitive dependency? — rarely found a timely answer. The flaw had been in the code for years; what hurt, in the moment, was the absence of a dependency inventory you could query.

The industry responded by settling around three distinct artefacts, which are often muddled together:

  • SBOM — the component inventory (name, version, hash, licence, transitive dependencies). It answers what is inside.
  • Provenance and build attestations — who built the artefact, from which source, with which builder. It answers how it was produced.
  • Signature — the cryptographic binding between the artefact and an identity. It answers who vouches for it.

None of the three, on its own, stops a malicious deploy. To stop it you need a fourth element: enforced verification.

The architecture

The chain that works has three stages, and the third is the one most pipelines skip.

Generation. At build time you produce an SBOM (in SPDX or CycloneDX format) and provenance. The reference framework for provenance is SLSA (Supply-chain Levels for Software Artifacts), whose Build track defines increasing levels. Build L1 asks for provenance describing the platform, the process and top-level inputs — it may be incomplete and unsigned. Build L2 asks for the build to run on dedicated infrastructure and for the provenance to be tied to that infrastructure by a digital signature, with downstream verification of authenticity. Build L3 adds the controls that stop runs from influencing one another and user-defined steps from touching the secret material used to sign. Attestations are usually written with in-toto, a CNCF graduated project that standardises the metadata on the steps, actors and order of the supply chain.

Signing and transparency. Sigstore makes signing workable without having to manage long-term keys. The keyless flow goes like this: cosign generates an ephemeral key pair, Fulcio (the CA) verifies an OIDC token and issues a short-lived certificate bound to that identity, and the private key is thrown away after a single signing. The signature, certificate and artefact digest end up in Rekor, an append-only, immutable transparency log. The problem shifts: no longer guarding a key, but trusting an OIDC identity and a public log. Whoever consumes the artefact queries Rekor and confirms that the certificate was valid at signing time.

Verification enforcement. This is the stage that turns the earlier artefacts into a control. In a CI/CD pipeline it is the step that fails the build if the SBOM contains a denylisted component or a CVE above threshold. At runtime, on Kubernetes, it is an admission controller that evaluates a signing policy and rejects Pods whose image lacks a cosign signature from an expected identity, or SLSA provenance at the required level. Without this gate, generating and signing is wasted work: the deploy goes through anyway.

Where it breaks

The breaking points lie in the trust model and in verification, not in generation.

Trust root. Keyless signing shifts trust onto three elements: the OIDC provider that asserts the identity, the Fulcio CA that issues the certificates, the Rekor transparency log. A policy that accepts any signing identity verifies nothing useful: it has to pin the expected OIDC identity — for instance a specific GitHub Actions workflow inside a specific repository. Checking that the signature is there, without checking who signed, is the most common form of verification theatre.

Key management under keyless. Removing long-term keys eliminates persistent-key theft, but shifts the attack surface: whoever controls the OIDC identity controls the signature. A compromised OIDC token, or a configuration that lets any workflow impersonate the expected identity, produces valid signatures over malicious artefacts. The transparency log makes the abuse detectable afterwards, not prevented.

SBOM completeness and accuracy. An SBOM is worth as much as it is faithful to the binary you ship. Generated from the dependency manifest, it can miss components introduced by the build system or vendored into the source; generated from the final artefact, it depends on how much the scanner manages to recognise. Transitive dependencies are the exact point where an incomplete inventory misfires, just as it did with Log4j. An SBOM listing only direct dependencies would not have answered the December 2021 question.

Runtime verification. Verifying at build time and not at deploy time leaves the window between the two open. An image can be signed properly and then replaced in the registry, or a mutable tag can be repointed to a different digest. The verification that counts is the one against the immutable digest, done by the admission controller at the moment of the deploy.

What changes with the regulation

The regulatory hook moves this architecture from good practice to a constraint. The Cyber Resilience Act — Regulation (EU) 2024/2847 — entered into force on 10 December 2024, with staggered application. The obligations to report actively exploited vulnerabilities and severe incidents kick in from 11 September 2026; the bulk of the essential requirements, technical documentation included, from 11 December 2027. Annex I asks for the product’s components to be documented in an SBOM in a commonly used, machine-readable format, covering at least the top-level dependencies, placed in the technical documentation and provided to market surveillance authorities on request — with no obligation to publish it.

The two fronts are the same work seen from two sides. To report within 24 hours (early warning) when a dependency is exploited you have to know, at that moment, which products contain it. That is exactly the question an accurate, queryable SBOM answers. The regulatory deadline is 2027; the operational capability that meets it is an inventory built and verified before then.

The limits

Verifiable provenance covers the integrity and origin of the build chain, not the correctness of the code. An artefact can be impeccably signed, built at SLSA Build L3, with a complete SBOM, and still contain a not-yet-known vulnerability: Log4Shell was as signable and attestable as any other library. Provenance tells you where it comes from and who vouches for it, not it is free of defects.

The NTIA minimum elements for an SBOM (baseline data fields, traceability, operational practices) remain a floor: the alignment between the declared SBOM and the executed binary is not something the standard verifies, the pipeline has to verify it. And as of today no EU delegated act mandates a specific SBOM format: the choice between SPDX and CycloneDX is left to the organisation, as is the burden of keeping them current on every release.

For anyone starting now, the concrete step is to add the gate that verifies the artefacts, before even generating more of them. A pipeline that churns out SBOMs and signatures without an admission controller to enforce them has increased the work, not the security.

https://slsa.dev/spec/v1.0/levels https://docs.sigstore.dev/ https://www.sigstore.dev/ https://in-toto.io/ https://www.ntia.gov/page/software-bill-materials https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng https://nvd.nist.gov/vuln/detail/CVE-2021-44228 https://www.noze.it/en/insights/sbom-slsa-supply-chain/

Cover image: A hand-folded paper letter closed with a red wax seal bearing the impression of the letter “A” — photo by Contrafool, CC BY-SA 3.0 — https://commons.wikimedia.org/wiki/File:Wax_seal_with_impression_of_uppercase_letter_A.jpg