advisory-scan: attribute vendor-changelog CVEs to the release that fixed them #9
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: recipe-maintainers/cc-ci-orchestrator#9
Reference in New Issue
Block a user
Found by the operator asking a good question: lasuite-docs and lasuite-drive both bump nginx — why did the scanner report no CVEs?
Because nginx publishes no GitHub security advisories at all. Its feed is empty; every nginx CVE we can see lives in
nginx.org/en/CHANGES. The scan scraped CVE ids out of that page but never attributed them to a release, so they had no patched version, could never be classified, and every nginx bump reported 0. nginx is a sidecar in most of the fleet, so this was a fleet-wide blind spot rather than a one-recipe quirk.Measured on the two PRs that prompted the question:
Matching a hand count of the changelog exactly —
CVE-2026-42055,CVE-2026-42530,CVE-2026-48142in 1.31.2 andCVE-2026-42533,CVE-2026-56434,CVE-2026-60005in 1.31.3. The narrower window correctly counts only the latter three.How: when a vendor page is organised by release, each CVE is attributed to the nearest preceding release heading (
Changes with nginx 1.31.3,## v1.31.3) and that becomes its fixed-in version. It is tied to a window by the image name appearing in the page URL (windownginx↔nginx.org/...).A changelog lists the project's entire history, so only releases the window actually crosses may count — there is a test asserting the 2013-era entries stay out, since sweeping those in would be a far worse failure than reporting 0.
76 tests. discourse 140 / gitea 2 / mailu 2 / keycloak 12 unchanged.
nginx publishes NO GitHub security advisories. Every nginx CVE we can see comes from nginx.org/en/CHANGES, and the scan scraped ids out of it without attributing them to a release - so they had no patched version, could never be classified, and every nginx bump in the fleet reported 0 CVEs. nginx is a sidecar in most recipes, so this was a fleet-wide blind spot. Measured on the two PRs that prompted the question: lasuite-docs#7 nginx 1.31.1 -> 1.31.3 0 -> 6 CVEs lasuite-drive#6 nginx 1.31.2 -> 1.31.3 0 -> 3 CVEs matching a hand count of the changelog exactly (three fixed in 1.31.2, three in 1.31.3; the narrower window correctly counts only the latter). How: when a vendor page is organised by release, each CVE is attributed to the nearest preceding release heading ('Changes with nginx 1.31.3', '## v1.31.3'), and that becomes its fixed-in version. The CVE is tied to a window by the image name appearing in the page URL (window 'nginx' <-> nginx.org/...). A changelog lists the project's whole history, so only releases the window actually crosses count - asserted by a test that the 2013 entries stay out. 76 tests. discourse 140 / gitea 2 / mailu 2 / keycloak 12 unchanged.