CVE detection engine — correctness fixes, spec, tests, audit #2

Merged
autonomic-bot merged 10 commits from review/1-cve-engine into review/session-base 2026-08-11 19:03:53 +00:00
Showing only changes of commit 8d7320f32e - Show all commits
+9 -3
View File
@@ -48,9 +48,15 @@ keeps every weekly edition looking the same regardless of which model writes the
RCEs were reported as "none" on 2026-08-07.
- **`?` must stay RARE — it means "we tried and could not tell", not "we didn't look".** Use it
ONLY when a scan ran and reported genuinely failed sources, **or when the scan block says
COUNT UNKNOWN** (it refuses to classify across a version-scheme change, e.g. semver → calver —
discourse 3.5.3 → 2026.7.1). In that case the scan's `0` means *not determined*: publish `?`
and say so in the notes; publishing `0` would assert a clean bill of health nothing supports.
COUNT UNKNOWN**. In that case the scan's `0` means *not determined*: publish `?` and say so in
the notes; publishing `0` would assert a clean bill of health nothing supports. Note a
**version-scheme change is no longer a reason for `?`** — the scan resolves semver→calver jumps
(discourse 3.5.3 → 2026.7.1) by falling back to advisory publish dates and reports a real number.
- **Counts span every image, each judged by its own window.** A scan block lists one line per
image with its version range and classification method; the headline is their union. So a
recipe's count legitimately includes **sidecar** CVEs (discourse's 128 = 123 app + 5 redis).
When a sidecar contributes a critical/high, name the image in the bulletin — CVE-2025-49844 is
a redis flaw, not a discourse one, and an operator reading "discourse" needs to know that.
(The scan headline itself now says `UNKNOWN` rather than a number in that case.)
In particular: a recipe with **no upgrade this run** (up-to-date/skipped) has nothing an
upgrade could have fixed — report `0`, not `?`. A recipe with a clean scan reports its number (including `0`). Benign notes in a scan