advisory-scan: NVD by CPE, so mattermost and mumble stop scanning as '?' #11

2026-08-11T22:17:12Z

autonomic-bot commented

2026-08-11 22:17:12 +00:00

Two recipes could not see CVEs at all: mattermost-lts (empty GitHub advisory feed, security bulletins rendered client-side so a text sweep finds nothing) and mumble (nothing published anywhere the registry points). Both returned ? — honest, but useless.

NVD is CPE-indexed and carries structured version ranges, so it answers where the vendor does not. Declared per recipe: nvd-cpe: <image> = <cpe:2.3:...>.

scan	before	after
mattermost-lts 10.5.0 → 10.12.4	`?`	165
mattermost-lts 10.11.22 → 10.12.4 (the real PR window)	`?`	0, measured
mumble 1.3.0 → 1.6.870	`?`	2

Fleet sweep: 0 recipes with no usable CVE source, down from 2.

The measured 0 needed a new rule to be correct

My first run reported 12 CVEs for mattermost 10.11.22 → 10.12.4. That was wrong. mattermost patches every maintained line at once — CVE-2025-11794 is fixed in 10.11.4, 10.12.1 and 10.5.12 — so the upgrade crosses 10.12.1 while the deployment, at 10.11.22, was already past 10.11.4. A fix on the line you upgrade FROM was already yours, and counting it credits the upgrade with work it did not do.

That rule then broke something else, which is worth recording: it read the placeholder 7.4.X as a bare 7.4 and concluded "already fixed at 7.4", silently dropping redis CVE-2024-46981 and taking discourse 140 → 139. The rule is now skipped for placeholders — those are the indeterminate path by definition.

Caveats kept explicit

NVD lags the vendor — it had neither gitea CVSS-9.8 RCE at publication — so it is a fallback, never a replacement for an advisory feed or an attributable changelog. /cve-check now records the remedy as well as the symptom: if the sweep ever flags a blind recipe again, find its CPE and add the line.

79 tests. discourse 140 / gitea 2 / mailu 2 / keycloak 12 / plausible 6 all unchanged.

Two recipes could not see CVEs **at all**: `mattermost-lts` (empty GitHub advisory feed, security bulletins rendered client-side so a text sweep finds nothing) and `mumble` (nothing published anywhere the registry points). Both returned `?` — honest, but useless. NVD is CPE-indexed and carries structured version ranges, so it answers where the vendor does not. Declared per recipe: `nvd-cpe: <image> = <cpe:2.3:...>`. | scan | before | after | |---|---|---| | mattermost-lts 10.5.0 → 10.12.4 | `?` | **165** | | mattermost-lts 10.11.22 → 10.12.4 (the real PR window) | `?` | **0, measured** | | mumble 1.3.0 → 1.6.870 | `?` | **2** | **Fleet sweep: 0 recipes with no usable CVE source, down from 2.** ### The measured 0 needed a new rule to be correct My first run reported **12** CVEs for mattermost 10.11.22 → 10.12.4. That was wrong. mattermost patches every maintained line at once — `CVE-2025-11794` is fixed in 10.11.4, 10.12.1 *and* 10.5.12 — so the upgrade crosses 10.12.1 while the deployment, at 10.11.22, was already past 10.11.4. **A fix on the line you upgrade FROM was already yours**, and counting it credits the upgrade with work it did not do. That rule then broke something else, which is worth recording: it read the placeholder `7.4.X` as a bare `7.4` and concluded "already fixed at 7.4", silently dropping redis `CVE-2024-46981` and taking discourse **140 → 139**. The rule is now skipped for placeholders — those are the indeterminate path by definition. ### Caveats kept explicit NVD **lags the vendor** — it had neither gitea CVSS-9.8 RCE at publication — so it is a fallback, never a replacement for an advisory feed or an attributable changelog. `/cve-check` now records the remedy as well as the symptom: if the sweep ever flags a blind recipe again, find its CPE and add the line. 79 tests. discourse 140 / gitea 2 / mailu 2 / keycloak 12 / plausible 6 all unchanged.

autonomic-bot added 2 commits 2026-08-11 22:17:12 +00:00

advisory-scan: NVD by CPE, so mattermost and mumble stop scanning as '?' 985dc06e47

Two recipes could not see CVEs at all. mattermost-lts has an empty GitHub advisory
feed and renders its security bulletins client-side, so a text sweep finds nothing;
mumble publishes nothing anywhere the registry points. Both returned '?' - nothing
measured - which is honest but useless.

NVD is CPE-indexed and carries structured version ranges, so it answers where the
vendor does not. Declared per recipe as 'nvd-cpe: <image> = <cpe:2.3:...>'.

  mattermost-lts 10.5.0  -> 10.12.4   165 CVEs
  mattermost-lts 10.11.22 -> 10.12.4    0 CVEs  (measured, not unknown)
  mumble         1.3.0   -> 1.6.870      2 CVEs

Both NVD range forms are used: versionEndExcluding is a patched version;
versionEndIncluding means the fix version is unpublished but the upgrade delivers
it whenever it crosses X.

That 0 for the actual mattermost upgrade is the interesting one, and it needed a
new rule to be correct: a fix on the line you upgrade FROM was already yours.
mattermost patches every maintained line at once, so 10.11.22 -> 10.12.4 crosses
10.12.1 while 10.11.22 already had the 10.11.4 backport. Without the rule the scan
claimed 12 CVEs the upgrade did not deliver.

The rule is skipped for placeholders: '7.4.X' parses to a bare 7.4 and would read
as 'already fixed at 7.4', which silently dropped redis CVE-2024-46981 and took
discourse 140 -> 139 before I caught it.

79 tests. discourse 140 / gitea 2 / mailu 2 / keycloak 12 / plausible 6 unchanged.
Fleet sweep: 0 recipes with no usable CVE source, down from 2.

cve-check: record the remedy for a blind recipe, not just the symptom 74117c2260

The skill said to render a sourceless recipe as '?'. It now says how to stop it
being sourceless: declare an NVD CPE in the registry. That is what took the fleet
from two blind recipes to zero, and it is the first thing to try when the sweep
flags another.

autonomic-bot merged commit ab5d11ea2a into main

2026-08-11 22:17:13 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: recipe-maintainers/cc-ci-orchestrator#11