Vulnerability aliases

[dervoeti]

In SecObserve, vulnerabilities identified by their GHSA ID don't have an EPSS score. I checked a few GHSA vulnerabilities manually and all of them also had a CVE ID. Github provides an API that lists different identifiers for a GHSA:
https://docs.github.com/en/rest/security-advisories/global-advisories

I think it would be a good idea to store vulnerability aliases in SecObserve as well, to provide more metadata for each finding. The CISA KEV list for example also uses CVE IDs.

In Postgres, arrays could be used, but other databases might not support this. Another idea would be to use a table like this to JOIN the aliases:

observation_id | vulnerability_alias
---------------|---------------------
1              | CVE-2024-24680
1              | GHSA-xxj9-f6rv-m3x4
2              | CVE-2023-47641
2              | GHSA-xx9p-xxvh-7g8j

Or create a separate table for vulnerabilities and then another table with aliases for those.

This will negatively impact the performance of some queries, because of the need for JOINs, but I think with indexes this should not be a huge problem.

[StefanFl]

I thought about this as well. Would be helpful to have it. It must definitely work with different databases. We have a lot of relationships already, so I am not afraid of another table.

Not sure at the moment if to store with the observation or seperately so it can be used for different observations and where to get it from. It should go on the backlog.

[StefanFl]

@dervoeti Which scanner are you using? I typically work with Trivy and checked these observations. All observations from Trivy with GHSA didn't have a CVE.

[dervoeti]

Yeah, I think Trivy already prefers the CVE if available. I've used Grype. But I just saw it has the --by-cve flag which is described as: "orient results by CVE instead of the original vulnerability ID when possible".
I just checked it with one example vulnerability and Grype indeed reported the CVE ID instead. That's actually already enough for my use case. Might still be worth it to have vulnerability aliases in SecObserve, but it's maybe not super important. Configuring scanners to prefer CVE (which Trivy does by default) seems to solve most of the problems. And it puts the burden of matching vulnerability aliases on the scanners.