Skip to content

OSV parser drops all crates.io affected entries because the ecosystem mapping uses cargo #2485

Open

Description

@Ashutosh-Panda2004

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.

Activity

  1. Ashutosh-Panda2004 commented on Oct 27, 2026

    @Ashutosh-Panda2004
    Author

    @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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions