Lighthouse

Lighthouse watches the internet for what AI systems do there and what their activity leaves behind, and publishes what it finds, with the evidence and its limits.

Studies LH032

LH032 measurement amendment, 23 October 2026, after baseline outcomes

Protocol 0.1 and its original outcomes remain unchanged in their retained files. Version 0.2 repairs the measurement after an independent audit: use the captured head's first-parent ancestry for successive generated-list states, pin the revision explicitly, reject overwrites/colliding identities/malformed rows, parse escaped Markdown delimiters and retain notes/full links and last-change clocks for all measured fields. Reconcile the selected head against source fragments and the compiled SPDX at individual package/status/version level. Counts and any field-clock claims must identify the instrument version. Reprocessing the same head is a derived audit, not an extra daily read.

The mainline clock is a committer timestamp attached to the captured history. It is neither a measured public first appearance nor a vendor release, and historical generated tables can lag JSON source edits. Source statuses are checked per package, not validated by equal totals alone. An inventory entry can be a runtime component, library or tool as well as an application or appliance. A product rename can change the supplier/product key; multiple scoped entries may refer to one product.

The late advisory sample rule and its prior knowledge were written and committed in review/plan.md before page reads. The actual four-request check did not follow its case-insensitive sort and remains explicitly incomplete (review/advisory-check-2026-10-23/findings.md). Preserve its actual selection and raw responses. No additional request repairs that historical deviation.

LH032 measurement amendment, 2 November 2026, after outcomes were seen

Made after outcomes were seen. Written on 2 November 2026, after the day's read had stopped at the head and after the list's own statistics at that head (929 tracked, 240 "Runtime-dependent") had been read. Instrument version 0.2 becomes 0.3 (analysis_version in each summary). Reads made under 0.2, including the partial read of 2 November pinned to 640dcb0a9b72, remain unchanged in their retained files.

What changed in the list. Since mainline commit c005d3d (2 November 10:43:29 UTC+1, 09:43 UTC), NCSC-NL's generated tables carry a sixth status. At head 60d6616dbbe3 the list's software/README.md defines it as: "Runtime-dependent | The product/component has no direct VEX assertion; assess the linked supplied or containing PHP runtime/deployment." Its tools/README.md adds: "Runtime-dependent is a presentation status derived from hasProvidedDependency, hasOptionalDependency, or containment beneath the PHP runtime family; it is not an SPDX VEX status and does not propagate affectedness or fixedness automatically." Each such row's note reads "Runtime-scoped: assess the linked PHP runtime or deployment; no direct product VEX status is asserted."

The rule. "Runtime-dependent" is a status of its own, in the list's words, counted beside Investigation, Vulnerable, Fix, Workaround and Not vuln and never merged into any of them, nor into a combined "unresolved" or "resolved" class. It is not an assessment of the product: it says only that the list asserts no status for the product and points to the runtime. The verifier reproduces it from the source fragments, independently of the list's code, as the list documents it: for each tracked CVE with no direct VEX relationship, a package gets "Runtime-dependent" if it is the source of a hasProvidedDependency or hasOptionalDependency relationship or is contained, at any depth, beneath the PHP runtime family package (urn:php2shell:inventory:package:PHP-0037, "PHP core and Zend Engine"). A direct VEX relationship always takes precedence. The per-package reconciliation against the Markdown tables is otherwise unchanged, so a table that showed any other status where the source implies "Runtime-dependent" still stops the analyser. The timing measures (first Fix or Not vuln record) are unchanged, because the new status is neither.

Reading the series across the change. An entry that moved from Investigation to Runtime-dependent was relabelled by the list, not assessed: no vendor or upstream source was recorded for it, and it is neither a fix nor a not-affected finding. The fall in Investigation counts across c005d3d is therefore not resolution, and a count of entries "leaving Investigation" or an Investigation share must say how many left for Runtime-dependent. Investigation counts before and after the change are not comparable without that subtraction; Fix, Vulnerable and Not vuln counts are comparable as before. The 30-day comparison reports Runtime-dependent as its own row from the first read that shows it. "Entries ever changing status" under 0.3 counts the relabelling as a change and so rises on that account alone; it is reported with that caveat.

Check of backward compatibility. Under 0.3 the verifier reproduces exactly the per-CVE status counts and source hashes retained for every earlier read head (2fdc314ded28, 3b68e919dd24, 1d605e33471f, 28caa84cd7b0, 0ae7abbd5a72, 640dcb0a9b72); no earlier read changes. The head 60d6616dbbe3 of the 2 November read was reprocessed under 0.3 as a derived audit, not a new read, in data/read-2026-11-02T1526Z/head-audit/.

From studies/LH032/amendments.md in the repository, last changed 2 November 2026.