Hey Josh, we can't break the schema, and would need a very good reason to create a new major version. I'll ask some more clarifying questions in #53.

@oliverchang This would be backwards compatible, as you could still have an array of strings. It's just that you can now also do an array of objects instead if you want. (anyOf)

That said, the types I provided as examples definitely need refined and perhaps slimmed down to purely known use-cases. For now, duplicate (and perhaps alias to consolidate that?) are the only ones I know of from the GSD perspective.

@oliverchang, @darakian, are there any that would be useful from the Google/GitHub perspective? I could see GHSA's including parent/child relationships for a root-cause vulnerability and the affected OSS packages, for example.

EDIT: Oh, and the SIMILAR_TO is something we've seen with particular CVEs that say "this is NOT CVE-x CVE-y CVE-z" - @kurtseifried might know the example IDs off the top of his head. Also covers the generic "related" type. Well, not quite the generic case. There is some nuance there, but worth discussing anyway.

EDIT 2: There would need to be a RELATED or similar type for explicit backwards compatibility with the untyped string array. (i.e. if the string array is used, all entries are assumed to be of RELATED type). This could be the catchall type, similar to WEB for references.

Ideally, if a v2 schema was possible:

• related would be removed entirely and replaced with a new relationships field
• aliases would be removed entirely and provided as a relationship type
• relationships would be an array of objects { type, id }, similar to references being { type, url }

Alternatively, can also add relationships as a new field, and leave aliases and related unchanged. Allows for more specific relationship information, but remains completely backwards compatible and simple.

One comment: I think we should leave aliases and related as is. 1) backwards compatibility (assuming anyone uses it) and 2) it also nicely solves the case for which we have related data but don't know what the relationship is.

In my mind it would be nice to classify the relationship so that every end user doesn't have to read the links and figure it out, e.g. answers like "downstream vendor that ships this" or "vuln2 was found because of an incomplete fix for this vuln" and so on. Thus a possible solution where URLs start in related and then graduate to relationships once we know what the relationship is, also we leave the URL in related so that older tooling that can't read relationships still get the data.

parent/child relationships for a root-cause vulnerability and the affected OSS packages

What does it mean to be in a parent child relationship though? Is that package A discovers a vuln and package B consumes A as a dependency? Is that the vuln in A causes a distinct vuln to occur in B? Something like parser issue in A leads to incorrect behavior in B. If code is copied by a ctrl+c/ctrl+v from A to B is that a relation or an alias?

Beyond that how do we collect and validate this data? How do we use this data? I find it very difficult to know at advisory review time what relations may exist and I'm not sure what behavior change I would expect from someone receiving an advisory if it had relationship data.

@darakian

Is that package A discovers a vuln and package B consumes A as a dependency?

This is the primary use-case I was imagining. For example, with Log4Shell you could have a root vuln for Log4j itself, with child IDs for each library or service that consumes it (Minecraft, Ubiquity, every Java application on the planet that logs things, etc). This helps keep the root vulnerability minimal and relevant while still providing the valuable meta for each package affected.

Beyond that how do we collect and validate this data? How do we use this data? I find it very difficult to know at advisory review time what relations may exist and I'm not sure what behavior change I would expect from someone receiving an advisory if it had relationship data.

That's a good question. With something like GSD, for example, this would be folks updating the ID over time as things are discovered, rather than something frontloaded with the original/parent vuln ID.

The only behavior change I would see is some additional metadata for humans investigating the root cause. Scanners wouldn't care because it doesn't matter where the affected version comes from (one huge ID with everything everywhere affected, or from a child ID specific to the package scanned).

This is the primary use-case I was imagining. For example, with Log4Shell you could have a root vuln for Log4j itself, with child IDs for each library or service that consumes it (Minecraft, Ubiquity, every Java application on the planet that logs things, etc). This helps keep the root vulnerability minimal and relevant while still providing the valuable meta for each package affected.

In theory this is how CVEs are supposed to work. Rule 7.2.4 in the cve rule set states that a CNA

MUST NOT assign more than one CVE ID if the products are affected, because they share the vulnerable code. The assigned CVE ID will be shared by the affected products.

In practice it can be hard to know if two advisories share the same underlying vulnerable code or not which is where this gets painful.

That's a good question. With something like GSD, for example, this would be folks updating the ID over time as things are discovered, rather than something frontloaded with the original/parent vuln ID.

The only behavior change I would see is some additional metadata for humans investigating the root cause. Scanners wouldn't care because it doesn't matter where the affected version comes from (one huge ID with everything everywhere affected, or from a child ID specific to the package scanned).

I guess let me ask; how is a relation different from an alias? An alias is already a relation with a claim that two advisory IDs are the same (for some definition of sameness). I think the example you're laying out where users would tag an ID over time as new instances of a vuln are discovered could be captured in the alias field.

@darakian

I guess let me ask; how is a relation different from an alias? An alias is already a relation with a claim that two advisory IDs are the same (for some definition of sameness). I think the example you're laying out where users would tag an ID over time as new instances of a vuln are discovered could be captured in the alias field.

An alias is a type of relationship; not all relationships are aliases. #53 has more examples of the other kinds of relationships and why they would be helpful.

I do get wanting more fidelity out of relations, but looking at that issue it seems like an impossibility to maintain those with any sort of consistency.

Closing. I share the same concerns with @darakian here around this being not feasible to maintain with consistency in a practical way. This also complicates the schema a fair bit, and fragments it (i.e. there are now two ways to specify aliases).