This service provides engineers with a critical tool to ensure the integrity and trustworthiness of their software supply chain. It enables independent verification of signed artifacts, significantly reducing risks from tampering and compromised keys, and enhancing overall security posture.
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.
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.
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. |
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.
Implementing Signing Transparency offers enterprises substantial security through:
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.
Join the preview community for a virtual chat by expressing interest here.
The post Enhancing software supply chain security with Microsoft’s Signing Transparency appeared first on Microsoft Azure Blog.
This integration brings Anthropic's most advanced reasoning to Azure, enabling engineers to build secure, agentic workflows with a 1M token context window. It simplifies the path to production by combining frontier intelligence with enterprise-grade governance and data connectivity.
As AI adoption scales, engineers need unified tools to manage model lifecycles, security, and compliance. Microsoft’s integrated approach reduces operational risk and simplifies the deployment of responsible, agentic AI systems across complex multicloud environments.
Continue reading on the original blog to support the author
Read full articleThis integration enables engineers to build specialized AI agents for highly regulated sectors. By combining Claude's reasoning with domain-specific MCPs and Azure's secure infrastructure, teams can automate complex medical reasoning and R&D tasks while maintaining strict compliance.
