v0.24.2 — the vendor feed that moved out from under us

Fixes #45.

If you pinned back to v0.24.0 to work around #45, that does not help. v0.24.0 is affected identically. The issue compared a scan from 2026-10-15 against one from 2026-10-16 and read the difference as a version boundary; it was a date boundary. Nothing in v0.24.1 caused this, and nothing before it was immune.

What happened

SUSE reorganised its CSAF-VEX feed into year directories on 2026-10-15. The year is not the one in the CVE id — it is the year SUSE first published the document, so the whole pre-2023 back catalogue sits under 2023/:

.../csaf-vex/2023/cve-2021-3711.json   200
.../csaf-vex/2021/cve-2021-3711.json   404
.../csaf-vex/cve-2021-3711.json        404   <- the path vexscan built

Every document 404ed. And a 404 from this feed is a real answer: it means SUSE has no record for that CVE. One CVE at a time that reading is correct; all of them at once it is an outage, and there was nothing in the response to tell the two apart. So --prefer-vendor suse stopped rating anything, in silence, and every finding fell back to its OSV-derived severity — which on a SUSE image is mostly absent. On hardened-kubernetes:v1.37.1-rke2r1-build20260924 that moved 58 findings out of CRITICAL/HIGH and out of a --severity CRITICAL,HIGH filter entirely.

This is the failure mode this tool exists to not have. A clean report has to mean something.

The fix

Document paths now come from index.txt, the feed's own listing, fetched once per provider and shared between the score pass and the verdict pass. The path is looked up rather than constructed, because it was never derivable from the id in the first place — the old scheme worked only because the feed happened to be flat.

A CVE the index does not list is declined with no request at all, so the common case costs fewer round trips than before, not more.

A feed with no index — a mirror, or an offline copy of the old flat layout — still works. That fallback is deliberately the only silent one. An index that cannot be read, including a 200 serving something that is not an index, is an error, because an unreadable index must never read as a feed with nothing in it.

The part that let it go unnoticed

preferVendorScores logged only when it had overridden something, so a pass that rated nothing said nothing at all. It now says so:

prefer-vendor: no preferred vendor scored any of the 160 CVE(s) asked about
  (every finding keeps its OSV-derived rating)

A flag that changed nothing should say so. That line is the difference between a day and a minute.

Measured

Same image, same flags, same day, against the live feed:

v0.24.0        LOW=15  UNKNOWN=145                        (0 CRITICAL/HIGH)
v0.24.1        LOW=15  UNKNOWN=145                        (0 CRITICAL/HIGH)
v0.24.2        HIGH=58  MEDIUM=18  LOW=21  UNKNOWN=63

The last row is the distribution #45 recorded on 2026-10-15, before the feed moved.

Upgrading

Anyone running --prefer-vendor suse should move to v0.24.2 directly; there is no earlier version to fall back to. Scans run between 2026-10-15 and this release under-report severity and should be re-run — the finding counts in them are correct, only the ratings are missing.