Update aliases & related definitions

[michaelkedar]

Clarify the intended use cases for the aliases and related field to align with our intended use cases.

[oliverchang]

Thanks, this looks good. I'll just add @chrisbloom7 for a review of the wording here.

The context to this is we've noticed certain sources (mainly Linux distros) use aliases to link to together different vulnerabilities in a single advisory. This complicates things when it comes to VEX/ignore files if we want to consider aliased vulnerabilities to be the same.

[rhalar]

I still find it confusing that Debian advisories removed CVE references from aliases. Especially now with these definitions, if you encounter a Debian advisory you couldn't presume that the affected packages contain the CVEs listed in related since for other entries these could be

a similar but completely different vulnerability.

even though to my understanding that's precisely what the Debian advisories tell you; a list of all CVEs affecting specific package(s) and when they were resolved.

[oliverchang]

I still find it confusing that Debian advisories removed CVE references from aliases. Especially now with these definitions, if you encounter a Debian advisory you couldn't presume that the affected packages contain the CVEs listed in related since for other entries these could be

a similar but completely different vulnerability.

even though to my understanding that's precisely what the Debian advisories tell you; a list of all CVEs affecting specific package(s) and when they were resolved.

Thanks for the feedback.

The intention of aliases is to enable VEX statements/ignore files to work across different IDs. For instance a VEX file containing CVE-XXXX-XXXX would also ignore GHSA-XXXX-XXXX, if they're linked transitively through aliases.
With linux distros, what tends to happen is DSA-XXXX bundles multiple different vulnerabilities (e.g. CVE-XXXX-1, CVE-XXXX-2). If we apply aliases transitively in this case, then a VEX statement that contains CVE-XXXX-1 will also incorrectly apply to CVE-XXXX-2 because they're linked by the DSA-XXXX.

related was always intended to be used for cases where multiple different vulnerabilities are bundled into a single entry, among others. This PR is making this a bit more explicit and correcting some incorrect/outdated wording.

May we understand your programmatic use case for Debian a bit more, and why this might be problematic for you?

[rhalar]

The VEX example makes sense, I can see the reasoning behind it and it seems correct. However, while I don't really have too much of an issue, it could be worked around for DSA and the like, the wording makes it seem like you can't really depend on related to tell you if the package in question is or isn't affected by the vulnerabilities found there.

For DSA then all vulnerabilities in the related field apply to the package, but the wording I pointed out

a similar but completely different vulnerability.

and even

Cases that do not satisfy the strict definition of aliases.

would perhaps imply this not always to be the case? E.g. CVE-2021-45046 is related to the Log4Shell issue, but they were resolved in different versions of Log4j. Should they reference each other through the related field it would be erroneous to always presume both to be applicable (it would give contradicting information even). But this would have to be done for Debian advisories since we presume all applicable vulnerabilities are enumerated there.

I hope that makes sense, I may completely be missing something though.

[chrisbloom7]

Documentation changes look great, thanks for taking the time to clarify it @michaelkedar. Approving without weighing in on the Debian discussion to unblock shipping if you all decide it's good to go.

[oliverchang]

The VEX example makes sense, I can see the reasoning behind it and it seems correct. However, while I don't really have too much of an issue, it could be worked around for DSA and the like, the wording makes it seem like you can't really depend on related to tell you if the package in question is or isn't affected by the vulnerabilities found there.

For DSA then all vulnerabilities in the related field apply to the package, but the wording I pointed out

a similar but completely different vulnerability.

and even

Cases that do not satisfy the strict definition of aliases.

would perhaps imply this not always to be the case? E.g. CVE-2021-45046 is related to the Log4Shell issue, but they were resolved in different versions of Log4j. Should they reference each other through the related field it would be erroneous to always presume both to be applicable (it would give contradicting information even). But this would have to be done for Debian advisories since we presume all applicable vulnerabilities are enumerated there.

I hope that makes sense, I may completely be missing something though.

related is not meant for consumption/usage by automated systems. It's purely a metadata field for humans to look at loosely related vulnerabilities that don't fit under aliases.

It sounds like you're looking for a way to definitively know which CVEs are addressed by e.g. a DSA? Can you speak a bit more about the end use case if so, from the perspective of vulnerability scanners / consumers of Debian?

I'll merge this PR as is, but if there are remaining gaps I think that would be better suited for another new field instead.

[rhalar]

It does make sense, and that was my initial assumption. But since CVEs were moved from aliases to related, there is no other way for an automated system to map DSAs to CVEs.

It seems a bit strange to me that there is an advisory which tells you a package is vulnerable, and even enumerates vulnerable versions, but doesn't expose the CVE(s) which are part of it. E.g.
https://osv.dev/vulnerability/DSA-5472-1

We can say cjose 0.6.1+dfsg1-1 is vulnerable, but can't state the vulnerabilities (CVE-2023-37464). I can point to an advisory, but I already ingested the advisory to get that info in the first place.