Verify the code. Every build, every time.

Every Henedo production build emits a transparency manifest, a JSON document listing the SHA-384 hash of every JavaScript, CSS, and WASM asset in the build. The manifest is:

• Signed with an Ed25519 key that lives offline and is never deployed to any server.
• Published to the transparency_manifests table, publicly readable.
• Injected as SRI integrity attributes on every <script> and <link> tag.

On app startup, your browser fetches the manifest and its signature, verifies the signature with the public key embedded in the client, and compares each asset hash against what’s actually running. Any mismatch produces a visible security warning in your browser tab.

• A rogue Henedo employee cannot serve poisoned JS to one user without the mismatch being detected.
• A server compromise cannot modify built assets without breaking every client’s SRI check.
• A CI/CD pipeline tampered post-build would produce a different hash and fail verification.
• A CDN serving stale or modified assets would fail the client-side hash check.

• A full infrastructure compromise where the attacker controls both the CDN and our offline signing key.
• A browser extension that modifies page content after SRI verification.
• A physically compromised user device.

Any external auditor or browser extension can verify any Henedo build independently:

1. SELECT manifest_json, signature FROM transparency_manifests WHERE build_id = ?
2. Verify the Ed25519 signature over manifest_json with the known public key.
3. Fetch each asset URL from our CDN and compute SHA-384.
4. Compare against the manifest, any mismatch indicates targeted code injection.

The public signing key is published at /.well-known/transparency-key.pub. Auditors, security researchers, and browser extensions are welcome to cross-check against our published log.

Our first formal third-party audit is scheduled for Q3 2026, and the architecture is already open for review today. Until the audit firm is contracted (we publish their name when we sign), what an external auditor or browser extension can verify right now is the part of the story we control completely:

• Architecture spec: SECURITY.md and BACKEND_ARCHITECTURE.md, public, maintained, line-by-line citable.
• Signed builds: every production deploy publishes its manifest to the public log; the auditor workflow above runs in any browser.
• Bug bounty: $5K to $25K paid for confirmed issues, see the security page.
• Source-level disclosures: the cryptographic primitives we depend on, with their library versions, on the security page.

Most launches ask you to wait for an audit before they document anything. We document first; the audit confirms what is already in the open.

Your data is engineered to survive any single point of failure, including ours. The transparency log is one half of that promise; the export architecture is the other.

The signing public key is embedded in every Henedo build, so any cached copy of the app remains independently verifiable. Manifests already published are public records. If Henedo ever winds down, the log mirrors to a successor archive so future auditors can verify any historical build.

For your data itself: vault exports are an open OAIS-style bundle, the M-DISC option is a no-Henedo recovery path, and the decrypt-without-Henedo recipe is published in full. See the portability page.

The full security architecture (including zero-knowledge encryption, Argon2id key derivation, device-bound ASK, WebAuthn PRF, Shamir secret sharing, and canary-blob breach detection) is documented on the security page. The fault-isolation argument for the bundled product is on the architecture page.