The first wave of software signing asked a simple question: who signed this artifact? The next wave asks a harder one: can you prove where it came from, how it was built, and whether it ever left the trusted path? That shift, from signing files to signing provenance, is where supply chain security is heading.
We signed the artifact and still missed the attack Link to heading
For a while, the industry treated supply chain security separately:
- Generate an SBOM so you know what is inside the software.
- Sign the artifact so you know it came from someone you trust and was not modified in transit.
Both matter. SBOM explains the contents. Signing answers the identity and integrity question.
But attacks like SolarWinds and Codecov exposed the gap between those two controls. Someone compromises the build server, or ships a release that bypasses the normal build path, and the malicious binary still carries a legitimate identity. The SBOM describes exactly what was present at build time and says nothing about the build itself being poisoned. That is the problem provenance is designed to solve.
Why the first era of signing was not enough Link to heading
Traditional signing systems were built around long-lived keys and manual trust, and that combination did not survive modern delivery.
Docker Content Trust and Notary v1 are the clearest example. The model was elegant on paper: offline roots, signed targets, strong metadata, full TUF. The reality was uglier. CI systems had to become the key custodians, and signatures lived alongside extra operational machinery that was hard to integrate with the container ecosystems.
The lesson we learned was that an unadopted control is counterproductive.
That is why we pivoted. Instead of asking developers to guard private keys forever, the newer model tries to eliminate key handling from the day-to-day workflow altogether. Instead of bolting trust on, it tries to make trust travel with the artifact, the build, and the registry.
Changing what “signing” means Link to heading
Sigstore has shown this shift most clearly, and it’s what we implemented.
The core of the change is that trust moves from long-lived keys to short-lived identity-backed evidence. Fulcio does not hand out a permanent credential. A client first gets an OIDC identity token from GitHub, Google, or another issuer, then generates an ephemeral key pair locally, then sends the public key plus the OIDC proof to Fulcio. Fulcio validates the issuer and subject claims and returns an X.509 signing certificate with a validity window measured in minutes, typically about ten. The private key never needs to be stored in a vault or copied into CI secrets. It exists just long enough to sign the artifact or attestation.
That ten-minute certificate lifetime is the important design choice. Traditional PKI spends enormous effort on revocation because long-lived keys leak, linger, and outlive the humans and systems that were supposed to control them. Fulcio instead makes the credential so short-lived that the system mostly stops depending on revocation as the first line of defense. Verification becomes less about “is this key still trusted after six months?” and more about “can I prove this identity was authorized to sign at that specific moment?”
Rekor is what makes that moment durable. It is an append-only transparency log, backed by Merkle-tree proofs, that records the signature, the artifact digest, and the certificate chain used at signing time. A verifier does not just see a signature blob; it can also check that the signing event was integrated into an immutable public log and that the inclusion proof still matches the signed tree state. That is what turns “trust me, this was signed” into “the world can verify this was signed and later tampering would be detectable.”
Because certificates are so short-lived, time matters: the verifier needs durable proof that the signature was created while the certificate was still valid. That is where timestamping enters the picture. Rekor stores an integration time and signed entry timestamp, but we want to separate timestamping into a dedicated Timestamping Authority so the proof of when something was signed is independently anchored. In practice, the trust story becomes three-part:
- Fulcio proves who
- Rekor proves what was logged
- Timestamping proves when it happened
We keep TUF, but in a narrower role: distributing the root of trust safely.
This changes the shape of verification. I can ask for evidence that a named identity signed this artifact, through a known issuer, at a provable point in time.
That is already better than classic signing, though it still isn’t the full answer.
Provenance extends the promise of signing Link to heading
If SBOM tells you what is inside the artifact, provenance tells you where the artifact came from.
This is where SLSA matters. Provenance turns a build into a signed claim about source, builder, workflow, inputs, and outputs: “this workflow in this repository built this artifact from this revision on this builder.”
That is a much stronger statement, and the natural response to the real attacks we keep seeing. Git tags can be rewritten.
Commit authors are self-declared unless signing is enforced. uses: org/action@v1 looks stable while pointing at whatever that tag means today. A malicious PR can abuse pull_request_target, a cache can be poisoned, and a self-hosted runner can become a backdoor. In each case, the failure isn’t just lack of identity, it’s misplaced trust in labels, mutable references, and human process.
Provenance attaches cryptographic evidence to the build path itself. It keeps the core promise of verifiable trust and extends the guarantee to everything that produced the file.
The new standard is layered Link to heading
No single control is enough here. You need all four:
- SBOM for contents
- signatures for identity and integrity
- provenance for source and build path
- policy for enforcement
That last layer creates a self-enforcing loop: nothing can be deployed unless it has everything required.
Security evidence only changes outcomes when something actually refuses the artifact. That can be a package registry surfacing provenance, a verifier checking source URI and tag, a cluster admission controller rejecting unsigned images, or a pipeline gate requiring attestations before deploy. The mechanism matters less than the principle: trust should be checked by systems, not assumed by convention.
What we’ve learned Link to heading
The same conclusion keeps appearing across all of these topics: container building internals, SLSA, Docker’s abandonment of full-fat TUF signing, GitHub Actions compromises.
We stopped trusting floating tags (ahem :latest), long-lived CI secrets, unsigned commits, ad hoc release steps,
and untrusted workflows running with privileged tokens. What replaced them is all machine-checkable:
- pinned commits
- short-lived identity-backed certificates
- transparency logs
- signed provenance
- immutable releases
- policy gates
Raise the trust bar Link to heading
The future of supply chain security is better evidence and better enforcement. Signatures matter, SBOMs matter, but on their own they answer yesterday’s questions. That is why provenance feels like the second coming of signing: the guarantee now covers the whole path from source to consumer, with no trust gap to disappear into.
Prove the route the artifact took to get here.