BACKLOG
Claims we haven’t measured yet
Every paper on this site starts from a sentence an organisation published about itself. These are the sentences we have found, quoted from the source and checked to be theirs, that nobody has recomputed yet. 16 are open. Each has a second path we could take written beside it. If you measure one before we do, tell us and we will link your work instead of writing our own; if you know a claim that belongs here, the tip line is at the bottom of the index.
| Who | What they said | How it could be checked | Status |
|---|---|---|---|
| Docker | “We are committed to providing a complete and accurate SBOM and detailed build provenance as signed attestations for all Docker Official Images.” source | For the :latest tag of every DOI repo (~170) plus 5 random older tags each: per platform, is there an SBOM and a provenance attestation, and is either one signed (DSSE media type, cosign .sig/.att tag, referrer signature… | measured · the paper |
| CISA | “Starred (*) are elements CISA provides to the CVE database through CISA's Vulnrichment Program for every vulnerability with a CVE ID. / CISA publishes answers to KEV Status, Exploit Automation, and Technical Impact for every CVE ID through services such as the…” source | (a) All 1,731 KEV CVEs: SSVC present in a CISA-ADP container? (b) Uniform sample of 1,000 CVEs published 2026-06-10..2026-09-25 (aged >7 days): share with all three SSVC decision points, and lag from datePublished to ADP… | measured · the paper |
| NIST (National Vulnerability Database) | “Starting on April 15, 2026, we will prioritize the following CVEs for enrichment: CVEs appearing in CISA's Known Exploited Vulnerabilities (KEV) Catalog - Our goal is to enrich these within one business day of receipt” source | Every KEV addition from 2026-04-15 to 2026-09-30 (about 250): business days from KEV dateAdded to the first NVD enrichment event (CPE configuration / CVSS by NIST / 'Initial Analysis'). Without an API key, 5 requests per… | measured · null row |
| Hugging Face | “We run every file of your repositories through a malware scanner. Scanning is triggered at each commit. ... It can take up to a few minutes to be scanned.” source | 400 repos last modified more than 1 hour ago (stratified: 200 recent, 200 random older) plus 100 datasets: count files whose avScan status is unscanned, queued or error. ~1,000 API calls, ~30 min. Light request rate, no … | measured · the paper |
| 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 … | open |
| Mozilla (Firefox CRLite) | “Firefox stores this encoding locally, updates it every 12 hours, and queries it privately every time a new TLS connection is created. ... Firefox's CRLite implementation uses half the bandwidth, updates twice as frequently, and includes all revocations.” source | (a) Cadence: the changeset only keeps ~30 days, so poll forward for 30 days and log gaps >13 h. (b) Coverage: draw 500 revoked serials from CCADB CRLs whose certs are CT-logged and unexpired, query the current filter loc… | measured · the paper |
| Debian release team | “Aided by the efforts of the Reproducible Builds project [1], we've decided it's time to say that Debian must ship reproducible packages. Since yesterday, we have enabled our migration software to block migration of new packages that can't be reproduced [2] or …” source | Source packages that entered or updated in testing (forky) after 2026-05-09 on amd64 and arm64: rebuilderd status of the migrated version. Count BAD or never-tested versions that migrated anyway. ~1 h. | measured · null row |
| Kubernetes (SIG Release) | “The Kubernetes release process signs all binary artifacts (tarballs, SPDX files, standalone binaries) by using cosign's keyless signing.” source | Latest patch of each minor v1.26..v1.37 plus 3 random older patches each: list every binary, tarball and SPDX file from the SBOM, HEAD the .sig/.cert, and cosign verify-blob a 10% sample against the documented identity. … | measured · null row |
| 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 | 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. | open |
| 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. | open |
| CVE Program (CNA Operational Rules) | “4.5.1.4 CNAs MUST publish a CVE Record to the CVE List within 72 hours of Publicly Disclosing a CVE ID assigned by the CNA.” source | Collect CVE IDs cited in public advisories from 3 large CNAs' own feeds (Microsoft, Apple, GitHub) over 90 days; compare advisory publication time with CVE datePublished; count >72 h. ~2 h. | measured · null: all 336 of GitHub’s recent CVE records were published before the advisory that cites them, so the rule holds by construction there |
| CISA | “Q: How quickly does CISA update the KEV Catalog after identifying a new in-scope vulnerability? A: CISA aims to update the KEV within 24 hours.” source | For vendor-flagged in-the-wild CVEs since 2026-06-10 (Microsoft, Apple, Google): lag from vendor flag to KEV dateAdded. ~1 h. | measured · the paper |
| 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… | open |
| 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? ~… | open |
| Proton (Proton Mail Key Transparency) | “Normally a ProtonKT epoch should be published every 4 hours. The maximum publishing interval is 72 hours; after that the server is considered to be misbehaving.” source | Pull every epoch certificate: check epoch-ID continuity, the issuanceTime interval distribution (mean vs 4 h, max vs 72 h), notBefore within 24 h of issuanceTime, and >=2 SCTs from distinct operators. ~30 min. | measured · null row |
| 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… | open |
| 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. | open |
| 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. | open |
| 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 | 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. … | open |
| 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… | open |
| 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. | open |
| 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. | open |
| 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 | 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. | open |
| 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. | open |
| 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. | open |
| Debian | “Progress on securing our distribution against supply chain attacks: The Debian testing/trixie release on amd64 is now reproducible for over 95%, and counting.” source | Recompute the GOOD share for the trixie amd64 binary set from the rebuilderd API, by source and by binary package (the denominator choice matters). ~20 min. | measured · null row |
| EPA (Toxics Release Inventory) | “Each report under this section for activities involving a toxic chemical that occurred during a calendar year at a covered facility must be submitted on or before July 1 of the next year.” source | Envirofacts carries the original postmark on every form. Count forms postmarked after 1 July for 2019 to 2024; join the late facilities to EPA’s own EPCRA 313 enforcement cases in ECHO by registry ID. ~25 min of downloads. | measured · paper in review |
| FDA / ClinicalTrials.gov sponsors | “Clinical trial results information ... must be submitted no later than 1 year after the primary completion date.” FDA, 13 Apr 2026: letters to “more than 2,200 companies and researchers” seeking “voluntary compliance”. source | Pull every interventional study with primary completion since 2017 from the registry API; join to Oxford’s FDAAA tracker; count late results landing per month before and after the 30 March letters; read FDA’s own notice page. Pitfall: the API only fills the submit date once results post. | measured · data and scripts; letters moved about 1% of overdue trials |
| SEC (insiders of S&P 500 issuers) | “Form 4 must be filed before the end of the second business day following the day on which the subject transaction has been executed.” Proxy Item 405: companies must name late filers. source | From EDGAR’s submissions feed, every Form 4 of each issuer’s latest fiscal year with its transaction and filing dates; read each proxy’s Item 405 and check whether it names the filers EDGAR shows late. ~2 h. | measured · null: 34,490 forms, 279 more than five business days late; the proxies name them, two exceptions, both small |
| 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 |
| 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 |
Compiled 2 October 2026 from each organisation’s own pages; quotations were verified against the source on that day. “Measured” links to the paper or null row that took the claim on. Order is our estimate of how much rests on the claim and how far it might be from the truth, and it changes.