Security attestations on Nostr: a public record of what has been checked

• A recent example
• The proposal
• Principles
• What it makes possible

Software security has an accounting problem. When someone analyzes a program and finds — or fails to find — a vulnerability, that knowledge rarely becomes a durable, public, machine-readable fact. It lives in a blog post, a private report, a chat thread, or a CVE that takes weeks to be assigned, if it ever is. There is no common, permissionless way to state “this exact version of this software was examined, by this method, with this result,” and to have every tool that cares be able to read it.

That gap is widening now that anyone can run a capable model over a codebase. Finding a vulnerability is cheap; the missing piece is a trustworthy, reusable, public record of what was checked and what was found.

§A recent example

In late July 2026, attackers began draining COLDCARD hardware wallets — on 30 July, roughly a thousand BTC (tens of millions of dollars) was taken from over a thousand addresses in about 41 minutes, by more than a dozen independent attackers, none of whom needed physical access to a device. The cause was a firmware defect that had shipped silently since 2021: a preprocessor check tested whether the hardware-RNG macro was defined rather than whether it was enabled — it was defined as zero — so wallet seeds were produced by a deterministic software fallback with a fraction of the intended entropy.

The account came together in public over days: user reports of stolen funds, independent researchers root-causing the defect, coverage across several outlets, and finally vendor confirmation and corrected firmware from Coinkite. Through all of it there was no CVE — a CVE needs a numbering authority to file one, and the exploitation outran that process. The facts were public; the standard registry simply wasn’t where they lived. A signed attestation could have carried the finding the day it went public, with a CVE id attached later if one was ever assigned.

Sources: Block engineering advisory · Coinkite confirms a five-year-old flaw (Blockhead) · the theft (BleepingComputer) · The Hacker News

§The proposal

A single signed event type — one record, one signer, one immutable snapshot of code — that states the presence or absence of vulnerabilities. Anyone can produce them: an automated scanner, an agent running a fixed prompt, a human auditor. Anyone can read and display them. Nostr carries them: signed, permissionless, with no authority deciding who may attest or on what schedule. The wire format is defined in the companion NIP (kind 8443).

§Principles

• Producer-agnostic. A scanner, an agent and a human auditor are equal citizens. No one owns the namespace, and no gatekeeper decides whose findings are allowed to exist.
• Schedule-agnostic. Each producer follows its own disclosure policy — immediate, or a staged commitment now with detail released later. The format imposes no timeline.
• The signer bears the claim. An attestation is signed by whoever made it, and that signer carries responsibility for it. A tool that merely displays attributed, signed attestations by others is a conduit, not the publisher — which is what lets any tool surface findings without owning them.
• Honestly scoped. A model’s output is not deterministic, so naming the model that produced a result is provenance, not proof. The trust anchor is the signer plus a finding anyone can re-check against the public code — never the model label alone.
• CVE-compatible, not CVE-dependent. A record stands on its own the moment it is signed; a CVE id is added later if and when one is assigned. Existing CVE records map cleanly onto the same format.
• Trust is the reader’s choice. How to weight signers, how many independent producers make a result convincing, and what to show a user are decisions for whoever consumes the records — not properties baked into the wire.

§What it makes possible

• A public, versioned record of what has and has not been examined — including the telling absence of any record for a given project or release.
• Corroboration: independent producers, using different methods, converging on — or disagreeing about — the same code.
• A maintainer’s track record: how promptly reported issues are fixed, derivable from the sequence of records over time.
• Findings that become public knowledge by default, so discovery stops implying a private, weaponizable secret.