Aliases, and how they are supposed to be used

[nscuro]

Hey OSV team, thanks for your great work!

We're currently looking at how we can correlate vulnerabilities that describe the same thing.

As per specification, OSV has the aliases field for this:

The aliases field gives a list of IDs of the same vulnerability in other databases, in the form of the id field.

At least in my interpretation, aliasing is a bidirectional relationship that also applies transitively.
If X aliases Y and Z, Y should also alias X, and Y should also alias Z. If they all describe the same thing, that should be a valid assumption.

However, in reality, we see that many vulnerability databases (ab-)use the OSV schema to publish advisories. In my understanding, a vulnerability would describe one defect, and that one defect only. Whereas an advisory can potentially refer to multiple vulnerabilities (as in "we patched all these vulnerabilities in version 1.2.3 of our package"). This appears to be a common thing for at least the Go, Rust, and (especially) Debian ecosystems in the OSV database. There are most likely more, but these have been the most obvious candidates to us.

For example, GO-2022-0586 presumably aliases four CVEs and four GHSAs:

• CVE-2022-26945
• CVE-2022-30321
• CVE-2022-30322
• CVE-2022-30323
• GHSA-28r2-q6m8-9hpx
• GHSA-cjr4-fv6c-f3mv
• GHSA-fcgg-rvwg-jv58
• GHSA-x24g-9w7v-vprh

These are four different vulnerabilities, with different CWEs, descriptions and severities. CVEs and GHSAs actually alias each other in pairs of two (GHSA-28r2-q6m8-9hpx aliases CVE-2022-30323, but not CVE-2022-26945 etc.):

In cases of advisories like this, the "aliases" are neither bidirectional (GHSA-28r2-q6m8-9hpx isn't really the same as GO-2022-0586), nor are they fully transitive (CVE-2022-26945 is not the same as CVE-2022-30323). If one was to attempt to find all aliases for GHSA-28r2-q6m8-9hpx here, traversing this graph would yield wrong results.

The Debian ecosystem especially has many of these scenarios, where one DLA can refer to loads of CVEs:

I have the feeling that OSV entries of type "advisory" (maybe such a distinction would be good to have?) should instead use the related field. Although I imagine this will be hard to enforce, and even harder to apply in an automated fashion.

Am I understanding aliasing in OSV correctly? Is this a data quality issue with the databases that use the OSV schema? Is there anything we can do about it?

[oliverchang]

Hey @nscuro !

Thanks for the very detailed issue!

Can you explain a bit more about the exact use case you're trying to achieve here with the OSV data? Are you trying to build your own graph representation?

For the OSV schema, we actively avoided trying to make an explicit distinction between a group of vulnerabilities (advisory) vs a single vulnerability to keep things simple. In terms of the end result we want to enable, it's the same -- the ability to identify which package versions are affected and which versions to update to.

How we envision a vulnerability scanner working with our data would be this:

1. Extract a list of packages and versions to query. Say this is just Package "Foo" at Version "1.0.0".
2. Query OSV and get the list of vulnerability entries that say "Foo" at "1.0.0" is vulnerable.
3. Use "aliases"/"related" to group them together for presentation, e.g. in a bug filed.
4. Suggest a fix/resolution such that all the entries in a single group agree.

Under this workflow, it seems to make sense to group all of the related vulnerabilities together, so users have the full context on what all the vulnerability sources say, and updates/remediation steps account for all relevant entries in the same group. The fact that some of these are "advisories" should not matter -- having them be split up would have the same effect.

If this is an issue of semantics and representation, we can certainly ask our data sources to use related instead in the cases where an entry they're exporting consists of multiple other vulnerabilities from a different source, and this is likely more correct. I think this would be a relatively easy ask for our current sources to adopt.

[nscuro]

Can you explain a bit more about the exact use case you're trying to achieve here with the OSV data?

Our use case is not primarily about recommending a fixed version to an end user ("updating to version X will resolve all these issues"), it's more about tracking risk, and making it transparent. So knowing which vulnerabilities are the same and which are not does matter to us.

We also have a VEX-like use case, where users (or machines) evaluate whether a project is actually affected by a vulnerability, and record their decision. Obviously we want to avoid redundant work being done, a decision should not have to be recorded for GHSA-28r2-q6m8-9hpx and CVE-2022-30323 separately, as they describe the same thing. On the other hand, we don't want the same decision being applied to different vulnerabilities (CVE-2022-30323 vs. CVE-2022-26945), because the exposure, attack vector, impact etc. may differ.

Approaching this use case the other way around, if a vendor provided a VEX document stating that their product is not affected by CVE-2022-30323, this should also be applicable to actual aliases like GHSA-28r2-q6m8-9hpx, but not CVE-2022-26945.

If this is an issue of semantics and representation, we can certainly ask our data sources to use related instead in the cases where an entry they're exporting consists of multiple other vulnerabilities from a different source, and this is likely more correct.

That'd be great!

[oliverchang]

Can you explain a bit more about the exact use case you're trying to achieve here with the OSV data?

Our use case is not primarily about recommending a fixed version to an end user ("updating to version X will resolve all these issues"), it's more about tracking risk, and making it transparent. So knowing which vulnerabilities are the same and which are not does matter to us.

We also have a VEX-like use case, where users (or machines) evaluate whether a project is actually affected by a vulnerability, and record their decision. Obviously we want to avoid redundant work being done, a decision should not have to be recorded for GHSA-28r2-q6m8-9hpx and CVE-2022-30323 separately, as they describe the same thing. On the other hand, we don't want the same decision being applied to different vulnerabilities (CVE-2022-30323 vs. CVE-2022-26945), because the exposure, attack vector, impact etc. may differ.

Got it, thanks for explaning! Are you thinking of recording VEX on a per package basis, such that users can transitively determine from the entire dependency graph if they're actually indirectly affected by a vulnerability?

Approaching this use case the other way around, if a vendor provided a VEX document stating that their product is not affected by CVE-2022-30323, this should also be applicable to actual aliases like GHSA-28r2-q6m8-9hpx, but not CVE-2022-26945.

If this is an issue of semantics and representation, we can certainly ask our data sources to use related instead in the cases where an entry they're exporting consists of multiple other vulnerabilities from a different source, and this is likely more correct.

That'd be great!

We'll start conversations here with Go, and fix up the Debian ones.

[github-actions]

This issue has not had any activity for 60 days and will be automatically closed in two weeks

[nscuro]

Commenting to signal that this issue is still relevant.

I am enlightened however to see there is a continuous effort to improve the situation :)

[oliverchang]

Commenting to signal that this issue is still relevant.

I am enlightened however to see there is a continuous effort to improve the situation :)

Thanks! removed the stale tags.

[tiegz]

@oliverchang was wondering if asking vuln providers to break these apart was still part of the plan, or if it's a lost cause? We came across some extreme cases that have 20 CVEs grouped together (seems like Alma does the grouping too):

https://api.osv.dev/v1/vulns/ALSA-2022:1759
https://api.osv.dev/v1/vulns/DLA-2819-1

[nscuro]

@tiegz Those records look OK to me, since they don't use the aliases field. The related field that they do use is not meant to assert equality.

[tiegz]

@nscuro @oliverchang sorry, my bad! I saw these as linked together at some point by "alias", but it was most likely via GHSA-q759-8j5v-q5jp instead, which is missing in OSV now.

Some of the Go reports that "alias"'ed together multiple CVEs in the past seem to have been fixed, so these are the only ones I see now:

• GO-2022-0536
• GO-2024-2652
• GO-2022-0586
• GO-2022-0427
• GO-2021-0084
• GO-2020-0005

And I know Rust was already mentioned in this Issue, but here are a a couple examples of reports that I still see using "aliases" in this way:

• RUSTSEC-2020-0041
• RUSTSEC-2021-0128
• RUSTSEC-2021-0110
• RUSTSEC-2020-0070
• RUSTSEC-2021-0019
• RUSTSEC-2021-0038

Thanks for the work on this!

[nscuro]

@tiegz Do you happen to know how the other Go vulns were fixed? Were all identifiers simply moved to related? Is Go creating vulnerabilities more granular going forward to enable usage of the aliases field? I haven't refreshed my analysis setup in a while.

[tiegz]

@nscuro they do seem to be moving to the "related" field, e.g. https://api.osv.dev/v1/vulns/GO-2022-0322:

Previously, I believe this report's aliases were:

CGA-93vr-4696-924c
CGA-h2vq-f2rf-jwrq
CVE-2022-21698
CVE-2023-25151
CVE-2023-45142
GHSA-5r5m-65gx-7vrh
GHSA-cg3q-j54f-5p7p
GHSA-rcjv-mgp8-qvmr
GO-2023-1546
GO-2023-2113

[nscuro]

Hmmm... I guess technically that's better than before. Although now we lost the info that GHSA-5r5m-65gx-7vrh aliases CVE-2023-25151. But GHSAs have their own records anyway so that info is not gone for good.

Curiously, GHSA-5r5m-65gx-7vrh (listed as related in GO-2023-1546) is still listed to alias GO-2023-1546: https://api.osv.dev/v1/vulns/GHSA-5r5m-65gx-7vrh. If you were to consume both the GO, and the GHSA advisory, you'd still run into the original issue.

[tiegz]

I think we've still got that alias to CVE-2023-25151 in GHSA-5r5m-65gx-7vrh.

Here's an attempt to graph what's in OSV for these previously bundled reports (I omitted "related" edges because that would've been noisier):

flowchart LR
    style CGA-93vr-4696-924c fill:orange
    CGA-93vr-4696-924c --aliases--> CVE-2022-21698
    CGA-93vr-4696-924c --aliases--> GHSA-cg3q-j54f-5p7p
    CGA-93vr-4696-924c --aliases--> GO-2022-0322
    
    style CGA-h2vq-f2rf-jwrq fill:orange
    CGA-h2vq-f2rf-jwrq --aliases--> CVE-2023-45142
    CGA-h2vq-f2rf-jwrq --aliases--> GHSA-rcjv-mgp8-qvmr
    CGA-h2vq-f2rf-jwrq --aliases--> GO-2023-2113

    style CVE-2022-21698 fill:yellow
    CVE-2022-21698 --aliases--> CGA-93vr-4696-924c
    CVE-2022-21698 --aliases--> GHSA-cg3q-j54f-5p7p
    CVE-2022-21698 --aliases--> GO-2022-0322

    style CVE-2023-25151 fill:yellow
    CVE-2023-25151 --aliases--> GHSA-5r5m-65gx-7vrh
    CVE-2023-25151 --aliases--> GO-2023-1546

    style CVE-2023-45142 fill:yellow
    CVE-2023-45142 --aliases--> CGA-h2vq-f2rf-jwrq
    CVE-2023-45142 --aliases--> GHSA-rcjv-mgp8-qvmr
    CVE-2023-45142 --aliases--> GO-2023-2113

    style GHSA-5r5m-65gx-7vrh fill:lightblue
    GHSA-5r5m-65gx-7vrh --aliases--> CVE-2023-25151
    GHSA-5r5m-65gx-7vrh --aliases--> GO-2023-1546

    style GHSA-cg3q-j54f-5p7p fill:lightblue
    GHSA-cg3q-j54f-5p7p --aliases--> CGA-93vr-4696-924c
    GHSA-cg3q-j54f-5p7p --aliases--> CVE-2022-21698
    GHSA-cg3q-j54f-5p7p --aliases--> GO-2022-0322

    style GHSA-rcjv-mgp8-qvmr fill:lightblue
    GHSA-rcjv-mgp8-qvmr --aliases--> CGA-h2vq-f2rf-jwrq
    GHSA-rcjv-mgp8-qvmr --aliases--> CVE-2023-45142
    GHSA-rcjv-mgp8-qvmr --aliases--> GO-2023-2113

    style GO-2023-1546 fill:pink
    GO-2023-1546 --aliases--> CVE-2023-25151
    GO-2023-1546 --aliases--> GHSA-5r5m-65gx-7vrh

    style GO-2023-2113 fill:pink
    GO-2023-2113 --aliases--> CGA-h2vq-f2rf-jwrq
    GO-2023-2113 --aliases--> CVE-2023-45142
    GO-2023-2113 --aliases--> GHSA-rcjv-mgp8-qvmr

    style GO-2022-0322 fill:pink
    GO-2022-0322 --aliases--> CGA-93vr-4696-924c
    GO-2022-0322 --aliases--> CVE-2022-21698
    GO-2022-0322 --aliases--> GHSA-cg3q-j54f-5p7p

Loading