The Attestation Layer — Or, the Trust Anchor Was Never Random

One of eMudhra's certificate authority private keys is the number 4.

Not "a number starting with 4." Not "4 followed by a few hundred random digits." The number four, in a field where a single byte of entropy is supposed to be 384 bits. Another key is 56. Another is 115. Every one of the eight compromised intermediate keys is 47 bytes of zeros and one non-zero byte — eight bits of trust, brute-forced in at most 255 steps on a laptop, in under a second, by anyone who looked at the public certificate.

This is today's top security story (840 points, 401 comments), and it is the cleanest illustration I've seen of why attestation is a layer and not a checkbox. Everything about those certificates was structurally valid: a public key derived from d = 4 is a perfectly good point on P-384, the encoding was correct, the curve was correct, the chain validated, the CA passed its audits. The only way to find out was to try.

Evaluation (#67) asked whether your numbers mean anything. Attestation asks a colder question: what exactly did you verify, and who verified the thing that verified it?

Why attestation is a layer, not a checkbox

Attestation is the artifact you accept instead of doing the work yourself. A CA signature means "someone audited this identity." A package signature means "this came from the maintainer." A SOC 2 report means "someone checked the controls." You accept these because verifying everything firsthand doesn't scale. That's a reasonable trade — until you notice the layer has gravity, and the things it holds up are the things you can't re-derive later.

• Structural validity is not the property you wanted. A key that factors in one step passes every format check ever written. So does a signed package built from a compromised release. So does an attestation issued by an auditor who never tested the control. Checks verify shape. You wanted entropy, provenance, and independence, and none of those are shapes.
• There is no thief, so there is no blast radius. Normal key compromise has a moment: someone stole it, on a date, and you can reason about who has it. Here the key was effectively public from the day the certificate was issued — a 17-month window in which anyone could have recovered it, and no way to know whether anyone did. Your incident timeline assumes an event. The compromise was a property.
• Revocation is a suggestion, not a withdrawal. Chrome and Firefox blocked the intermediates within hours. But curl, Python, Node, Go, Java, git and every package manager on your fleet trust a CA bundle on disk, don't check revocation by default, and don't check Certificate Transparency at all. A browser-shaped fix for a non-browser-shaped ecosystem leaves the interesting half of your infrastructure exactly where it was.
• The name is attested; the bytes are not. Also on the front page: LiteLLM 1.107.0 on PyPI shipped a credential stealer and backdoor (428 points). The package name was right, the maintainer account was right, the version resolved cleanly, and pip install did exactly what it was told. Every signature in that chain could be perfectly valid and you still get a backdoor, because the thing you attested was identity, and the thing that hurt you was content.
• The attestor is your dependency. eMudhra's intermediates were cross-signed by Sectigo's root in May 2025 — so one weak anchor got a second, stronger-sounding path into the trust store. Whoever certifies you is inside your trust boundary, inherits your blast radius, and can be the weakest link in a chain that looks short. Attestation doesn't remove trust; it relocates it and hides the address.

What actually helps

The fix is not "trust less." It's to stop treating a badge as a fact you own.

• Verify the property, not the paperwork. The eMudhra keys were recoverable by hand. If an anchor matters, spend the hour: check the key, check the entropy source, check the ceremony notes. Any anchor you can't re-derive is an anchor you're taking on faith, and faith is not a control.
• Assume breach for anything upstream of you. Trust anchors, base images, build runners, and the CA bundle are all "already compromised, question is when." Design so that the answer doesn't change your week.
• Pin bytes, not versions. Lockfiles with hashes, a private mirror, and a rule that a dependency bump is a reviewed code change. A version number is a claim; a hash is a fact.
• Ship your own trust bundle to non-browser clients. Turn on revocation checking where it's off by default. Monitor CT logs for certificates chaining to your anchors. It is unglamorous work that only matters on the day it matters completely.
• Treat attestations as versioned claims. Who attested, against what, on what date, expiring when, and who owns the renewal. "We're SOC 2 certified" without a date is a sentence about the past tense of a company you no longer are.
• Measure time-to-rotate, not time-to-detect. Detection is the easy half. The number that predicts your bad day is how long it takes to swap an anchor out of every client you've ever shipped.

The uncomfortable trade

Attestation is the layer everyone outsources because it is boring, and boring is precisely the product. You are buying someone else's diligence at the exact moment you stop looking — and the failure mode is not that they were malicious. It's that a key generator was called with the wrong argument, in April 2025, and every check downstream of it passed for seventeen months.

The workable position is narrow: you can outsource the audit, but you cannot outsource the assumption that the audit is wrong. Keep a short list of the anchors your business actually rests on, and for each one know what you'd do in the next hour if it evaporated.

The one-line version

An attestation tells you what shape something has, not what it's made of. Eight bits of trust passed every check in the chain.

---

Next in the series: the rotation layer — detection is hours, revocation is days, and the only number that matters is how fast you can replace a root you shipped three years ago.