MIssing GHSA related to https://github.com/randombit/botan

[sha-cy]

Describe the bug
in the OSV i have noticed that there are several GHSA for the https://github.com/randombit/botan project that are missing.
Some are missing the GIT section in the affected package section of the OSV json, and others are missing entirely; all of them are listed in https://github.com/randombit/botan/security

To Reproduce
Steps to reproduce the behaviour:

1. Go to 'botan security page'
2. Copy a GHSA identifier
3. Search for it in OSV.dev

Expected behaviour
have the GHSA listed on the website

Screenshots

[andrewpollock]

GitHub, somewhat confusingly, has two types of advisories. I'm probably going to use incorrect terminology here, but there's basically the advisories issued by GitHub (and present in https://github.com/github/advisory-database) and advisories that any GitHub repository owner can issue. I'll call these "repo advisories".

I think to further add to the confusion, GitHub may issue their own advisory (with a separate GHSA identifier) in response to a repo advisory. Nothing stops these two advisories from diverging.

Please keep me honest here, @taladrane @darakian

These repo advisories are not included in what OSV.dev imports from GitHub, because they're not technically "in" the GitHub Advisory Database (present in https://github.com/github/advisory-database).

Working through what we've got at https://github.com/randombit/botan/security:

• GHSA-jp24-56jm-gg86
  • https://osv.dev/vulnerability/CVE-2024-39312 exists for it and aliases the repo advisory
• GHSA-w4g2-7m2h-7xj7
  • https://osv.dev/vulnerability/CVE-2024-34703 exists for it and aliases the repo advisory
• GHSA-5gg9-hqpr-r58j
  • https://osv.dev/vulnerability/CVE-2024-34702 exists for it and aliases the repo advisory
• GHSA-4v9w-qvcq-6q7w
  • https://osv.dev/vulnerability/CVE-2022-43705 exists for it and aliases the repo advisory

Searching by alias is essentially the crux of #760 and #1016. #2235 also touches on this more broadly.

If you were to use the OSV.dev API to query for any of the vulnerabilities described by any of the existing records with a relationship the CVE records, you'd get those vulnerability identifiers returned.

[darakian]

GitHub, somewhat confusingly, has two types of advisories.

Yep. Repo advisories and reviewed advisories. In theory they can diverge on anything/everything, but in practice the reviewed advisories tend to be cleanups on metadata and sometimes some information enrichment. We also filter out false claims. For a given GHSA you can get the repo advisories on
https://docs.github.com/en/rest/security-advisories/repository-advisories?apiVersion=2022-11-28
and the reviewed advisories on
https://docs.github.com/en/rest/security-advisories/global-advisories?apiVersion=2022-11-28

I think to further add to the confusion, GitHub may issue their own advisory (with a separate GHSA identifier) in response to a repo advisory. Nothing stops these two advisories from diverging.

I think you're talking about the reviewed advisories here. Not all advisories get reviewed due to scope limitations or whatever, but those that do share the same GHSA number as the repo advisory. There are cases where a user may get a CVE number from a different CNA and also make a repo advisory and depending on how a race condition works out that may or may not create a new GHSA number. It's a huge pain we try really hard to wrangle. Not perfect I know, but I hope that helps. :)

[sha-cy]

thank you both for your answers i was unaware of this system of "official" and "unofficial" (for lack of a better term) of GHSA in repos, but the reason I opened this issue is more to do with the way the affected field is built then the missing page.

When looking at CVE-2024-39312 entry in OSV for example we can see that the GHSA is listed in the aliases field, but when working with the affected field to try and determine whether the relevant version of botan is vulnerable, I was unable to because all the purls and ecosystems there were for specific Linux distributions.

When I searched for relevancy until now I found the most efficient and accurate method to be searching for the affected block where the purl was the GitHub repository and\or where the "Type" was "GIT", since there is a GHSA for those botan vulnerabilities with a range of affected version I thought that the reason that there was non in OSV was some kind of parsing error of the GHSA since there was no independent entry for that as well.

But from what I understood from your answers, a GHSA only if they are here, both the reviewed and the unreviewed, that the botan vulnerabilities didn't.

What is not clear is why the botan vulnerabilities are not listed there?

[andrewpollock]

Hi again,

I think I'm hearing two questions:

1. Why doesn't https://osv.dev/vulnerability/CVE-2024-39312 have any Git ranges (but the other Botan CVE-prefixed vulnerabilities do)?

This CVE is still awaiting analysis by the NVD, and lacks the necessary machine-readable metadata to attempt to map to Git commits and if successful, include in OSV.dev.

CVE-2024-34703 and CVE-2024-34702 are also in this state, but these have reference URLs that enable a best-effort conversion.

CVE-2022-43705 has been analyzed by the NVD and has the necessary machine-readable metadata to enable Git commits to be derived.

2. Why aren't the aforementioned Botan repository advisories included in the GitHub global security advisories?

That's more of a question for the GitHub Advisory Database folks, I'm not intimately familiar with their processes. @darakian is there some canonical "life of a GitHub Advisory" documentation I can point people at in situations like this?

[darakian]

2. Why aren't the aforementioned Botan repository advisories included in the GitHub global security advisories?

The simple reason is that botan is outside of our curation scope. C and C++ stuff has come up a bunch and we've got an open issue for it here
github/advisory-database#2963

The tl;dr we don't (yet) have a good way to index the vulnerability data to make it broadly useful.

@darakian is there some canonical "life of a GitHub Advisory" documentation I can point people at in situations like this?

Not that I'm aware of. I gave an old talk which touches on it a bit
https://www.youtube.com/watch?v=vOQmvEUt_AU
But we should probably add something in text.

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

[sha-cy]

I think i will close this ticket as my questions were answered and I will switch to monitoring github/advisory-database#2963, to see how things develop