Summary
The native OSV files under osv/ in this repository appear to have been published once — a single commit on 2026-03-10 — and never regenerated, while the OVAL files (azurelinux-3.0-oval.xml, cbl-mariner-2.0-oval.xml) are updated daily. OSV.dev's importer consumes exactly that osv/ directory (their source.yaml, entry azurelinux: repo_url: https://github.com/microsoft/AzureLinuxVulnerabilityData.git, directory_path: 'osv'), so the Azure Linux:2 / Azure Linux:3 ecosystems on OSV.dev are frozen, and every OSV.dev consumer silently misses everything Azure Linux has published since the spring.
Evidence (sampled 2026-08-28)
git log -- osv on this repository: exactly one commit (1c040ad, 2026-03-10), authored by CBL-Mariner-Bot with the message "Added latest version of OSV files: 1773178605" — the phrasing suggests an automated export that was meant to recur and ran once.- OVAL: current (this repository's latest commit 2026-08-27 at the time of sampling); it contains, for example, CVE-2026-10536 (curl), CVE-2026-42250 (bzip2), CVE-2025-5278 (coreutils).
- The
osv/ files do not contain those advisories.
- Downstream effect on OSV.dev:
POST /v1/query {"package":{"name":"curl","ecosystem":"Azure Linux:3"}} returns 14 records, every one modified: 2026-04-21 (their last processing of the frozen snapshot); same for expat (12 records, same date).
Impact
Scanners consuming the OVAL directly (grype, trivy) are current; anything consuming OSV.dev's Azure Linux data is ~5 months stale. In a three-scanner differential over a digest-pinned Azure Linux 3.0 image, the OVAL consumers report 140 (package, CVE) findings — 135 of them 2026 CVEs, all with real fixed versions — that an OSV.dev-sourced scanner misses entirely.
Ask
Either regenerate osv/ on the same cadence as the OVAL (it looks like a one-time export that was intended to be continuous — OSV.dev onboarded it as a production source in April, google/osv.dev#5175), or, if the OSV export is discontinued, say so in the README and let OSV.dev know so they can point their importer elsewhere or retire the ecosystem rather than serving frozen data.
Happy to provide the full 140-finding list or any other detail.
Summary
The native OSV files under
osv/in this repository appear to have been published once — a single commit on 2026-03-10 — and never regenerated, while the OVAL files (azurelinux-3.0-oval.xml,cbl-mariner-2.0-oval.xml) are updated daily. OSV.dev's importer consumes exactly thatosv/directory (theirsource.yaml, entryazurelinux:repo_url: https://github.com/microsoft/AzureLinuxVulnerabilityData.git,directory_path: 'osv'), so theAzure Linux:2/Azure Linux:3ecosystems on OSV.dev are frozen, and every OSV.dev consumer silently misses everything Azure Linux has published since the spring.Evidence (sampled 2026-08-28)
git log -- osvon this repository: exactly one commit (1c040ad, 2026-03-10), authored by CBL-Mariner-Bot with the message "Added latest version of OSV files: 1773178605" — the phrasing suggests an automated export that was meant to recur and ran once.osv/files do not contain those advisories.POST /v1/query {"package":{"name":"curl","ecosystem":"Azure Linux:3"}}returns 14 records, every onemodified: 2026-04-21(their last processing of the frozen snapshot); same forexpat(12 records, same date).Impact
Scanners consuming the OVAL directly (grype, trivy) are current; anything consuming OSV.dev's Azure Linux data is ~5 months stale. In a three-scanner differential over a digest-pinned Azure Linux 3.0 image, the OVAL consumers report 140 (package, CVE) findings — 135 of them 2026 CVEs, all with real fixed versions — that an OSV.dev-sourced scanner misses entirely.
Ask
Either regenerate
osv/on the same cadence as the OVAL (it looks like a one-time export that was intended to be continuous — OSV.dev onboarded it as a production source in April, google/osv.dev#5175), or, if the OSV export is discontinued, say so in the README and let OSV.dev know so they can point their importer elsewhere or retire the ecosystem rather than serving frozen data.Happy to provide the full 140-finding list or any other detail.