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. A build server can be compromised. A release can bypass the normal build path. A malicious binary can still be signed with a legitimate identity. An SBOM can still describe exactly what was present at build time but miss the fact that the build itself was 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. In theory, that sounds rigorous. In practice, it collapsed under 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 brutally simple: 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 impemented.
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 am no longer asking, “Do I trust this private key from CI three years ago?” I am asking, “Can I prove this exact artifact was signed by this exact identity, through this exact issuer, at this exact time, with evidence?”
That is already better than classic signing. But it still is not the full answer.
Provenance Is the Second Coming 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. Not just “someone signed it”, but “this workflow in this repository built this artifact from this revision on this builder.”
That is a much stronger statement.
It is also 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. A self-hosted runner can become a backdoor. In each case, the failure is not just lack of identity.
It is misplaced trust in labels, mutable references, and human process.
Provenance raises the bar by attaching cryptographic evidence to the build path itself.
It feels like the second coming of signing. It keeps the core promise of verifiable trust, but extends the guarantee to everything that produced the file.
The New Standard Is Layered, Not Singular Link to heading
No single control is enough here. The practical model is layered:
- 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.
This is the same broader pattern showing up across modern engineering. Good teams are moving away from “please follow the process” and toward “the system enforces the process.” Supply chain security is following the same path.
What We’ve Learned Link to heading
Across all of these topics, from container building internals to SLSA to Docker’s abandonment of full-fat TUF signing to GitHub Actions compromises, the same conclusion keeps appearing.
We should trust fewer mutable human-managed things:
- no floating tags (ahem
:latest) - no long-lived CI secrets
- no unsigned commits
- no ad hoc release steps
- no untrusted workflows running with privileged tokens
And we should trust more verifiable machine-checked evidence:
- pinned commits
- short-lived identity-backed certificates
- transparency logs
- signed provenance
- immutable releases
- policy gates
In other words, the bar is moving from “signed by someone” to “provably produced by the right system in the right way.”
Raise the Trust Bar Link to heading
In summary, the future of supply chain security is better evidence, better defaults, and better enforcement.
Signatures matter, SBOMs matter, but on their own they answer yesterday’s questions. Today we should be proving the artifact took the right path from source to consumer without disappearing into a trust gap.
That is why provenance today feels like the second coming of signing.
Do not just sign the artifact. Prove the route it took to get here.