Summary

As of January 14, 2025, the current situation is as follows (if we understand correctly):

• OVALv2:

• • Patched vulnerabilities: Include only binary package names.
  • Unpatched vulnerabilities: Include both source and binary package names.
• CSAF VEX:

• • Patched vulnerabilities: Include both source and binary package names.
  • Unpatched vulnerabilities: Include only source package names.

At Aqua Security, our vulnerability scanner, Trivy, utilizes OVALv2. Since OVALv2 includes only binary package names for patched vulnerabilities, Trivy consistently performs comparisons using binary package names regardless of the vulnerability status (patched/unpatched).

However, CSAF VEX does not include binary package names for unpatched vulnerabilities, making the migration from OVALv2 to CSAF VEX challenging.{}

Details

OVALv2

We understand that OVALv2's unpatched advisories mix source and binary package names. For example, while no binary package is named "vim," OVALv2 lists it alongside other binary package names like "vim-X11."

"Criterions": [
  {
    "Comment": "vim is installed",
    "TestRef": "oval:com.redhat.cve:tst:20171000382011"
  },
  {
    "Comment": "vim is signed with Red Hat redhatrelease2 key",
    "TestRef": "oval:com.redhat.cve:tst:20171000382012"
  }
] 

From the context, "vim" in this case, is considered a source package, although, as far as we know, there is no direct way to discern source packages from the OVALv2 data.

Example OVALv2 JSON snippet link for unpatched vulnerabilities

In contrast, OVALv2’s patched advisories do not include "vim," which indicates that they list only binary package names.
Example OVALv2 JSON snippet link for patched vulnerabilities

CSAF VEX

However, for CSAF VEX, unpatched vulnerabilities include only source package names.

Example:

          {
            "category": "product_version",
            "name": "vim",
            "product": {
              "name": "vim",
              "product_id": "vim",
              "product_identification_helper": {
                "purl": "pkg:rpm/redhat/vim?arch=src"
              }
            }
          }
        ...
        {
          "category": "no_fix_planned",
          "details": "Out of support scope",
          "product_ids": [
            "red_hat_enterprise_linux_6:vim",
            "red_hat_enterprise_linux_7:vim"
          ]
        },

Example CSAF VEX JSON snippet link for unpatched vulnerabilities

Patched vulnerabilities in CSAF VEX include both source and binary package names:
Example:

            "BaseOS-8.6.0.Z.MAIN.EUS:vim-2:8.0.1763-19.el8_6.4.src",
            "BaseOS-8.6.0.Z.MAIN.EUS:vim-X11-2:8.0.1763-19.el8_6.4.aarch64",
            "BaseOS-8.6.0.Z.MAIN.EUS:vim-X11-2:8.0.1763-19.el8_6.4.ppc64le",
            "BaseOS-8.6.0.Z.MAIN.EUS:vim-X11-2:8.0.1763-19.el8_6.4.s390x",
            "BaseOS-8.6.0.Z.MAIN.EUS:vim-X11-2:8.0.1763-19.el8_6.4.x86_64", 

Example CSAF VEX JSON snippet link for patched vulnerabilities

Context

Our vulnerability scanner separates the vulnerability detection engine from the vulnerability database, allowing independent updates. However, CSAF VEX cannot provide a database equivalent to OVALv2. This would require modifying the detection engine to compare source package names for unpatched vulnerabilities—such a change risks failing to detect unpatched vulnerabilities for users running older versions.

We would like to inquire whether it is possible to include OVALv2-equivalent data in CSAF VEX or if there are any recommended workarounds.

This draft emphasizes clarity and structure. Let me know if you’d like further refinements!