Include more details in "unreviewed" advisories

[G-Rath]

Currently there are a lot of "unreviewed" advisories sitting in this repository that represent very real and known vulnerabilities in potential ecosystems but who currently cannot be represented in the OSV specification as they don't map to a defined ecosystem.

This has already created a "chicken vs egg" situation because in order to remain valid to the specification these advisories don't have any affected details which means while tools like osv-detector can load them, there's nothing for it to compare against - however it's a lot harder to propose a new ecosystem if we can't do any analysis or prototyping.

I want to propose that GitHub deliberately violate the OSV specification for those advisories in favor of attempting to include as much affected information as possible in the unreviewed advisories so that folks can more easily try and find patterns in these advisories that could lead to new ecosystems being proposed for the specification.

I think there's a number of forms this could actually take and that ultimately its probably for GitHub to decide what works best for them and how far they want to take it - I personally would probably start by ensuring as much of the version-based information is present, ignoring/dropping the ecosystem property for now (i.e. rather than picking experimental or arbitrary ecosystem names), and start with a sort of high-level based tagging.

This probably won't work nicely for every single unreviewed advisory, but that's also part of the point of this: currently the amount of advisories is huge, so we want to try and sort through them to identity the more complex advisories by reducing the number of completely unreviewed advisories.

The example I've been thinking about is WordPress plugins: I know there are unreviewed advisories for WordPress plugins, so they could be tagged with something that identified them as that and then people could exclude/include those depending on what they're wanting (e.g. my place of work is very interested in that because we have some WordPress sites, so if we could pick out just WP plugin advisories and they had at least some affected information we could explore that further; whereas other people who are trying to pick out some potential new ecosystems could exclude WP plugin advisories since they're already "tagged")

[oliverchang]

This also makes sense to me -- starting with unsupported ecosystems only in "unreviewed" could be a good way to trial a new ecosystem that can be later properly specified in the OSV spec. We can explicitly document that anything in "unreviewed" do not strictly follow OSV.

On how to do this, I'd recommend not using the "ecosystem" field as that can cause confusion/inconsistencies once an ecosystem is officially supported later and instead use something else like:

{
  "unsupported_ecosystem": "Wordpress",
  "name": "plugin-name"
}

[kmk3]

Related discussion:

• Got feedback for our new open-source Advisory Database repository? #11 (comment)