Transparency Log

The log operates as a Write-Once-Read-Many (WORM) data structure. Once an entry is recorded, it can never be modified, deleted, or reordered. This is enforced through a Merkle Tree structure, where each new entry contributes to a single, cumulative root hash. Any attempt to alter a historical record would immediately invalidate the root hash, providing tamper-evidence and guaranteeing data integrity over the entire history of the log.

The log's backbone is a Merkle Tree, a binary tree where each leaf node is the hash of a logged entry, and each non-leaf node is the hash of its two children. This generates a single root hash that represents the state of the entire log at a given time. This structure enables:

• Inclusion Proofs: A compact, logarithmic-sized proof that a specific entry exists in the log.
• Consistency Proofs: A proof that a later version of the log is an append-only extension of an earlier version, without downloading the entire log.

The log is designed to be publicly accessible and verifiable by any party, not just the log operator. Monitors can continuously watch the log for entries matching specific patterns (e.g., certificates issued for their domain). Auditors can cryptographically verify that the log is behaving correctly by checking consistency proofs and ensuring no history has been rewritten. This transparency eliminates the need to blindly trust the log operator, a core tenet of zero-trust architectures.

To prevent a malicious log from presenting a split-view—showing different versions of the log to different observers—transparency logs employ gossip protocols. Witnesses are independent, third-party entities that fetch the latest signed tree head (root hash) from the log, verify its consistency, and gossip it to other witnesses and monitors. This creates a globally observable, non-repudiable state, making it computationally infeasible for the log to equivocate without detection.

Modern transparency logs, such as Rekor in the Sigstore ecosystem, are designed for a keyless signing paradigm. Instead of managing long-lived private keys, a signer authenticates via an OpenID Connect (OIDC) identity. A certificate authority like Fulcio issues a short-lived code-signing certificate bound to that identity. The signing event, including the ephemeral certificate, is then immutably recorded in the transparency log, providing a verifiable, timestamped attestation of the signing action without the burden of permanent key management.

Every entry in the log is indelibly timestamped, providing a verifiable chronological order of events. This is critical for establishing non-repudiation—the signer cannot plausibly deny having performed the signing action at that specific point in time. In software supply chain security, this proves that an attestation or signature existed before a vulnerability was disclosed, not retroactively generated after the fact, thereby preventing post-compromise forgeries.

A data storage model where information, once written, cannot be modified or deleted. This property is the physical and logical foundation of a transparency log. WORM-compliant storage ensures that every signing record is permanently preserved in its original state, providing an immutable audit trail that satisfies regulatory requirements for non-repudiation and long-term data integrity.

A security property that provides undeniable proof of the origin and integrity of data. In the context of transparency logs, non-repudiation ensures that the entity that signed a model artifact cannot later deny having done so. The combination of a publicly auditable log, cryptographic signatures, and timestamped entries creates a legally and technically defensible chain of custody for every model version.

The cryptographic data structure that underpins transparency log efficiency and verifiability. Each leaf node contains a hash of a signing record, and every non-leaf node contains the hash of its children. This structure enables:

• Inclusion proofs: Prove a specific entry exists in the log without revealing the entire dataset
• Consistency proofs: Verify that a newer version of the log is an append-only extension of an older version
• Tamper evidence: Any modification to a single entry invalidates the root hash