How to query the API for vulnerabilities in a Git repo?

[thoughtpolice]

I am using Cap'n Proto, a relatively niche library but one that has had a CVE or two.

Consider https://osv.dev/vulnerability/CVE-2023-48230 — how can I find this via an API query, given the version or Git commit of the upstream https://github.com/capnproto/capnproto/ repository for the package I'm using? Let's say it's 1.0.1, so it should be vulnerable to this CVE? How can I query that?

Things I've tried:

• Setting ecosystem=GIT in the API request and querying for the repo as the name of the package. This always returns Invalid ecosystem. with code=3 — for example http https://api.osv.dev/v1/query package[name]="https://github.com/capnproto/capnproto" package[ecosystem]=GIT
• Using PURL specification since the spec mentioned a hypothetical pkg:github, but it returns nothing no matter what — for example http https://api.osv.dev/v1/query package[purl]=pkg:github/capnproto/capnproto

(http is HTTPie, which is just a simpler way to write JSON requests than cURL.)

Neither of these seem to work; the actual Python app running the frontend seems to be using its own search index in the background which isn't exposed to the API?

Cap'n Proto is not the only relevant example. I would also like to query for:

• https://github.com/microsoft/mimalloc (no reports to date)
• https://github.com/madler/zlib (several real reports, but most hits are actually under pkg:debian, etc)

Neither of these have pkg:generic PURL specifiers it seems, so I can't refer to them. zlib is the more relevant of the two since I'm in the same boat there; if I have version 1.3.1, how can I query against the repository? I guess in the zlib case I can piggyback on pkg:debian, but in the mimalloc case it seems I'm SOL.

[oliverchang]

The way to query by git repos is to query by the commit SHA. e..g.

curl -d '{"commit": "c7f810a76ca88ff28613fa165927e0269255aab0"}' https://api.osv.dev/v1/query

(c7f810a76ca88ff28613fa165927e0269255aab0 is the commit for https://github.com/capnproto/capnproto/releases/tag/v1.0.1)

However, this is returning 0 results. This is because of #1910 (comment) and us not doing cherrypick detection by default for our CVE source.

@andrewpollock

[oliverchang]

In the case of https://osv.dev/vulnerability/CVE-2023-48230, it's because the record doesn't include capnproto/capnproto@5d5d734 (another cherrypicked variant of the fix)

Our cherrypick detection does detect this case (python -m osv.analyze_tool --detect_cherrypicks true --format json ~/CVE-2023-48230.json), but again it's not turned on by default. I've filed #2577 to track this.

[thoughtpolice]

Thanks! I really couldn't understand directly from the documentation if the commit object was inclusive (i.e. all dependent and ancestor commits and the graph is known so you can tell if any commit vulnerable) or if it was only intended to be specified on release objects, or what have you.

I think I likely did try what you suggested but got zero results, which made it seem even stranger, like the endpoint call was wrong.

Probably just a little more docs on the v1/query page would have helped here. Thanks for tracking the capnproto bug, too!

[andrewpollock]

Probably just a little more docs on the v1/query page would have helped here.

Feel free to send us a PR for an improvement that would have made them better for someone like yourself.

[andrewpollock]

Also, HTTPie is cool, thanks for bringing it to my attention.

For vulnerabilities in https://github.com/madler/zlib, https://osv.dev/list?q=https%3A%2F%2Fgithub.com%2Fmadler%2Fzlib&ecosystem= returns a bunch, let's explore a few:

• https://osv.dev/vulnerability/CVE-2023-45853
  • querying for madler/zlib@09155ea (https://github.com/madler/zlib/releases/tag/v1.3): curl -d '{"commit": "09155eaa2f9270dc4ed1fa13e2b4b2613e6e4851"}' https://api.osv.dev/v1/query returns https://osv.dev/vulnerability/CVE-2023-45853
• https://osv.dev/vulnerability/CVE-2022-37434
  • querying for madler/zlib@b9ae6f0: curl -d '{"commit": "b9ae6f0079099c1b2e26abbb434725c4cf62d6b2"}' https://api.osv.dev/v1/query returns https://osv.dev/vulnerability/CVE-2022-37434 and https://osv.dev/vulnerability/CVE-2018-25032
• https://osv.dev/vulnerability/CVE-2018-25032
  • querying for madler/zlib@https://github.com/madler/zlib/commit/cacf7f1d4e3d44d871b605da3b647f07d718623f (https://github.com/madler/zlib/releases/tag/v1.2.11): curl -d '{"commit": "cacf7f1d4e3d44d871b605da3b647f07d718623f"}' https://api.osv.dev/v1/query returns https://osv.dev/vulnerability/CVE-2018-25032

Basically, take whatever commit your repo of interest is at, and feed it to the API (or use OSV-Scanner) and see what you get back.

[github-actions]

This issue has not had any activity for 60 days and will be automatically closed in two weeks

See https://github.com/google/osv.dev/blob/master/CONTRIBUTING.md for how to contribute a PR if you're interested in helping out.

[thoughtpolice]

I do consider this closed, as I have my (terribly written) osv.dev scripts working now. Thanks everybody!