Trust · Transparency log
A report cannot be quietly replaced. The log proves it.
A signature proves a report was not altered. The transparency log proves something else: that this exact report existed when it claims, and that a different one was not slipped in later. Every report becomes a leaf in an append-only, hash-chained Merkle log, each shipping with its own inclusion proof.
Three properties a signature alone cannot give you.
Append-only
You can add, never edit
Entries are chained by hash. Rewriting any past entry changes every hash after it, so tampering is self-evident.
Inclusion proof
Proof per report
Each report carries a Merkle proof binding it to the log's root, checkable without trusting the log operator.
No replacement
History you can rely on
A reviewer can confirm the report they hold is the one that was logged, not a quietly swapped re-issue.
Hash the report, append the leaf, return the path.
When a report is signed, its hash is appended as a leaf to the Merkle tree. The log returns the audit path from that leaf to the root. Anyone can recompute the path and confirm the leaf is included. The chained roots make removing or reordering history detectable.
RFC 6962-style Merkle log · SHA-256 leaves · per-report audit path
Each report is a leaf, appended in order, never rewritten.
An illustration of how the log grows. Every entry records its position (the leaf sequence number), the type of event, and the tree root it sealed. Because the roots chain, removing or reordering any past entry changes every root after it, so the tampering shows.
- seq 4128Signed report appendedleaf
Latest entry. Its inclusion proof is the audit path from this leaf to the current root, shipped inside the report.
- seq 4127Re-attestation deltasupersede
A fresh signed delta supersedes an earlier report. The old leaf stays in the log; it is never deleted.
- seq 4126Checkpoint root publishedroot
A signed tree head fixes the root over every leaf so far. Each new root is chained to the one before it.
- seq 4125Signed report appendedleaf
An earlier report. A reviewer holding it can recompute its audit path to this point and confirm it was logged exactly when it claims.
Sequence numbers above are illustrative. The live tree size is published at /v1/transparency-log/size, and each report's own inclusion proof verifies offline against the root it cites.
Math reviewers already accept.
Enterprise security teams are wary of crypto custody and public-chain exposure, so we keep none of that in the path. The transparency log is the same well-understood, Sigstore-style construction reviewers know from software supply-chain security, and it verifies offline. The signed envelope it anchors is specified in the report spec.
Offline
No network to verify
The inclusion proof checks against the report itself, with no network call needed.
Familiar
Supply-chain lineage
The same transparency-log idea behind modern artifact signing.
No custody
Nothing to hold
An append-only Merkle tree served over HTTPS; verification needs only the published root.
Signed, logged, and checkable by anyone.
Every report carries its own inclusion proof. Your buyer checks it offline.
Caveats: Scope is contractual. Permission posture, redaction and audit-trail integrity are assessed. Injection is tested and reported, not warranted.