{"id":47580,"date":"2025-11-03T09:00:00","date_gmt":"2025-11-03T17:00:00","guid":{"rendered":""},"modified":"2025-10-31T13:45:24","modified_gmt":"2025-10-31T20:45:24","slug":"enhancing-software-supply-chain-security-with-microsofts-signing-transparency","status":"publish","type":"post","link":"https:\/\/azure.microsoft.com\/en-us\/blog\/enhancing-software-supply-chain-security-with-microsofts-signing-transparency\/","title":{"rendered":"Enhancing\u00a0software\u00a0supply chain security with Microsoft’s Signing Transparency"},"content":{"rendered":"\n

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 \u201cnever trust, always verify.<\/em>\u201d 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.<\/p>\n\n\n\n

\n
Sign up for Microsoft’s Signing Transparency preview<\/a><\/div>\n<\/div>\n\n\n\n

Need for transparency in the software supply chain<\/h2>\n\n\n\n

Modern software supply chain security faces sophisticated threats. Attackers have repeatedly exploited the trust in signed software<\/a>\u2013from compromised build systems to stolen code-signing certificates\u2013to distribute malicious updates. In fact, what is needed is a mechanism to make code signing verifiable and accountable at scale<\/strong>, so that any unexpected changes become evident.<\/p>\n\n\n\n

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<\/em> and what<\/em> was signed, and by whom<\/em>, including the ledger itself, making it much harder for attackers to hide malicious signatures.<\/p>\n\n\n\n

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\u2013any tampering or unexpected signing can be detected, by any party, via the transparency log. This significantly boosts confidence in the software supply chain\u2019s integrity.<\/p>\n\n\n\n

What is Microsoft\u2019s Signing Transparency?<\/h2>\n\n\n\n

Microsoft\u2019s 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.<\/p>\n\n\n\n

Specifically, it maintains a public, append-only ledger of software signing events, leveraging strong cryptography and confidential hardware to ensure the ledger\u2019s 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.<\/p>\n\n\n\n

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\u2019s commitment to open standards in supply chain security.<\/p>\n\n\n\n

Countersigning COSE envelopes<\/strong><\/td>Immutable Merkle tree ledger<\/strong><\/td>Receipts for auditing and compliance<\/strong><\/td><\/tr>
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. <\/td>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.<\/td>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.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

How does it work in practice?<\/h3>\n\n\n\n

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<\/a>, containing signature, metadata, and the payload. That signed object (the COSE envelope<\/em>) is then sent to the Signing Transparency service. The service verifies the signature and the signer\u2019s identity against its trust policy, then appends a countersignature to the COSE envelope. This countersignature does not replace the original\u2014it augments<\/em> it with Microsoft\u2019s attestation and a pointer to the immutable ledger and the cryptographic inclusion proof.<\/p>\n\n\n

\"The<\/figure>\n\n\n\n

When the service commits an entry to its ledger, under the hood, this ledger is backed by Microsoft\u2019s Confidential Ledger<\/a> and Confidential Consortium Framework<\/a> (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\u2019s inclusion) into the receipt<\/strong> returned to the user. The receipt essentially says, \u201cWe, the transparency service, have recorded your artifact\u2019s signature at position X in our log (with root hash Y). Here is the proof and our signature to vouch for it.\u201d<\/em><\/p>\n\n\n\n

Because the receipt is a signed proof of inclusion, and the ledger is backed by confidential computing, verification proves the object passed the log\u2019s trust policy, and the signing event was logged for every participant\u2014be it an automated deployment system, an auditor, or an end-user\u2014to see and independently verify.<\/p>\n\n\n\n

How Signing Transparency enhances security and trust<\/h2>\n\n\n\n

Implementing Signing Transparency offers enterprises substantial security through:<\/p>\n\n\n\n