Microsoft has announced the preview of Signing Transparency, a managed service that brings the principle of Zero Trust —“never trust, always verify”— into the realm of code signing. The proposal aims to address a known weakness: valid signatures have sometimes been exploited to
Why code signing alone is no longer sufficient
For years, signing binaries, container images, or packages has been a trust marker. But traditional signatures leave no auditable trail beyond the certificate itself and do not prevent a stolen key from being used silently. In this scenario, transparency becomes the missing piece: if every signing event is recorded in an immutable ledger, then disappearing without a trace ceases to be an option for the attacker. Security now depends not only on “who signs” but also on proofs of when and under what conditions the signing occurred.
What is Signing Transparency
Microsoft defines Signing Transparency as a “neutral notary” for software signatures. Every time an artifact — a release of an application, a OCI image, or firmware — is signed, the service verifies the signature against a declared policy, counter-signs it, and records the event into an append-only ledger. In return, it issues a cryptographic receipt proving that the signature exists in the registry and indicating its position. This receipt can be stored alongside the artifact and validated independently, without relying on the provider.
The key custody and integrity of the ledger are protected through confidential computing: service keys never leave the secure enclave, and the log prevents edits or deletions. If anomalous key usage is detected, the trail remains recorded for forensic auditing.
How it works: COSE, counter-signatures, and Merkle trees
The implementation relies on COSE envelopes (standard format for signing and packaging metadata) and the SCITT transparency framework for supply chain integrity. The flow is straightforward:
- The build system generates a COSE_Sign1 containing the signature and metadata of the artifact.
- This envelope is sent to Signing Transparency, which verifies the identity and the associated policy (who can sign, from where, with what requirements).
- The service counter-signs the envelope and records it in a Merkle tree.
- It returns a receipt with proof of inclusion (hash path) and the current Merkle root of the tree.
The Merkle structure guarantees that no entry can be altered without breaking the proof of inclusion. Clients can periodically check the tree’s consistency, store receipts, and automate validation within their CI/CD pipelines.
What it brings compared to alternatives and what it preserves
The concept of transparency logs has already proven its usefulness in open ecosystems. The innovation here is a managed service with counter-signatures, portable receipts, and enclave anchoring for organizations demanding cryptographic accountability and traceability with audit guarantees. The approach does not break compatibility with existing practices: it can coexist with traditional signatures, artifact catalogs, or container registries, adding a layer of independent verification.
Concrete benefits for development, security, and compliance
- Verifiable traceability. Each release includes an independent receipt that can be stored as evidence for audits and forensic analysis.
- Visible and enforceable policies. Rules can be set (double signing, time windows, HSM/TEE use, repository scopes) and enforced with a public compliance record.
- Early detection of anomalies. Out-of-pattern signatures, unexpected identities, or unanticipated artifacts stand out when monitoring the log.
- Mitigation of replay and rollback attacks. Freshness and consistency proofs help prevent reintroduction of vulnerable older versions.
- Interoperability with enterprise tooling. Receipts can travel with the image or package and be verified locally during deployment, pipelines, and compliance platforms.
Beyond software: firmware and hardware
The same principle —auditable signature transparency— extends to firmware and hardware components. Rooted in silicon trust and secure boot measures, transparency adds a public proof of who signed each update, when, and under what policy. The ultimate goal is an end-to-end verifiable supply chain, from the circuit board to runtime.
What it doesn’t solve (and why it remains key)
Signing Transparency does not replace a secure SDLC nor basic hygiene: dependency analysis, code review, secret management, pipeline segmentation, or security testing remain essential. Transparency does not prevent an attacker from exploiting a vulnerability if the code reaches the build stage clean. What it does do is raise the bar for stealthy tactics and reduce detection times: either the attacker hides from the log — which reveals irregularities — or leaves an indelible trail that enables action.
How to prepare for adoption
- Artifact inventory. Map what gets signed (binaries, packages, images, firmware) and who signs.
- Signing policy. Define identities, conditions, co-signatures, and provenance controls.
- Receipt management. Decide where to store receipts, how to attach them to artifacts, and who validates them during deployment.
- CI/CD automation. Integrate the submission to the log and receipt verification as mandatory steps.
- Continuous monitoring. Keep an eye on tree consistency, usage anomalies, and policy gaps.
Frequently Asked Questions
What is a cryptographic receipt, and what is it for?
It’s a portable proof including the Merkle root hash and the inclusion path of your signature in the log. It demonstrates, at any given time and without vendor permission, that your artifact was signed and registered at a specific date and position.
Do I need to change my signing tools?
Not necessarily. If you already sign with corporate certificates or HSMs, you can encapsulate the signature into a COSE envelope and send it to the service for counter-signing and receipt generation. Automatically integrating this step into CI/CD is ideal.
What if a key is compromised?
Any usage will be logged; unexpected or policy-violating signatures can be detected by monitoring the log. Transparency doesn’t prevent abuse but makes it visible and accelerates response actions (revocation, blocking, rotation).
How does it integrate with audits and regulatory frameworks?
Receipts serve as objective evidence for change management and governance of releases. They help meet requirements for traceability, non-repudiation, and proof of controls in certifications and audits.
Does it also apply to containers and firmware?
Yes. Any signable artifact — OCI images, packages, binaries, firmware — can be registered to obtain transparency and proof of inclusion, strengthening integrity across the entire supply chain.
In essence, Signing Transparency does not aim to “replace” code signing but make it accountable. By combining counter-signatures, immutable records, and confidential computing, it turns each release into a verifiable fact, reduces the window for silent attacks, and raises the bar for trust and responsibility within the supply chain. For engineering and security teams, it’s a practical lever to shift from “trust because it’s signed” to “trust because it can be verified.”
via: azure.microsoft