OSV API: "package not found" for an Alpine apk package - ecosystem naming mismatch with what the scanner sent

TL;DR

OSV's API matches packages within a named ecosystem, and its Alpine ecosystem names carry a version qualifier (like Alpine:v3.19). If your scanner sends a bare "Alpine" or a differently formatted name, OSV finds no such ecosystem and returns package not found. Normalize the ecosystem string to OSV's naming before querying, and treat anything still unmatched as unknown, never as clean.

The query

OSV API: "package not found" for an Alpine apk package - ecosystem naming mismatch with what the scanner sent

Use this when

• OSV API returns package not found for Alpine apk packages
• The same package clearly exists in Alpine's own security data
• Other ecosystems query fine from the same pipeline

Not for

• Packages that genuinely are not in OSV's data (new or obscure packages)
• OSV API 429 rate limiting (a quota problem)
• Scanner-side parsing failures before the API is even called

Steps

1. Log the exact ecosystem string you sent

Print the full request payload for a failing package: package name, version, and especially the ecosystem field.

Expected output: the literal ecosystem string, e.g. a bare "Alpine" or a distro-specific variant OSV does not list.

2. Check OSV's supported ecosystem names

Consult the OSV schema documentation for the exact ecosystem strings. Alpine entries use the version-qualified form.

Expected output: the correct string for your Alpine version.

3. Normalize in the pipeline

Add a mapping step that converts whatever the scanner emits into OSV's ecosystem names before the query is built. Cover every distro version you scan, not just the one that failed today.

Expected output: the mapping is a small explicit table, reviewed, not a clever regex.

4. Retry the failed queries

Re-run the previously failing package queries with the normalized ecosystem.

Expected output: package found, with vulnerability data returned normally.

5. Quarantine persistent unknowns

Any package that still returns not-found after normalization goes into an "unknown ecosystem coverage" bucket for manual review. Verify: the pipeline has three outcomes (vulnerable, clean, unknown), and unknown is never displayed as clean.

Variant phrasings

OSV API package not found alpine apk

The short symptom search.

OSV ecosystem name mismatch scanner

The cause-first search.

Compatibility: OSV API v1. Applies to any scanner that constructs OSV queries from distro package data.

Why it happens

Ecosystem naming is a convention, not a standard, and every tool invented its own. OSV chose version-qualified names for Alpine because Alpine's security data is versioned that way. Scanners that emit a generic distro name produce queries for an ecosystem that, as far as OSV is concerned, does not exist. The API answers honestly: not found.

Edge cases / pitfalls

• Alpine versions go end-of-life and their OSV ecosystems stop updating. A correct name with stale data is still a coverage gap; track EOL dates.
• The same mismatch pattern hits other ecosystems (Debian codenames versus version numbers, for example). Audit all your ecosystem mappings, not just Alpine.
• Do not normalize by stripping the version qualifier to "make it match". The qualifier is load-bearing; without it you query the wrong data set.
• When OSV adds a new Alpine version, your mapping table needs the new row. Review it on the same cadence as your base-image updates.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_JGvh7o-eHrD02QG3XPvPTw