is vendor == CNA? Capture a way to say a product is from a different origin/source/upstream

[chandanbn]

create a new tag?

product tags? type of product?

[jasinner]

Red Hat as a CNA would like to report vulnerabilities in software which is not distributed by us, but instead consumed by us. None of the software which we distribute is not first distributed by a third party. We commonly refer to that as "upstream".

We might make modifications to the software such as applying security patches, which change the way in which report CVEs in upstream sources verses our products, but many times we are redistributing upstream content without any changes. Being able to report on 'upstream' sources helps us improve security vulnerability reporting in the upstream community, and also increases the speed at which we can report issues.

We would like to give security information back to upstream users because we are responsible open source community members. It's in the spirit of open source to share information openly, and what better forum to share that information than through the CVE Project itself. By only allowing reporting of a vendor's products, we are reducing the usefulness of CVEs.

Only being able to report on downstream software will slow down the speed with which we can report vulnerabilities. We most often learn about vulnerabilities in upstream software which we consume before we check if the vulnerabilities affects the downstream source, because we can distribute the same upstream source in many downstream products. That means we usually known first if upstream is affected, and then only test and report on downstream software.

[jasinner]

I think the use of an 'open source' vendor is the best approach, as it allows open source software uses to search filter the data using that field. Here's a couple of examples:

"affected": {
        "vendors": [
          {
            "vendorName": "open source",
            "products": [
              {
                "productName": "dnsmasq",
                "collectionUrl": "http://www.thekelleys.org.uk/dnsmasq/",
                "versions": [
                  {
                    "versionValue": "2.76",
                    "versionAffected": "<",
                    "references": [
                      {
                        "url": "https://www.jsof-tech.com/disclosures/dnspooq/",
                        "name": "Vulnerabilities threaten DNS integrity (again)",
                        "tags": [
                          "x_.Third Party Advisory"
                        ]
                      }
                    ]
                  }
                ]
              }
            ]
          },
          {
            "vendorName": "Red Hat",
            "products":[
              {
                "productName": "Red Hat Enterprise Linux 7",
                "packageName": "dnsmasq",
                "collectionUrl": "https://access.redhat.com/downloads/content/package-browser",
                "versions": [
                  {
                    "versionValue": "2.76-16.el7_9.1",
                    "versionAffected": "<",
                    "references": [
                      {
                        "url": "https://access.redhat.com/errata/RHSA-2021:0240",
                        "name": "RHSA-2021:0240 - Security Advisory",
                        "tags": [
                          "vendor-advisory"
                        ]
                      }
                    ]
                  }
                ]
              },

      "affected": {
        "vendors": [
          {
            "vendorName": "open source",
            "products": [
              {
                "productName": "hashicorp/go-slug",
                "collectionUrl": "https://github.com",
                "versions": [
                  {
                    "versionValue": "0.4.3",
                    "versionAffected": "<=",
                    "references": [
                      {
                        "url": "https://github.com/hashicorp/go-slug/releases/tag/v0.5.0",
                        "name": "Change the Unpack function to better protect against Zip Slip attacks while unpacking the tarball, addressing CVE-2020-29529",
                        "tags": [
                          "x_.Third Party Advisory"
                        ]
                      }
                    ]
                  }
                ]
              }
            ]
          },
          {
            "vendorName": "Red Hat",
            "products": [
              {
                "productName": "Red Hat Advanced Cluster Management for Kubernetes 2.2 for RHEL 7",
                "packageName": "rhacm2/openshift-hive-rhel7",
                "collectionUrl": "https://catalog.redhat.com/software/containers/explore",
                "versions": [
                  {
                    "versionValue": "v2.2.2-4",
                    "versionAffected": "<",
                    "references": [
                      {
                        "url": "https://access.redhat.com/errata/RHSA-2021:1168",
                        "name": "RHSA-2021:1168 - Security Advisory",
                        "tags": [
                          "vendor-advisory"
                        ]
                      }
                    ]
                  }
                ]
              },

[jasinner]

Perhaps one way to denote the original source verses redistributed software is to add a boolean to the vendor field such as 'isOrigin'?

[iamwillbar]

@jasinner does this run the risk of bypassing the open source project's vulnerability disclosure process opening up the possibility of zero-days? For GitHub-hosted open source we provide a path for open source projects to:

1. Share how vulnerabilities should be reported.
2. Create and collaborate on draft security advisories in private.
3. Publish those security advisories and have a CVE issued.

How can we balance the desire to federate issuing CVEs with the community's own governance?

[jasinner]

I believe CNAs are the only ones able to report directly to mitre in the fashion. There it would be up to the CNA (Red Hat, or GitHub for example) to maintain embargoes, and report vulnerabilities after collaboration with maintainers

[chandanbn]

@jasinner does this run the risk of bypassing the open source project's vulnerability disclosure process opening up the possibility of zero-days?

No. A CNA decides when to populate a CVE record. This typically happens after the issue is fixed and an advisory is out in most cases.

If the open source project is a CNA they manage their publication schedule.

If not, the assigning CNA is incharge.

A CVE assignment requires a public proof in the form for a URL that the CVE is genuine, (but it does not require responsible disclosure).

[chandanbn]

I think the use of an 'open source' vendor is the best approach, as it allows open source software uses to search filter the data using that field. Here's a couple of examples:

 "vendorName": "open source",

That makes the field less useful.

We also want to cover non-open-source products.

[jasinner]

I think the use of an 'open source' vendor is the best approach, as it allows open source software uses to search filter the data using that field. Here's a couple of examples:

 "vendorName": "open source",

That makes the field less useful.

We also want to cover non-open-source products.

I'd be open to using a tag instead. Or some other way to separate upstream software from products. As long as CNA where consistent in how it was used. But we definitely need a way for CNAs to report issues in software they do not sell or distribute themselves. I think for Red Hat 'open source' summarizes those cases quite well, but I'm not sure what over non-open-source software CNAs might want to report on, and how to categorise those.

[tcullum-rh]

I think the use of an 'open source' vendor is the best approach, as it allows open source software uses to search filter the data using that field. Here's a couple of examples:

 "vendorName": "open source",

That makes the field less useful.
We also want to cover non-open-source products.

As long as CNA where consistent in how it was used.

I think we should explore this a bit more (I will mention in QWG). Right now I have no idea what the expectations are for where CNAs are consistent versus where CNAs will deviate (do we want to suggest any particular conventions for areas of the schema in the user guide perhaps?), but I see an increasing number of topics where it would be beneficial for the community to align.

Last meeting, we also discussed an origin boolean field for the original source of software as you mentioned, @jasinner , which can be placed on vendor so at least we know the original source of the software when there are multiple vendors who have the same project listed. I think it was well received. However, I think @david-waltermire-nist suggested using the upstream project/org name as the vendor rather than "open source" generically, and potentially using a tag for this (as you noted as well).

Thanks for your contribution, @jasinner !

[ccoffin]

Discussed this in the September 12, 2024 QWG Meeting. What's the value to CVE consumers?