SECOND MEASUREMENTS
Registry
One row for each public promise an organisation made about itself that we have measured, checked and found holding, or listed to measure next. The state is ours; the sentence is theirs. Rows link to the paper, the null row or the backlog entry that carries the evidence.
| State | Who | The claim | What we found | Clock · recheck |
|---|---|---|---|---|
| did not hold | CNA 72-hour rule | CNA 72-hour rule: four CNAs late on two records in three | 1,816 of 13,871 records late (13.1%). ZDI 77%, Dell 49%, Drupal 82%, Arista 86%; Microsoft 0.5%. Sent, awaiting reply | 30 days left · rechecked 2026-10-11 |
| did not hold | FCC and its broadcast licensees | FCC public-file lists: one in ten late in 2025 | 6,070 of 59,842 lists late across 18,043 stations; 3,231 over a month late. Published; FCC asked 14 Oct | questions go with the 14 October read · rechecked 2026-10-10 |
| did not hold | EPA (Toxics Release Inventory) | Toxic-release reports: a thousand plants a year late, 61 EPA cases | 5,964 of 473,709 forms over a year late; EPA actions fell from 52 a year to 16. Sent, awaiting reply | 22 days left · rechecked 2026-10-03 |
| did not hold | Chrome CT policy | Chrome CT policy: logs include within the MMD, RFC 6962 MMD at most 4 h, shard windows at most a year; Apple: “usable” logs can be relied on | 64 of 64 logs inside their MMD, tiled ones under 6 s; Chrome’s list declares 24 h against a 4 h policy, admits four 380-day shards; Apple’s list marks 12 closed shards usable, untouched since March Sent to Apple and Chrome 3 Oct 2026 | 21 days left · rechecked 2026-10-12 |
| did not hold | RPKI | RPKI: Brazil gives a member five days to fix a lapsed manifest; validators give zero | 30 members lapsed in the week to 3 October; by 8 October 20 were deleted, 10 recovered. Validators drop a lapsed member’s authorisations in the first hour; RIPE’s service still carried 34 lapsed points under 18 CAs. Sent, awaiting reply | 30 days left · rechecked 2026-10-12 |
| did not hold | CCADB | CCADB: CAs upload audit statements within 92 days; Microsoft: audits “on an annual basis” | 11 of 119 statements past the deadline, 7 with nothing on file; 24 Microsoft-trusted roots with audits over 15 months old, one from 2019 Sent to CCADB and Microsoft 3 Oct 2026 | 21 days left · rechecked 2026-10-12 |
| did not hold | Mozilla | Mozilla: CRLite’s builder has “total knowledge” of the public Web PKI; uncovered certificates are “likely new certificates and private CAs” SM-011 ● | Three of the largest logs read to June, June and August; 68 of 726 top-site certificates not covered, up to 50 days old, from Google, DigiCert and Microsoft; 57 of the 68 were issued by Google Trust Services Sent to Mozilla 2 Oct 2026 | answered in 3 days · rechecked 2026-10-12 |
| did not hold | Hugging Face | Hugging Face: every file in every repository goes through a malware scanner at each commit | Every file under 2 GiB scanned (2,539 of 2,551); none at 2 GiB or more (0 of 487); 476 of them badged “safe” Sent to Hugging Face 2 Oct 2026 | 20 days left |
| did not hold | Mozilla | Mozilla: CRLite stores all certificate revocations locally; Firefox enforces it and skips the online check for what it doesn’t cover SM-009 ● | 38 of 465 current revocations missing; 37 of 108 among certificates revoked within a day of issuance, for up to 28 days Sent to Mozilla 2 Oct 2026 | answered in 3 days; next full filter 17 October · rechecked 2026-10-12 |
| did not hold | CISA | CISA: SSVC answers for every CVE ID | 1 of 158 kernel CVEs since March Sent 2 October; six questions open | 20 days left · rechecked 2026-10-12 |
| did not hold | Docker | Docker: signed attestations for all Official Images | Attestations on 99.9% of Linux images; none signed Sent 2 October; seven questions open | 20 days left · rechecked 2026-10-12 |
| did not hold | Meta | Meta: the pulled-software list is published every 3 hours | Every 6 hours since January; whitepaper unchanged No reply yet | 19 days left · rechecked 2026-10-12 |
| did not hold | Wild SBOMs are written by many practitio | Wild SBOMs are written by many practitioners | Nearly half came from one automated run One author replied; no correction yet | 18 days left |
| did not hold | AIDev captures each coding agent’s pull | AIDev captures each coding agent’s pull requests | Its Claude Code search catches about 1 in 11 No reply yet; two other teams have since reached the same result | 18 days left |
| did not hold | Google: the Pixel log covers every factory image from Pixel 6 on SM-001 ● | January 2026 (29 images) missing for eight months Google confirmed and fixed it within a week | fixed in 7 days; daily recheck at 0 missing · rechecked 2026-10-11 | |
| not tested | x402 payment counts on Base | x402 payment counts on Base | Our count reproduced; traffic fell three-quarters No reply yet | 19 days left · rechecked 2026-10-01 |
| held | Charity Commission for England and Wales, annual report 2024 | Charity Commission for England and Wales, annual report 2024–25: “92% of charities were up to date with filing at the end of 2024-25. This represents a significant recovery from 2023-24 (81%)” | Received by the due date: 81.8% of 67,689 for the 2023 cycle, 91.4% of 71,433 for 2024, 92.6% of the 52,663 due so far for 2025. The Commission’s numbers hold. By income the on-time share is 95%; the late ones are late by a median 45 days, and 408 charities with income over £1 million filed late for 2024, the British Council (56 days) and the Salvation Army (112) among them. The extract carries no row for a return never filed, so non-filers are invisible here. | |
| held | CCADB incident-report rules | CCADB incident-report rules: open reports “MUST be updated: on or before the ‘Next update’ date in the Whiteboard field”, and CA Owners “MUST respond within 7 days” to comments and questions (ccadb.org/cas/incident-report) | 24 reports carry a Next-update date; none is past it without a CA update. No question from a root program or the community has waited more than 7 days for a CA reply. Two flags on first pass were an administrative note and a community thread with a scheduled date. The rule polices itself: one open report is Microsoft PKI Services filing an incident for having missed its own seven-day update on another. | |
| held | CA/Browser Forum Baseline Requirements 4.9.7 | CA/Browser Forum Baseline Requirements 4.9.7: a CA issuing subscriber certificates “MUST update and publish a new CRL at least every seven (7) days”; the CRL profile caps nextUpdate at “at most 10 days after the thisUpdate” for CRLs covering subscriber certificates | 15,982 CRLs covering subscriber certificates: median 3 hours old, 99% under a day; median validity 7.0 days, 90th percentile 9.96 days against a 10-day cap. Not one TLS CRL is stale or expired. The five over seven days old are timestamping, qualified-signature and legal CAs the CCADB marks with a server-authentication bit, plus one real one: Brazil’s ITI, trusted by Microsoft alone, serves an EV CRL whose nextUpdate was 24 March 2023, 54 entries, three and a half years stale. | |
| held | GitHub | GitHub: “Public repositories that generate artifact attestations use the Sigstore Public Good Instance. A copy of the generated Sigstore bundle is stored with GitHub and is also written to an immutable transparency log that is publicly readable on the internet.” | Every Actions-generated attestation is in the log: 161 of 161 found on Rekor at the stated index. The other 227 bundles are GitHub’s own release attestations, which come with immutable releases: signed by GitHub’s certificate authority with a one-year certificate, timestamped by GitHub, and in no public log. GitHub’s release documentation doesn’t claim one; the sentence above is about the first kind. A verifier of an immutable release is trusting GitHub alone. | |
| held | CVE Program, CNA Operational Rules 4.5.1.4 | CVE Program, CNA Operational Rules 4.5.1.4: a CNA “MUST publish a CVE Record to the CVE List within 72 hours of Publicly Disclosing a CVE ID” | For GitHub’s own CNA, 336 of 336 records were published before the advisory that discloses them, by a median of 26 hours, so the rule holds there by construction. The same is true of VulnCheck (288), OpenJS (84) and HeroDevs (24). The rule is only measurable where a CNA announces first and files later. | |
| held | SEC Rule 16a-3(g) | SEC Rule 16a-3(g): an insider’s Form 4 “must be filed before the end of the second business day following the day on which the subject transaction has been executed”; Regulation S-K Item 405: the proxy must name anyone who filed late | 2,531 forms filed after day two, 279 after day five, across 116 issuers. 188 of the 214 proxies with the section name their late filers, down to a five-share trade. Reading the 279: most of the rest are exempt transfers, plan purchases or inheritances. Two omissions survive: an AutoZone director’s $1.08M sale reported 303 business days late with a proxy that carries no section, and a First Solar controller’s 560-share vest reported 122 days late, likewise. AutoZone’s next proxy is due in late October. | |
| held | Homebrew | Homebrew: homebrew-core uses Sigstore “to cryptographically attest to all bottles built in the official Homebrew CI” (2024) | 599 of 600 attested; every CI attestation carries a Sigstore transparency-log entry. The exception: ht 2.1.0’s two Monterey bottles, built 24 April 2024 and still served, which neither signer attests. Reported as homebrew-core#314985. | |
| held | NIST NVD | NIST NVD: for CVEs in CISA’s known-exploited catalogue, “our goal is to enrich these within one business day of receipt” (from 15 April 2026) | 163 of 163 within one business day. 68 had been analysed before they reached the catalogue; the other 95 took a median of 19.5 hours. | |
| held | Kubernetes | Kubernetes: “The Kubernetes release process signs all binary artifacts (tarballs, SPDX files, standalone binaries) by using cosign’s keyless signing.” | 408 of 408 carry both; 12 of 12 signatures verify, all from the release identity Kubernetes documents. Certificate chain and transparency-log entries not checked here. | |
| held | Proton Mail key transparency | Proton Mail key transparency: “Normally a ProtonKT epoch should be published every 4 hours. The maximum publishing interval is 72 hours” (whitepaper, p. 14) | 515 epochs, 4 July to 2 October: median interval 4.00 hours; longest 38.1 hours (27–28 September), inside the 72-hour limit. Two epoch numbers at the start of the window aren’t visible, probably expired from the search index. | |
| held | Every Certificate Transparency log promises a maximum merge | Every Certificate Transparency log promises a maximum merge delay: 24 hours for the classic logs, 60 seconds for the tiled ones (the mmd field of the Google and Apple log lists; RFC 6962 §3) | 64 of 64 inside the promise. Tiled: all 43 within 6 seconds, most within 1. Classic: DigiCert 10 seconds, Google and Sectigo 1 to 2 minutes, TrustAsia 2.5 minutes, Cloudflare’s Nimbus 46 and 61 minutes, the only logs that publish a new tree head less often than every minute. The 24-hour figure Firefox’s revocation filter waits on (SM-009) is a thousand times what the slowest Google log took. | |
| held | Debian release team | Debian release team: “Since yesterday, we have enabled our migration software to block migration of new packages that can’t be reproduced or existing packages (in testing) that regress in reproducibility” (debian-devel-announce, 10 May 2026) | 457 are unreproducible. 128 were there before the gate; 231 replaced a version that was already unreproducible, which the rule allows; 76 carry a public release-team hint; 10 got their verdict after crossing. The last 12, all petsc, are the gate working: britney flagged them in June, the release manager judged them renamed rather than regressed, and waved them through on the record in #1135890. 0 unexplained. | |
| held | A Large-Scale Dataset of MCP Implementations on GitHub (MSR | A Large-Scale Dataset of MCP Implementations on GitHub (MSR '26) describes real-world MCP development | Every repository has at least 50 stars, a cut the paper doesn't state; that is 4.3% of matching repositories. Python and TypeScript lead on both sides of it, and no owner holds more than 1%. | |
| held | PyPI | PyPI: “17% of all uploads to PyPI in the last year included an attestation”, and more than 20% came via Trusted Publishing (2025 in review) | 17.9% of uploads carry an attestation (95%: 15.1–20.8%). Of the files still on PyPI, 20.5%, which is also a floor on Trusted Publishing. 178 of 179 come from GitHub. | |
| held | Same Name, Different Server (arXiv 2609.14119) | Same Name, Different Server (arXiv 2609.14119): 4.2% of multi-version servers in the official MCP registry moved their endpoint to a different host while keeping their name, which the registry “cannot distinguish” from a takeover | 418 of 10,402 (4.02%) to the end of August. Of the 135 whose name is tied to a verified domain, 116 stayed with that domain’s owner. 283 of the 418 are named after a GitHub account, where the registry checks no domain at all. | |
| held | Never Emitted (arXiv 2609.33099) | Never Emitted (arXiv 2609.33099): GitHub shows who reported each vulnerability on its advisory but leaves that credit out of the CVE record and its OSV file | 0 of 150 CVE records and 0 of 150 OSV files carry credits; all 150 CVE records carry metrics and problemTypes. | |
| held | Every entry in the Armored Witness production firmware log n | Every entry in the Armored Witness production firmware log names the source it was built from | 27 of 28 match the v-prefixed release tag. The recovery image's commit is on usbarmory/armory-ums master, but no 0.1.0 tag exists there or in any fork. | |
| held | Cloudflare's Plexi auditor has verified every WhatsApp key-t | Cloudflare's Plexi auditor has verified every WhatsApp key-transparency (v2) epoch from 722,677 to its reported last verified epoch | 150 of 150 retrievable and consistent. | |
| held | whisper.online’s ledger proves nothing w | whisper.online’s ledger proves nothing was changed SM-004 ● | Every proof checked; we found a duplicate-update bug Operator confirmed and fixed the bug | fixed in 4 hours |
| not yet measured | Mozilla Root Store / CAs disclosing CRLs in CCADB | “For end entity certificates, CRLs MUST be updated and reissued at least every seven days, and the value of the nextUpdate field MUST NOT be more than ten days beyond the value of the thisUpdate field.” source | HEAD every disclosed CRL URL for size and drop the very large ones; GET the rest (Mozilla puts it at ~3,000 active CRLs totalling ~300 MB, so under the 1 GB budget); parse thisUpdate/nextUpdate; flag age >7 days, window … | |
| not yet measured | Cloudflare (as Signal key-transparency auditor) | “Cloudflare acts as an auditor of Key Transparency Logs to ensure the transparency of end-to-end encrypted messaging public keys. Cloudflare provides an API for anyone to monitor the verification work we perform, and verify the state of its associated Logs loca…” source source 2 | Confirm no Signal namespace on Plexi or any other public Cloudflare endpoint; read the Signal and Cloudflare docs for a stated monitoring path. If one exists, run the WhatsApp-style 150-epoch sample. ~30 min. | |
| not yet measured | Python Software Foundation (CPython releases) | “Starting with the Python 3.11.0, Python 3.10.7, Python 3.9.14, Python 3.8.14, and Python 3.7.14 releases, CPython release artifacts are additionally signed with Sigstore. ... Starting with Python 3.14, Sigstore is the only method of signing and verification of…” source | Every release directory at or after the stated cut-ins: list artifacts, check for a .sigstore bundle per artifact, and sigstore-verify a 10% sample against the release manager's identity. ~40 min. | |
| not yet measured | Google Chrome CT policy / tiled CT log operators (Google, Let's Encrypt, Geomys, IPng, TrustAsia) | “static-ct-api logs must not specify a MMD greater than 1 minute and RFC 6962 logs must not specify a MMD greater than 4 hour. ... Incorporate a certificate for which an SCT has been issued by the log within the MMD.” source | Poll every usable tiled log's checkpoint every 5 s for 24 h; for each newly covered entry, read its timestamp from the data tile and compare with the first observation of a checkpoint covering it. Count entries over 60 s… | |
| not yet measured | GitHub (npm registry) | “Packages published to the public npm registry are signed to make it possible to detect if the package content has been tampered with.” source | 2,000 versions sampled across publish years (random package names from the replicate changes feed): is dist.signatures present, and does it verify over '<name>@<version>:<integrity>' with the key valid at publish time? ~… | |
| not yet measured | NVIDIA (NGC Catalog) | “NVIDIA has been signing all NVIDIA-published models in the NGC Catalog with the OpenSSF Model Signing (OMS) specification since March 2025.” source | Enumerate public org=nvidia models; for versions created on or after 2025-03-01, count isSigned=false. Download and verify ~20 small signed versions with model_signing and NVIDIA's cert. ~1 h, keeping downloads well unde… | |
| not yet measured | NVIDIA (Attestation RIM service) | “Centralized Repository: Provides a single, authoritative source for all NVIDIA GPU reference integrity manifests, eliminating the need for organizations to maintain their own local repositories.” source | For Hopper (GH100) and Blackwell (GB100/GB200) data-center drivers released since CC support began: does NV_GPU_DRIVER_<product>_<version> exist? Fetch and verify the signature on a sample. ~45 min. | |
| not yet measured | Google Cloud (Confidential VM firmware) | “Every firmware measurement possible on Google Compute Engine should be accounted for with an endorsed measurement ... Google publishes its production virtual firmware binaries for transparency.” source | List the whole bucket. For each endorsement, decode the VMGoldenMeasurement, check that the referenced .fd exists and its SHA-384 matches, and verify the signature chain. Each firmware is 2 MiB; expect <1 GB. ~1 h. | |
| not yet measured | Microsoft (nuget.org) | “(Live index) "allRepositorySigned": true — (spec) If the boolean is set to true, all packages available on the source must have a repository signature produced by one of the signing certificates mentioned in signingCertificates.” source source 2 | 1,000 package versions sampled uniformly across catalog pages 2013-2026: range-read each nupkg's central directory, extract .signature.p7s, and check for a repository countersignature from one of the three listed certs. … | |
| not yet measured | GitHub (npm provenance) | “If you use trusted publishing, provenance attestations are automatically generated for your packages without requiring the --provenance flag. ... The transparency log service provides a public, verifiable, tamper-evident ledger of signed attestations.” source | 500 recent versions that carry dist.attestations: does each bundle's tlog entry exist at its logIndex with a matching body hash and a valid inclusion proof against a fresh checkpoint? Separately, for versions published v… | |
| not yet measured | Sonatype (Maven Central) | “One of the requirements for publishing your artifacts to the Central Repository, is that they have been signed with PGP.” source | 1,000 artifacts stratified by publish year (2015-2026): check .asc on the jar and pom, and verify a sample against keys from keys.openpgp.org/keyserver.ubuntu.com. ~1 h. | |
| not yet measured | Sigstore (Rekor v2 public-good instance) | “Rekor v2 also will provide stronger security guarantees that the log remains append-only by integrating witnessing directly into Rekor. This will be implemented soon” source | Poll checkpoints for 24 h: what share are cosigned and by which witnesses? Are the witness keys and an M-of-N policy distributed in TUF as the spec says? Do fresh bundles carry cosigned checkpoints? ~24 h passive. | |
| not yet measured | Chainguard | “Chainguard signs every container it builds, along with the attestations that describe it. ... Every container also ships with a signed SBOM. / SPDX: https://spdx.dev/Document ... Available on all images.” source source 2 | All free cgr.dev/chainguard images: for each per-arch digest of :latest, check for .sig and an SPDX attestation, and cosign-verify a sample against the release workflow identity. ~30 min. | |
| not yet measured | F-Droid | “There is no final statistic as apps builds change with each cycle, but currently we see about 68% reproducible builds.” source | All apps' latest versions in index-v2: share with a successful verification-server result. ~30 min. | |
| not yet measured | Sigstore (Fulcio public-good CA) | “The certificate authority will submit certificates to a CT log, and the signing client will submit payload metadata to the Rekor transparency service.” source | 500 random Rekor entries with Fulcio certs: rebuild the precert leaf from the embedded SCT and look up inclusion in ctfe 2022. ~1 h of build. | |
| tripwire | IANA (root zone KSK) | “Rollover — 11 October 2026 — The successor key is scheduled to sign the zone; the current key will not sign the zone.” source | Hourly: which key tags sign the root DNSKEY set, from two resolvers and one root server; binary on the day. tripwire running | |
| dead | NHTSA / vehicle manufacturers | “The notification to owners ... shall be furnished ... within a reasonable time after the manufacturer’s determination ... not more than 60 days” (49 CFR 577.7). source | Recall flat file: owner-notification date minus report-received date. dead: the file’s notification date is the latest letter, not the first, so lateness can’t be read from it |
● marks a paper whose counterpart replied or fixed the finding and got a seal. Clocks count 30 days from the day we sent our questions. Data: registry.json.