Enhancing software supply chain security with Microsoft’s Signing Transparency
Microsoft has introduced a preview of Signing Transparency, aimed at tackling software supply chain risks that traditional code signing methods can’t completely mitigate. This initiative is rooted in the Zero Trust principle of “never trust, always verify.” Signing Transparency employs an append-only log to securely document each signature, with keys safeguarded in a protected confidential computing enclave.
Today, Microsoft is rolling out the preview of Signing Transparency to combat threats in the software supply chain that conventional code signing techniques alone can’t address, building on the Zero Trust approach of “never trust, always verify.” By utilising an append-only log, it records each signature securely, ensuring that the keys are protected within a confidential computing environment. This allows businesses and auditors to verify cryptographic evidence of software releases independently, enhancing security and accountability. The improved transparency offers clear visibility into the security policies applied to each release, fostering greater trust and evidence of tampering across enterprise systems.
The Importance of Transparency in Software Supply Chains
Today’s software supply chains face increasingly complex threats. Cybercriminals have taken advantage of the trust placed in signed software—exploiting everything from compromised build systems to stolen code-signing certificates to distribute harmful updates. Therefore, a solution is necessary to make code signing verifiable and accountable at scale, allowing any unexpected alterations to be identified promptly.
In the context of software, Signing Transparency ensures that every signed artifact is recorded in a tamper-proof, open-source, publicly accessible ledger. This means that anyone can subsequently query the ledger to verify when, what, and who signed, including the ledger itself, making it far more difficult for attackers to conceal malicious signatures.
Transparency logs play a vital role in extending trust where code signing falls short, especially when used alongside Trusted Execution Environments (TEE). For instance, if a hacker manages to steal a trusted signing key, they could fraudulently sign malware with a valid signature. However, a transparency service forces attackers to either conceal their actions from the log—which would raise immediate concerns—or make their attacks overtly visible. Put simply, even if attackers compromise signing keys, they won’t be able to erase their tracks—any tampering or unexpected signing will be detectable by any party through the transparency log. This significantly enhances confidence in the integrity of the software supply chain.
What is Microsoft’s Signing Transparency?
Microsoft’s Signing Transparency is a cloud-enabled service aimed at bolstering trust and security in software supply chains. Essentially, it acts as an unbiased notary for software signatures, creating a permanent, verifiable record of who signed what and when. This ensures that anyone can confirm that a given software release hasn’t been secretly modified and that all signing actions adhere to expected processes.
Specifically, it keeps a public, append-only ledger of software signing events, using advanced cryptography and secure hardware to preserve the integrity of the ledger for external parties. Whenever software is signed (like an application binary, container image, or firmware update), the signature is sent to the Signing Transparency service. Here, the service authenticates and records a reference signature in an immutable log (formulated as a Merkle tree) and signs it with a key that remains within a secure confidential computing enclave, providing a universally verifiable, tamper-proof receipt as evidence of the event.
The service employs COSE (CBOR Object Signing and Encryption) envelopes compliant with the Draft IETF standard for Supply Chain Integrity, Transparency, and Trust (SCITT), showcasing Microsoft’s dedication to open standards in supply chain security.
| Countersigning COSE Envelopes | Immutable Merkle Tree Ledger | Receipts for Auditing and Compliance |
| Signing Transparency can append a receipt for digital signatures packaged as COSE envelopes (an IETF standard format). By adding its own signature to the signed artifact’s envelope, it establishes a second layer of verification. Any changes made to the artifact or its original signature will break this countersignature, making tampering instantly recognizable, thus ensuring the integrity of the signed object is independently verifiable. | All countersigned records are stored in an append-only ledger structured as a Merkle tree. Every new signing event becomes a leaf in the tree, and the root hash is cryptographically updated. The Merkle format provides compact, verifiable proof of inclusion for each entry. Moreover, altering or removing any entry would compromise the linked cryptographic connections, providing strong guarantees of immutability and transparency. | For every signature submitted, the service issues a transparent statement receipt (i.e., cryptographic receipt). This receipt offers proof that the signature was logged (including the Merkle tree root and inclusion proof) and is signed by the transparency service. Organizations can retain these receipts for compliance audits, and anyone can later use them to verify that an artifact’s signature was indeed recorded in the ledger at a specific time. |
How Does It Work in Practice?
Whenever a developer or automated build system signs a piece of code, the signing service generates a COSE_Sign1 signature envelope. This is a compact binary signing format compliant with the RFC 9052 industry standard, which contains the signature, metadata, and the payload. That signed object (the COSE envelope) is then dispatched to the Signing Transparency service. The service authenticates the signature and the signer’s identity according to its trust policy, then adds a countersignature to the COSE envelope. This countersignature enhances—not replaces—the original, providing Microsoft’s attestation and a reference to the immutable ledger along with cryptographic proof of inclusion.
When the service adds an entry to its ledger, it’s supported by Microsoft’s Confidential Ledger and the Confidential Consortium Framework (CCF) operating within a TEE. Each entry encapsulates metadata, such as a hash of the signed artifact, the initial signature, the signer’s identity, and the countersignature. With Merkle tree data structure in place, when a new entry is added, the service computes a new Merkle root. The service then cryptographically signs this root and packages it, along with the chain of hashes proving the entry’s inclusion, into the receipt sent back to the user. The receipt essentially states, “We, the transparency service, have logged your artifact’s signature at location X in our log (with root hash Y). Here’s the proof and our signature confirming it.”
Since the receipt serves as signed proof of inclusion, and the ledger is fortified by confidential computing, verification confirms that the object adhered to the log’s trust policy and that the signing event was documented for every stakeholder—whether it’s an automated deployment system, an auditor, or an end-user—to observe and independently validate.
How Signing Transparency Boosts Security and Trust
Implementing Signing Transparency provides businesses with outstanding security benefits through:
- Tamper-evident releases: All software builds and updates must be logged, making any unauthorized or altered release immediately apparent. The immutable logs ensure that artifacts haven’t been secretly modified.
- Independent verification: Customers and partners can locally verify the authenticity of software using transparency receipts, eliminating the need to solely rely on vendors or distribution networks.
- Audit trail and compliance: Each software component is linked to a signed receipt, providing definitive proof for compliance audits and incident inquiries. Logs can also be scrutinized for irregularities.
- Policy enforcement and accountability: Transparency services enforce logging policies and maintain records of signing activities, deterring insider threats and ensuring responsibility for policy infringements.
- Protection against key compromise and replay: Any use of a compromised signing key is visible in the log, while freshness proofs prevent rollback attacks by verifying the most recent versions.
- Application to firmware and hardware: The same principles extend to firmware and hardware, supporting supply chain integrity across all technology layers, from servers to IoT devices. Initiatives like OCP-SAFE and Caliptra facilitate verification.
Why Verifiable Code Integrity and Transparency Are Crucial for Software Supply Chain Security
As software supply chain attacks become more frequent, organisations require reliable proof of integrity and swift detection mechanisms. Microsoft’s Signing Transparency service enhances this by linking a verifiable record to each signed artifact, fostering trust through transparency. For businesses, adopting this technology facilitates direct verification of code, mitigates risk, builds customer confidence, and deters tampering by documenting malicious actions.
I’m Interested! How Can I Learn More?
To join the preview community for a virtual discussion, express your interest here.
