Repo specific advisories with CVE IDs don't make it into the global set

[joshbressers]

It looks like if a repo has an advisory that was not marked to enter the global database, and that advisory is assigned a CVE ID, the CVE ID in question is not present in the GitHub Advisory Database.

I feel like I'm not explaining this well, so I have an example.

This Grafana advisory
GHSA-2x6g-h2hg-rq84

Has been assigned CVE-2022-39306

If you search the GitHub advisory database, that ID doesn't show up.

It is nice to use the GitHub database, even for unreviewed IDs, because it's vastly more complete and accurate for supported ecosystems than other sources. Incomplete CVE data means multiple data sources must be queried to get a full picture of which IDs exist.

Related is #2963 where I suggest allowing community contributions for non supported ecosystems, it would be a service to the world to have a public place to store useful details uncovered during investigations

[westonsteimel]

It's a similar story for advisories that were created in a private repository but got a CVE assigned with information available publicly

[KateCatlin]

Hi all! Thank you for opening an issue about this. Yes, it's a flaw in our system design and a known error. It's been on our roadmap to correct this for some time but keeps being pushed back for other issues.

I'll keep this issue open so I can report back when we have it resolved!

[karenetheridge]

The README for this repository says:

Generally speaking, our ecosystems are the namespace used by a package registry. As such they’re focused on packages within the registry which tend to be dependencies used in software development.

...

If you have a suggestion for a new ecosystem we should support, please open an issue for discussion.

Perl does have such a registry (in https://metacpan.org/dist/CPAN-Audit, maintained by the submitter of this issue), so it would seem quite straightforward to add it as a supported ecosystem.