You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
OSV parser drops all crates.io affected entries because the ecosystem mapping uses cargo #2485
I found that every crates.io advisory is silently dropped by the OSV parser.
In vulnerabilities/importers/osv.py, the PURL_TYPE_BY_OSV_ECOSYSTEM mapping is keyed by "cargo", but the ecosystem name in OSV data is "crates.io". The lookup lowercases the ecosystem string and finds no match for crates.io, so no package URL is built for the entry and the affected entry is skipped entirely.
I ran the parser on OSV advisories for serde and got:
F) ecosystem "crates.io", fixed version 1.0.0
-> [] (dropped)
G) ecosystem "Cargo" (not the real OSV ecosystem name), fixed version 1.0.0
-> pkg:cargo/serde with fixed 1.0.0 (works)
So the downstream path works end to end; only the ecosystem name in the mapping is wrong. This also means the cargo support that GithubOSVImporter.supported_ecosystems advertises never actually happens for real OSV data.
The fix I have in mind is to add a "crates.io": "cargo" entry to PURL_TYPE_BY_OSV_ECOSYSTEM, keeping the existing "cargo" key. Happy to raise a PR if this approach sounds right.
I reproduced this by calling parse_advisory_data with a Rust advisory for serde. With the ecosystem name that OSV actually uses, crates.io, the call returns no affected packages at all. As a control, the same advisory with the ecosystem written as Cargo returns one affected package, pkg:cargo/serde, with fixed version 1.0.0. So the downstream handling works, and the entry is lost at the ecosystem lookup.
I have a fix ready. The problem is the PURL_TYPE_BY_OSV_ECOSYSTEM mapping in vulnerabilities/importers/osv.py, which is keyed "cargo" while OSV calls this ecosystem "crates.io", and the lookup lowercases the ecosystem name before checking the mapping. My fix adds a "crates.io": "cargo" entry and keeps the existing "cargo" key, so crates.io advisories now produce pkg:cargo packages through the same path that the control case already proved. I added a regression test with a crates.io advisory that produces pkg:cargo/serde with its fixed version.
The fix is ready from my side. I will raise the PR.
Activity
Ashutosh-Panda2004 commentedon Oct 27, 2026
@TG1999 looping you in on this one.
I reproduced this by calling parse_advisory_data with a Rust advisory for serde. With the ecosystem name that OSV actually uses, crates.io, the call returns no affected packages at all. As a control, the same advisory with the ecosystem written as Cargo returns one affected package, pkg:cargo/serde, with fixed version 1.0.0. So the downstream handling works, and the entry is lost at the ecosystem lookup.
I have a fix ready. The problem is the PURL_TYPE_BY_OSV_ECOSYSTEM mapping in vulnerabilities/importers/osv.py, which is keyed "cargo" while OSV calls this ecosystem "crates.io", and the lookup lowercases the ecosystem name before checking the mapping. My fix adds a "crates.io": "cargo" entry and keeps the existing "cargo" key, so crates.io advisories now produce pkg:cargo packages through the same path that the control case already proved. I added a regression test with a crates.io advisory that produces pkg:cargo/serde with its fixed version.
The fix is ready from my side. I will raise the PR.