osv-scanner scan image reports no CVEs for alpine:3.19 musl, but Alpine's own tracker lists it as vulnerable

[mcho421]

Describe the bug

osv-scanner scan image returns no findings for musl when scanning the current alpine:3.19 image, but the installed musl-1.2.4_git20230717-r5 is listed as vulnerable to ALPINE-CVE-2026-40200 (and two other CVEs) by Alpine's own security tracker, by the OSV record itself, and by Docker Hub's image scan.

To Reproduce

1. Run the scan:

   osv-scanner scan image --format vertical alpine@sha256:6baf43584bcb78f2e5847d1de515f23499913ac9f12bdf834811a3145eb11ca1

2. Observe that no musl vulnerabilities are reported.
3. Confirm the installed musl version in the same image:

   docker run --rm alpine@sha256:6baf43584bcb78f2e5847d1de515f23499913ac9f12bdf834811a3145eb11ca1 apk list musl
   # musl-1.2.4_git20230717-r5 aarch64 {musl} (MIT) [installed]

4. Compare against:
   • Alpine security tracker: https://security.alpinelinux.org/vuln/CVE-2026-40200 (lists v3.19 fix as 1.2.4_git20230717-r6)
   • OSV record: https://osv.dev/vulnerability/ALPINE-CVE-2026-40200
   • Docker Hub scan for alpine:3.19: https://hub.docker.com/layers/library/alpine/3.19/images/sha256-45470a1b6b2bb3c200494c9caff4796ad4379e8a9090d4f664cf7f6c5052cbd6

Expected behaviour

osv-scanner scan image should report ALPINE-CVE-2026-40200 (and ALPINE-CVE-2025-26519, ALPINE-CVE-2026-6042) against the installed musl-1.2.4_git20230717-r5.

Screenshots

N/A — output above.

Additional context

The miss appears to reproduce against the OSV.dev API directly (i.e. without osv-scanner in the loop), so this may be upstream of the scanner. Sharing in case it helps triage; the analysis below was put together with help from an AI assistant and may be wrong.

# Installed version → empty
curl -sS -X POST \
  -d '{"package":{"name":"musl","ecosystem":"Alpine:v3.19"},"version":"1.2.4_git20230717-r5"}' \
  https://api.osv.dev/v1/query
# {}

# Same package, version with the `_git20230717` qualifier stripped → three CVEs
curl -sS -X POST \
  -d '{"package":{"name":"musl","ecosystem":"Alpine:v3.19"},"version":"1.2.4-r5"}' \
  https://api.osv.dev/v1/query
# returns ALPINE-CVE-2025-26519, ALPINE-CVE-2026-40200, ALPINE-CVE-2026-6042

# Older non-`_git` version also matches as expected
curl -sS -X POST \
  -d '{"package":{"name":"musl","ecosystem":"Alpine:v3.19"},"version":"1.2.3-r4"}' \
  https://api.osv.dev/v1/query
# returns the same three CVEs

Sweep across _git revisions — none match, regardless of whether they should fall inside or outside the affected range:

query version (Alpine:v3.19, musl)	matches CVE-2026-40200 (range [0, 1.2.4_git20230717-r6))?
1.2.4_git20230717-r0	no (would expect yes)
1.2.4_git20230717-r5	no (would expect yes)
1.2.4_git20230717-r6	no (correct — fixed)
1.2.4_git20230717-r99	no (correct — past fix)

Inspecting the OSV record itself, the Alpine:v3.19 entry has an ECOSYSTEM range with fixed: 1.2.4_git20230717-r6, but its affected[].versions enumeration is 223 entries long and contains no _git-qualified versions at all. ALPINE-CVE-2025-26519 (fix 1.2.4_git20230717-r5) has the same shape.

If that observation is right, it would suggest that versions carrying apk pre/post qualifiers (_git, and presumably _alpha, _beta, _pre, _rc, _p) aren't being matched against ECOSYSTEM ranges for the Alpine ecosystem — which would mean every current alpine:3.19 image is reported clean for these musl CVEs. I haven't read the importer or matcher code, so this part is a guess.