feat(redhat): migrate OVALv2 from CSAF VEX

[knqyf263]

Overview

This PR migrates the Red Hat vulnerability data source from OVALv2 to CSAF VEX format as requested by Red Hat.
Reference: https://www.redhat.com/en/blog/red-hat-vex-files-cves-are-now-generally-available

Implementation Flow

As described in aquasecurity/trivy#7452, modified the implementation to not process "product_status" since the status information (e.g., "fixed", "affected") can be obtained from "remediations" which contains product_id.

Implementation Details

While CSAF VEX stores advisories per CVE-ID, Trivy DB (following OVALv2's approach) stores patched vulnerabilities per RHSA-ID. For example:

• csaf-vex/2024/cve-2024-0001.json
  • RHSA-2024-0001
• csaf-vex/2024/cve-2024-0002.json
  • RHSA-2024-0001

This means we cannot process files individually and need to parse all files first, then rebuild them per RHSA-ID so that the new database will not break old clients.

The implementation consists of three main components:

• Parser: Parses individual CSAF VEX files and stores <package>-<vulnerability-id> pairs
• Aggregator: Aggregates parsed data for efficient storage
• VulnSrc: Stores aggregated data in the database

Implementation Notes

The parsed data is currently stored in memory. Initially, I created a temporary BoltDB for storage due to concerns about data size, but this significantly slowed down processing. After measuring the actual data size (560MB as of January 16, 2024), I determined that in-memory storage was feasible. If the data size grows substantially in the future, we may need to revise this implementation.

Blockers

As of January 16, 2025, there are significant differences in package name handling:

• OVALv2
  • patched vulns: binary package names only
  • unpatched vulns: source + binary package names
• CSAF VEX
  • patched vulns: source + binary package names (without mapping capability)
  • unpatched vulns: source package names only

Trivy currently compares binary package names, which works with OVALv2. However, with CSAF VEX, unpatched vulnerabilities need to be compared using source package names, which means older Trivy versions won't be able to detect unpatched vulnerabilities correctly. It would be a breaking change.

This issue has been raised with Red Hat and is being tracked at: https://issues.redhat.com/browse/SECDATA-856

Important Notes

The following issues were discovered during data analysis:

Unclear PURL Namespaces

While PURLs typically use the redhat namespace, some use different namespaces.
Example: pkg:rpm/redhat/satellite_client_6/foreman_ygg_worker?arch=src

This isn't related to module streams, and its purpose is unclear. Currently treating satellite_client_6/foreman_ygg_worker as part of the package name, though this data is effectively unused as Trivy doesn't construct such package names.

Issue tracked at: https://issues.redhat.com/browse/SECDATA-854

Missing PURLs

Despite documentation stating that product_version objects always include PURLs (https://redhatproductsecurity.github.io/security-data-guidelines/csaf-vex/), some cases lack PURLs.

Documentation states:

The product_version category includes information about a specific affected package. The product_version object will always include the name of the component, a product ID and a product identification helper in the form of a PURL.

Example of missing PURL:
https://github.com/aquasecurity/vuln-list-redhat/blob/925beb2b9a400640a45f8ea6fc7ea57ab4ae63ff/csaf-vex/2001/cve-2001-0131.json#L216-L223

Duplicate product_versions

Some files contain identical product_versions multiple times.

Examples:
https://github.com/aquasecurity/vuln-list-redhat/blob/42df5998a5f20d1a1cb67978486fffd82e61c34e/csaf-vex/2004/cve-2004-0885.json#L272-L282
https://github.com/aquasecurity/vuln-list-redhat/blob/42df5998a5f20d1a1cb67978486fffd82e61c34e/csaf-vex/2004/cve-2004-0885.json#L470-L480

Identical CPEs

Different product_ids may share the same CPE. Implementation must account for this to avoid duplicates.

Example:
https://github.com/aquasecurity/vuln-list-redhat/blob/ce0ad982c845fc24cabcf5678c3063b3b54dc500/csaf-vex/2015/cve-2015-4866.json#L206-L249

Source to Binary Package Mapping

While RHSAs include both source and binary packages for patched vulnerabilities, there's currently no way to map between them in CSAF VEX.

Example: Unable to determine which binary packages correspond to BaseOS-8.7.0.Z.MAIN:python-setuptools-0:39.2.0-6.el8_7.1.src from:

"BaseOS-8.7.0.Z.MAIN:platform-python-setuptools-0:39.2.0-6.el8_7.1.noarch",
"BaseOS-8.7.0.Z.MAIN:python-setuptools-0:39.2.0-6.el8_7.1.src",
"BaseOS-8.7.0.Z.MAIN:python3-setuptools-0:39.2.0-6.el8_7.1.noarch",
"BaseOS-8.7.0.Z.MAIN:python3-setuptools-wheel-0:39.2.0-6.el8_7.1.noarch",
"BaseOS-9.1.0.Z.MAIN:python-setuptools-0:53.0.0-10.el9_1.1.src",
"BaseOS-9.1.0.Z.MAIN:python3-setuptools-0:53.0.0-10.el9_1.1.noarch",
"BaseOS-9.1.0.Z.MAIN:python3-setuptools-wheel-0:53.0.0-10.el9_1.1.noarch"

Advisory Discrepancies

1. CSAF VEX-only advisories
   Some advisories exist only in CSAF VEX, not in OVALv2.
   Example: https://access.redhat.com/errata/RHSA-2023:4655

2. OVALv2-only advisories
   Some advisories exist only in OVALv2, not in CSAF VEX.
   Example: https://github.com/aquasecurity/vuln-list-redhat/blob/ac1041557cea771cc6ca106453202cbc4de7a139/oval/9/rhel-9-including-unpatched/definitions/2020/CVE-2020-26146.json

   While this specific CVE issue was resolved after the Vuls maintainer contacted Red Hat, similar issues likely exist.