support for GIT ecosystem via rest API

[phil-hayes]

When calling the rest API with ecosystem "GIT" (or "Git") the API returns with:
{"code":3,"message":"Invalid ecosystem."}

No issues when using other ecosystems such as the PyPI sample.

Searching via the browser interface appears to support CVE's sourced from the GIT ecosystem.

Is this a missing feature in the restful API or is the deployed code servicing the restful API not up to date with all the latest CVE feeds ?

Thanks

[another-rex]

Can I ask what use case you have in mind searching with the GIT ecosystem?

Currently there is nothing to actually search for at the moment with a git ecosystem currently, as a Git repo does not have a package name, only a repo url.

If you want to know whether a specific repo has affected vulnerabilities, currently the way to do so is to do a commit query.

Something we could add is to allow you to search by repository URLs, e.g. give me all vulnerabilities for this git repo, would this help?

[phil-hayes]

Thanks for your reply Rex.

The use case is to monitor vulnerabilities for a series of specific repos used by a java application
Example library would be apache commons-compress:
https://github.com/apache/commons-compress

I understand the meta data is a bit limited, e.g.
https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2024-26308.json

How I would use this is to keep track of which CVE had been reviewed/actioned and be notified of new CVE.
If the API was able to at least return the CVE source URL which I could review manually that would work.
So I think your suggestion of allowing a repository URL would work for this simple use case.

I guess the only other consideration is whether there might need to be say a date filter on ModifiedDate to avoid an API which returns the entire history with every call.

Thanks

[another-rex]

So our intended workflow is to use either query by:

• Commit hashes:
  • No need to pass in an ecosystem, as they are globally unique
• Package name within a specific ecosystem
  • If you are looking at Java packages, you can see if it's being published as a Maven advisory: E.g. https://osv.dev/list?ecosystem=Maven&q=org.apache.commons%3Acommons-compress
  • These entries are manually reviewed by GitHub and natively published as OSV advisories.

This way you don't need to filter by ModifiedDate, we will only show vulnerabilities that affect the specific version you are querying.

So if you are using a list of repositories, you can just query for the commit you are using, or query the list of package names/versions you are using. (If you specify all the packages used by your java application in a pom.xml file, you might be interested in using osv-scanner to automatically parse and query for those packages.

Does these options cover your use case?

[landesfeind]

I like to follow up on this request/discussion because I ran into the same problem and even raised this as an issue within the osv-scanner repository. While I understand your points on using the specific ecosystem where available, the osv.dev website suggest that it provides data for the "GIT ecosystem" (note the ecosystem=GIT in the URL). Also the osv.dev interfaces lists affected versions (next to the affected commit range of course).

Naively I therefore assumed that the following two requests are identical to retrieve a vulnerability that I picked at random:

# Query version 1.9 directly (https://github.com/samtools/samtools/releases/tag/1.9)
curl -d '{ "version":"1.9", "package": {"name": "github.com/samtools/htslib", "ecosystem": "GIT"}}'  "https://api.osv.dev/v1/query"

# Query version via commit for 1.9 (https://github.com/samtools/samtools/releases/tag/1.9)
curl -d '{ "commit": "b24d8121509cdfc745d73dd3b90da5571a6d4db9" }' "https://api.osv.dev/v1/query"

Having this feature would be very handy for repositories that are not (yet) part of a package-ecosystem but distributed via Github. Do you think it is possible to implement this feature? That said, in case this is doable for a new-starter on OSV.dev, we are open to start implementing a PR.

PS: Of course you can always fall back to the git-commit but that is less human-friendly.

[andrewpollock]

Hi @landesfeind

The GIT ecosystem is a "synthetic" ecosystem, created to assist with viewing and exporting records.

In an OSV record, ecosystem is part of the package object, and as you'll see in records like the one for CVE-2020-36403, there's no package object (because GIT isn't a "real" ecosystem).

Now, to address the use case you're describing with you desired example query, we could look at defining a "GIT" ecosystem, storing the value in the GIT range's repo field in the package name, and the version we had mapped previously extracted to a commit...

I think there's potentially some challenges with the fact that the versioning scheme of what is converted from is inherently unknowable, so any sort of version enumeration or meaningful comparison operation isn't possible, so the utility of being able to query by or for a vulnerable version isn't going to be possible, which is why I think we haven't pursued this.

[landesfeind]

Hi Andrew - thanks a lot for the feedback! I understand the issues with the arbitrary versioning scheme. I naively assumed that the Github advisory somehow solved that 😄

[alcroito]

I'd like to chime in and say that I was also confused by seeing Git as a supported ecosystem on https://osv.dev/list?ecosystem=GIT

A downstream project also specifies git as a supported purl ecosystem for osv https://github.com/devops-kung-fu/bomber/blob/9af27992666542f3ad7b2bdd8f340e4ba1a31b3f/providers/osv/osv.go#L40

So I naively thought that it would be possible to query packages using the purl spec and a git url, although the purl spec doesn't declare an official git ecosystem.

If it's difficult to implement any kind of meaningful enumeration in this case, it would at least be nice to have a disclaimer about Git being a synthetic ecosystem that isn't really 'queryable' to avoid further confusion.