Identity, Signing, and Transparency: The Foundation of Verifiable Builds
Signing artifacts is not new. Making that signing keyless, auditable, and transparently verifiable is.
Michael Lieberman
Gaurav Saxena
April 20, 2026
Before organizations can enforce build integrity, they must solve artifact identity. Who signed this? Under what authority? And can that claim be independently verified?
In their three-part blog series, Michael Lieberman and Gaurav Saxena highlight their views in shaping the future of software and walk through modern cloud-native tooling including how Sigstore, in-toto, and Kubernetes admission control makes software trust keyless, auditable, machine-verifiable, and enforceable.
Gaurav, a friend of Kusari, is an engineering leader in the field of platform and cloud engineering with over 20 years of experience in the software industry. His technical expertise includes Stream-based architectures, Kubernetes, Service Mesh, Software Supply Chain Security, and Observability.
In manufacturing, every approved supplier has a known identity. Parts don’t arrive anonymously.
Software needs the same guarantee.
For years, artifact signing relied on long-lived keys stored in CI systems. Those keys were hard to manage and easy to mishandle, rarely rotated, and high-value targets. If compromised, attackers could sign malicious artifacts with seemingly valid credentials.
The cloud-native ecosystem has moved beyond this model.
Keyless Signing with Sigstore
Sigstore introduces a keyless signing approach using OpenID Connect (OIDC) and short-lived certificates.
Instead of storing long-lived private keys:
- CI systems authenticate using OIDC tokens (e.g., GitHub Actions, GitLab CI, cloud workload identity).
- Fulcio, Sigstore’s certificate authority, issues a short-lived X.509 certificate.
- That certificate binds the workload identity (repository, workflow, subject) to an ephemeral signing key.
- The artifact is signed.
- The certificate expires shortly thereafter.
There are no long-lived secrets to manage. The signature cryptographically ties the artifact to a specific workload identity. It represents not just “someone signed this,” but “this specific workflow in this specific repository signed this.”
For security leaders, this eliminates a class of key management risk. For platform leaders, it integrates cleanly into existing CI workflows.
Rekor: The Transparency Ledger
Signing alone is insufficient without durable auditability.
Every Sigstore signature is recorded in Rekor, an append-only transparency log backed by a Merkle tree. Rekor provides:
- Tamper-evident history
- Verifiable inclusion proofs
- Durable record of signing events
Rekor functions as a global, cryptographic shipment ledger. Once a part leaves the supplier and enters the ledger, its existence and timestamp are immutable.
Even if someone deletes a container image or certificate later, the transparency log proves “This artifact was signed by this identity at this time.”
Ecosystem Maturity Matters
These technologies are not experimental.
Sigstore and in-toto are hosted under the Cloud Native Computing Foundation (CNCF), and in-toto has achieved graduated project status — signaling production maturity and broad industry adoption.
For decision makers, this matters.
Adopting these technologies aligns organizations with an ecosystem-backed direction — not a proprietary or isolated approach.
Cosign: Signing Artifacts and Attestations
Cosign ties everything together by operationalizing signing in OCI-based workflows.
It signs:
- Container images
- Provenance attestations
- SBOMs
- Policy results
Signatures are stored alongside images in registries and recorded in Rekor.
This creates something manufacturing teams would recognize immediately: a digital packet attached to every part, containing:
- Certificate of origin
- Inspection record
- Batch identity
In software, these are signatures and attestations.
But signing only answers one question: Who signed this?
It does not answer: Was it built correctly?
Knowing who signed something is important. Knowing whether it was built correctly — and enforcing that requirement — is what truly changes the security model. And that requires provenance — and enforcement.
In Part 3, we move from identity to verifiable production integrity using SLSA, in-toto, and Kubernetes policy enforcement.
Like what you read? Share it with others.
.webp)
.webp)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.jpg)
Previous
No older posts
Next
No newer posts
Want to learn more about Kusari?