Today, Microsoft is announcing the preview of Signing Transparency to address software supply chain threats that traditional code signing alone cannot fully prevent, building on the Zero Trust principle of “never trust, always verify.” Signing Transparency uses an append-only log to verifiably record each signature, with keys protected in a secure confidential computing enclave. This allows organizations and auditors to independently verify cryptographic proof of service releases, improving security and accountability. Enhanced transparency ensures direct visibility into enforced security policies for every release, increasing trust and tamper-evidence across enterprise deployments.
Need for transparency in the software supply chain
Modern software supply chain security faces sophisticated threats. Attackers have repeatedly exploited the trust in signed software–from compromised build systems to stolen code-signing certificates–to distribute malicious updates. In fact, what is needed is a mechanism to make code signing verifiable and accountable at scale, so that any unexpected changes become evident.
When it comes to software, Signing Transparency means every signed artifact signature is recorded in a tamper-evident, open source, publicly accessible ledger. This way, anyone can later query and audit the ledger to confirm when and what was signed, and by whom, including the ledger itself, making it much harder for attackers to hide malicious signatures.
Transparency logs help extend trust in cases where code signing cannot, especially when paired with Trusted Execution Environments (TEE). For example, if an adversary manages to steal or misuse a trusted signing key, they could sign malware with a perfectly valid signature. A transparency service forces an adversary to hide from the log (raising red flags) or make their attack indelibly visible. In other words, even if attackers compromise signing keys, they cannot cover their tracks–any tampering or unexpected signing can be detected, by any party, via the transparency log. This significantly boosts confidence in the software supply chain’s integrity.
What is Microsoft’s Signing Transparency?
Microsoft’s Signing Transparency is a cloud-managed service designed to enhance trust and security in software supply chains. At its core, it acts as an impartial notary for software signatures, creating a permanent, auditable record of who signed what and when. By doing so, it provides independent verification that a given software release has not been secretly replaced or modified and that all signing events follow expected patterns.
Specifically, it maintains a public, append-only ledger of software signing events, leveraging strong cryptography and confidential hardware to ensure the ledger’s integrity for external users. Whenever software is signed (for example, an application binary, a container image, a firmware update, etc.), the signature is submitted to the Signing Transparency service. The service uses policies to verify and record a reference signature in an immutable log (captured as a Merkle tree) and signs them with a key that is created in and can never leave a secure confidential computing enclave, issuing a universally verifiable, tamper-proof receipt as evidence of the event.
This service utilizes COSE (CBOR Object Signing and Encryption) envelopes which are compliant with the Draft IETF standard for Supply Chain Integrity, Transparency, and Trust (SCITT), underlining Microsoft’s commitment to open standards in supply chain security.
| Countersigning COSE envelopes | Immutable Merkle tree ledger | Receipts for auditing and compliance |
| Signing Transparency can add a receipt for digital signatures packaged as COSE envelopes (an IETF standard format. By adding its own signature to signed artifacts envelope, it creates a second layer of attestation. Any modification to the artifact or its original signature would break this countersignature, making tampering immediately detectable. This ensures the integrity of the signed object is independently verifiable. | All counter signed records are kept in an append-only ledger implemented as a Merkle tree. Each new signing even becomes a leaf in the tree, and the tree’s root hash is cryptographically updated. The Merkle structure provides a compact, verifiable proof of inclusion for each entry. Further, no entry can be altered or removed without breaking the cryptographic links, giving strong guarantees of immutability and transparency. | For every submitted signature, the service issues a transparent statement receipt (i.e. cryptographic receipt). This receipt contains proof that the signature was logged (including the Merkle tree root and inclusion proof) and is signed by the transparency service. Organizations can store these receipts as evidence for compliance audits, and anyone can later use them to independently verify that an artifact’s signature was indeed recorded in the ledge at a specific time. |
How does it work in practice?
When a developer or automated build system signs a piece of code, the signing service generates a COSE_Sign1 signature envelope, a compact binary signing format and RFC 9052 industry standard, containing signature, metadata, and the payload. That signed object (the COSE envelope) is then sent to the Signing Transparency service. The service verifies the signature and the signer’s identity against its trust policy, then appends a countersignature to the COSE envelope. This countersignature does not replace the original—it augments it with Microsoft’s attestation and a pointer to the immutable ledger and the cryptographic inclusion proof.
When the service commits an entry to its ledger, under the hood, this ledger is backed by Microsoft’s Confidential Ledger and Confidential Consortium Framework (CCF) running in a TEE. Each entry typically includes metadata such as a hash of the signed artifact, the original signature, the signer’s identity, and the countersignature. The ledger uses a Merkle tree data structure, so when the new entry is added, a new Merkle root is computed. The service cryptographically signs this root and packages it (along with the path of hashes proving the entry’s inclusion) into the receipt returned to the user. The receipt essentially says, “We, the transparency service, have recorded your artifact’s signature at position X in our log (with root hash Y). Here is the proof and our signature to vouch for it.”
Because the receipt is a signed proof of inclusion, and the ledger is backed by confidential computing, verification proves the object passed the log’s trust policy, and the signing event was logged for every participant—be it an automated deployment system, an auditor, or an end-user—to see and independently verify.
How Signing Transparency enhances security and trust
Implementing Signing Transparency offers enterprises substantial security through:
- Tamper-evident releases: All software builds and updates must be logged, making any unauthorized or modified release immediately detectable. The immutable logs ensure artifacts have not been secretly altered.
- Independent verification: Customers and partners can verify software authenticity locally using transparency receipts, eliminating sole reliance on vendors or distribution channels.
- Audit trail and compliance: Every software component is linked to a signed receipt, providing clear evidence for compliance audits and incident investigations. Logs can be monitored for anomalies.
- Policy enforcement and accountability: Transparency services enforce logging policies and retain records of signing actions, deterring insider threats, and ensuring accountability for policy violations.
- Protection against key compromise and replay: Any use of a compromised signing key is visible in the log, and freshness proofs prevent rollback attacks by verifying the latest versions.
- Extended to firmware and hardware: The same principles apply to firmware and hardware, supporting supply chain integrity across all technology layers, from servers to IoT devices, with initiatives like OCP-SAFE and Caliptra enabling verification.
Why verifiable code integrity and transparency are essential for software supply chain security
With software supply chain attacks on the rise, organizations need proof of integrity and fast detection methods. Microsoft’s Signing Transparency service advances this by attaching a verifiable record to each signed artifact, promoting trust through transparency. For enterprises, adopting this technology enables direct verification of code, reduces risk, builds customer confidence, and deters tampering by keeping malicious actions on record.
I’m interested! How can I learn more?
Join the preview community for a virtual chat by expressing interest here.