Check for `n/a` in vendor

[andrewpollock]

I've observed n/a in the affected[].vendor field in the wild.

Example CVE: https://cveawg.mitre.org/api/cve/CVE-2023-22799

[mprpic]

Technically the schema for the vendor field notes that n/a is valid:

Name of the organization, project, community, individual, or user that created or maintains this product or hosted service. Can be 'N/A' if none of those apply. When collectionURL and packageName are used, this field may optionally represent the user or account within the package collection associated with the package.

but I feel like if vendor is not specified then using product doesn't make sense either. In the example you linked to, I would expect it to either be:

      "affected": [
        {
          "vendor": "Rails",
          "product": "https://github.com/rails/globalid",
          "versions": [
            {
              "version": "1.0.1",
              "status": "affected"
            }
          ]
        }
      ],

which is pretty meh, or:

      "affected": [
        {
          "collectionUrl": "https://rubygems.org",
          "packageName": "globalid",
          "versions": [
            {
              "version": "1.0.1",
              "status": "affected"
            }
          ]
        }
      ],

or even better:

      "affected": [
        {
          "collectionUrl": "https://rubygems.org",
          "packageName": "globalid",
          "versions": [
            {
              "version": "pkg:gem/globalid@1.0.1",
              "status": "affected"
            }
          ]
        }
      ],

which I now realize breaks our version check since a purl contains plenty of weird non-version-looking characters. But using purls in the version field is the recommended way to specify them:

https://github.com/CVEProject/cve-schema/issues/173#issuecomment-1264500179

So I may modify the existing version check to ignore any fields that start with pkg:.

Side question: even if CNAs start filling out the vendor field, I assume the values used in that field would be all over the place. Is there any sort of a purl-like identifier for software producer entities that the field could standardize on?

[mprpic]

@andrewpollock, any thoughts on the above?

[andrewpollock]

The objective is to as authoritatively as possible programmatically identify the subject of the vulnerability.

I think we can have a heuristic for ways to consider that achievable:

• vendor and product (which in an ideal world, would correspond to the equivalent fields in a CPE string)
• collectionURL and packageName
• repo
• cpes

I just discovered https://github.com/CVEProject/cve-schema/blob/master/schema/docs/versions.md while I was trying to do some research to provide a more informed response. I thought purls were more of a first-class thing in CVE 5.1, but I can't find any explicit mention of them?

Yes, vendor being a free-form string is going to be an un-normalized mess, which is why I'd love it to correspond to the CPE Dictionary's idea of "vendor". I have this pipe dream of being able to construct a CPE string from other data available in the record...

[mprpic]

purl is technically supported as part of the version field, e.g.:

{"version": "pkg:npm/foobar@12.3.1", "versionType": "purl", "status": "affected"}

although there aren't any references to it in the docs I think.