The findings register
The register, including the misses.
Proof is a correctness audit practice; this register is its public record. Six entries so far: dated, each publishing its own triage boundary, each saying who validated it or why the name is withheld. We publish our misses, because a record that only contains wins has been edited. And no finding count will ever be a headline here; counts are the cheapest thing an audit produces.
01 · Entry: jsonparser
The two defects that got past us.
In July 2026, two defects in jsonparser’s Set() got past our review. One silently threw away data: asked to write at index [5] of a two-element array, Set returned a one-element array — valid JSON, nil error, the rest of the data gone. The other panicked on an empty path component, the same failure class a hazard sweep had already found at seven sites and missed at the eighth. The affected code carried 100% MC/DC at the time. That is the uncomfortable part, and the reason this entry leads the register: coverage was complete and the defects got through anyway, because the proof had a gap. The blameless postmortem naming that exact gap is published in the repository, next to the findings and the fixes, where you can re-run all of it. The gate stopped neither defect, and the project’s changelog credits an outside reporter for each — the full account, including where our own records and the changelog disagree, is on public proof.
The context. jsonparser is a decade-old Go library long maintained inside the practice; it went first on purpose, as code we could not hide from. Formalizing its behavior produced 123 requirements — 7 stakeholder, 116 system — and judged against them, the review surfaced six defects on its own. Eight defect files sit on master; the two beyond the six are the outside reports, credited by name in the changelog, and they are the two published misses. The issue register shows four known-issue records, KI-1 standing for a whole panic class across several call sites. Every one of those numbers is a directory or a document in the public repository, and they are counted out object by object on public proof.
A person validated every finding in this entry before it shipped. People sign the practice’s promises and its methodology bar, and publishing a miss is a person’s decision — the postmortem itself carries no signature, and it says so.
Triage boundary · entry 01
In scope: the library’s public API, formalized as 123 requirements. Both escaped defects sat inside that boundary with full evidence attached. Nothing about the scope excuses them, which is why they count as misses and why they get the postmortem.
The full case study → The postmortem ↗ The 123 requirements ↗ The live register ↗ seeded showcase branch; read the labels first
02 · Entry: rsync
Ninety-nine findings against thirty years of C.
rsync ships on virtually every Linux system and has moved the world’s files since 1996. Proof audited it continuously through the development of rsync 3.5.0, alongside Trail of Bits, re-running the whole tripwire suite every time upstream moved. The audit filed 99 findings; the 3.5.0 security release shipped 33 security fixes, six more landed mid-development in the interim 3.4.3 security release, and the cycle carries 39 CVE IDs in all. Ten of the findings had been present since the first release in 1996.
The board keeps its own honest arithmetic: 45 findings open, 21 fixed, 28 withdrawn — the audit disproved its own findings and the board shrank — and 5 re-examined by a person and allowed to stand. The release’s 33 fixes include findings from the daemon-protocol fuzzing pass and from researchers beyond this audit, and their work is never counted as ours. Every one of the 33 carries its own entry in the release notes, and the audit is still running.
Triage boundary · entry 02
In scope: rsync’s path-handling and daemon-protocol behavior, formalized into executable tripwires and re-run on every upstream change through the release. Severity labels are ours — 13 high, 41 medium, 43 low, 2 low-medium — our assessment, weighted by reachability and impact; a starting point for the maintainers’ triage, not a CVSS determination.
03 · Entry: grpc-go
Five fixed upstream, two as our own pull requests.
google/grpc-go is the Go implementation of gRPC, a security-critical RPC framework that carries authorization and transport for a large part of the cloud. Five issues are fixed on master — two of them landed as our own merged pull requests, and two are covered by the vendor’s own published security advisories. One more fix is in review, and one issue was withdrawn by agreement as intended behaviour.
We count a finding as ours on one basis: we reported it, and it was fixed after — whoever’s name ends up on the advisory. Each of these fixes, with its public evidence, is on the public roster. Reports still working through a vendor’s process, and anything we reported privately, are not published until they are public and closed.
Triage boundary · entry 03
In scope for this public entry: the fixed, in-review and withdrawn issues, each classed at the level the roster shows. Severity and formal credit are the vendor’s to assign; where a fix carries someone else’s name, the roster still shows it fixed and says so.
04 · Entry: graphql-hive/router
Six fixed on main in the Hive router.
graphql-hive/router is a GraphQL federation router. Six issues are fixed on main, and one was withdrawn by agreement as intended behaviour. Each one is a public pull request or issue you can open.
We publish these because the work should be checkable, not because it flatters us. Every fix here is on the public roster with its evidence. Reports still open, and anything we made privately, stay off the public page until they are public and closed.
Triage boundary · entry 04
In scope for this public entry: the fixed and withdrawn issues, each classed at the level the roster shows. Reports still open are held back entirely until they are fixed and public.
05 · Entry: wundergraph/graphql-go-tools
Eight fixed on master, credited to others.
wundergraph/graphql-go-tools is the GraphQL federation engine underneath a range of production gateways. A cluster of issues we reported was fixed on master; the fixes landed as the vendor’s own pull requests and were credited to others.
This engagement also produced hardening items held off public disclosure by written agreement, and reports that are still open. Both are omitted here entirely, and this entry represents no count of either — it shows only what is fixed and public. We count a fix as ours on the same basis as everywhere else: we reported it, and it was fixed after. Each fix, with its public pull request, is on the public roster.
Triage boundary · entry 05
In scope for this public entry: the fixed, public issues, each classed at the level the roster shows. The privately-held hardening set and the reports still open are out of scope here, and no count of either is claimed.
The full roster, row by row → wundergraph/graphql-go-tools ↗
06 · Entry: enterprise API gateway
One component, and the crash class every existing test missed.
The engagement scoped one component of an enterprise API gateway. The engineers who owned the component approved 47 requirements in about two hours of their time, and the audit itself changed zero production code — it reads; it does not write. Against those requirements, the audit surfaced a nil-pointer crash class that every existing test missed. The approval step alone surfaced seven undocumented design decisions the team itself disagreed about.
The client is not named because we had not asked permission when this entry shipped. We publish names only with written approval; if permission is granted, this entry will be updated. The permission rule itself is on Trust. Because the engagement is private, none of this entry’s numbers has a public evidence route — which is exactly why it sits below the entries that do.
Triage boundary · entry 06
In scope: one component, chosen with the client and defined by the 47 approved requirements. Nothing outside that component is claimed here.
07 · What a finding is
What a single finding looks like.
Every finding in an engagement ships in one structure, and the structure is the promise: no reproducer, no finding. A finding without a runnable reproducer does not ship — the reproducer, not the signature, is its authority.
A reproducer pins the finding one of two ways: it fails until the fix lands, or it asserts the broken behavior while that behavior is live and flips when the fix lands. The record says which, and it never tells the easier story of the two. When a fix is verified, the reproducer stays in the client’s CI as a regression pin, and the defect record preserves the root cause, the severity basis and the evidence.
A real record, walked field by field → The register it comes from → What “verified” means here →
08 · Standing offer
One open-source pre-release audit per quarter, self-funded.
Coordinated with the maintainers, on their schedule. No invoice, no commercial follow-up.
This register has to earn the right to be believed, and open source is the only place it can: a client’s requirements corpus describes their product in enough detail that publishing it would publish the product, and no permission fixes that. So the public record grows one self-funded open-source audit at a time, and paying our own way keeps the entries free of anyone’s release marketing.
09 · Where next
Check the bar itself.
A register is only as good as the bar behind it. These pages hold the bar, the engagement it installs, and the evidence you can open.
Methodology
The bar we audit against, the check that enforces each clause, and a table of what the audit cannot see.
The engagement
The Continuous Correctness Audit: its shape, its five commitments, and what stays in your repository.
Life after the audit
What findings turn into after week four: register, fix loop, miss protocol.
Public proof
The jsonparser evidence, file by file: the chain, the ledger, the postmortem, the limits.
Trust
Why client names stay private until written approval, and how access works.
About
The practice behind the register, and who stands behind the promises.