CSAF with purls that have no versions

[dejanb]

I noticed that Red Hat CSAF advisories contains purls that don't have versions, like

          {
            "category": "product_version",
            "name": "gstreamer",
            "product": {
              "name": "gstreamer",
              "product_id": "gstreamer",
              "product_identification_helper": {
                "purl": "pkg:rpm/redhat/gstreamer?arch=src"
              }
            }
          },

This will not be matched by any SBOM package as the current implementation of version_matches function return false in this case. Changing the function to return true for these cases shows significantly more matched vulnerabilities.

We need to investigate if this behaviour is correct and change and test it.

[ctron]

According to the spec: https://docs.oasis-open.org/csaf/csaf/v2.0/os/csaf-v2.0-os.html

The value product_version indicates exactly a single version of the product. The value of the adjacent name property can be numeric or some other descriptor. However, it MUST NOT contain version ranges of any kind.

So, if the section product_version actually has a the name of the component (instead of the version) I'd say the document is wrong. And we should not make any assumptions that seem Red Hat specific.

[JimFuller-RedHat]

from @mprpic "Yes, that's intentional. It is used for components where we are claiming something is affected but not yet fixed. We don't have versions available in that case, so this is the best we can do. I want us to start pinning affectedness to exact versions in OSIM/OSIDB, and adding support for purls in affects is the first step towards that. For now, versionless should be interpreted as all version of that package (in the context of the product the affect is associated with, of course)."

[ctron]

I'd still say that it's not the right way to provide that information.

[mprpic]

@ctron Care to elaborate what is the right way then?

[ctron]

According to the spec: https://docs.oasis-open.org/csaf/csaf/v2.0/os/csaf-v2.0-os.html

The value product_version indicates exactly a single version of the product. The value of the adjacent name property can be numeric or some other descriptor. However, it MUST NOT contain version ranges of any kind.

I'd say that this is the right content, according to the spec.

So maybe on level higher?

Or, using product_version_range instead?

To convey the term "all versions" the special string vers:all/* MUST be used.

– 3.1.2.3.2 Branches Type - Name under Product Version Range Item 1

[mprpic]

@ctron Mmm, good point! I think flipping it to product_version_range makes sense, though may break some consumers' use of this so we may have to check with them first so this is not an unexpected change. I assume TPA would have to be adjusted to grok this new object too, correct?

So something like this:

~/temp/csaf > diff -u cve-2025-0577.json cve-2025-0577_fixed.json 
--- cve-2025-0577.json	2025-01-24 10:45:32.542618884 -0500
+++ cve-2025-0577_fixed.json	2025-01-24 10:45:12.559578065 -0500
@@ -141,8 +141,8 @@
             "name": "Red Hat Enterprise Linux 9"
           },
           {
-            "category": "product_version",
-            "name": "glibc",
+            "category": "product_version_range",
+            "name": "vers:all/*",
             "product": {
               "name": "glibc",
               "product_id": "glibc",

Thoughts?

[dejanb]

@mprpic Yes, we can support this in the code (and it's a preferred way than to implement custom non-standard logic)
Is there a way for existing files to be modified like this?