search

AppThreat / vulnerability-db

Vulnerability database and package search for sources such as Linux, OSV, NVD, GitHub and npm. Powered by sqlite, CVE 5.0, purl, and vers.
MIT License
91 stars 22 forks source link

Switch to csaf feeds for redhat #57

Open prabhu opened 1 year ago

prabhu commented 1 year ago

https://access.redhat.com/security/data/csaf/v2/advisories/2023/

cerrussell commented 11 months ago

@prabhu Noticing a few things that seem problematic in switching to CSAF feeds for Red Hat. Firstly, it is clear from checking the CVE referenced in any given CSAF that a minority of affected packages have an associated RHSA and CSAF. For example, of the 142 packages listed for CVE-2021-4238, 37 have an RHSA, while 21 are listed as Affected but have no associated RHSA and therefore no CSAF.

It appeared to me that only those packages which have fixes are likely to get a CSAF at this point (I guess that's when an RHSA is released?), which seems to be confirmed here.

In the coming months, we'll also be evaluating publishing VEX files containing information on the product affectedness per each vulnerability (identified by a CVE). For example, products A, B, and C may be affected by a vulnerability, but only product A has had the vulnerability addressed via a security advisory. For product A, a CSAF VEX file would exist that would represent the advisory and contain information about the fixed components.

I also don't know if/when they do expand CSAF coverage, if they will do so only moving forward. If so, we would still need the CVEs from vuln-list to capture what we need for some time.

Another consideration is that they don't appear to include the source package that is vulnerable, just whatever Red Hat product contains it - e.g. CVE-2023-37788 is for goproxy but the CSAF contains data for an OpenShift package and goproxy is only mentioned in the description. I suppose that's ok, perhaps, if cdxgen accurately identifies these products. However, I am concerned that this sort of abstraction will result in a much greater volume of documents to process. It could mean we end up facing 271 different CSAF documents versus one CVE - one for each Red Hat package with goproxy

I will nevertheless finish putting together a preliminary implementation to process CSAF documents so we will have the capability.

Our CSAF generator does offer some comprehensiveness that the Red Hat CSAFs don't due to being released as a result of a single RHSA - aggregation.