How to identify version data in VEX profile

[rjb4standards]

I'm trying to understand how to identify an affected version of a particular product. Is there a version element that I can associated with a particular Product. For example, I want to create a VEX that shows Jog4j-core versions 2.14.x - 2.16.0 are affected by CVE-44228. Thanks, Dick Brooks

[tschmidtb51]

Hi @rjb4standards, here is a short excerpt (create with Secvisogram 1.10.0) from the VEX. To avoid confusion and misinformation, I chose different version numbers (copying from Apache):

  // ...
  "product_tree": {
    "branches": [
      {
        "category": "vendor",
        "name": "Apache",
        "branches": [
          {
            "category": "product_family",
            "name": "Logging Services",
            "branches": [
              {
                "category": "product_name",
                "name": "log4j-core",
                "branches": [
                  {
                    "category": "product_version",
                    "name": "2.0-beta9",
                    "product": {
                      "product_id": "CSAFPID-0001",
                      "name": "Apache log4j-core 2.0-beta9"
                    }
                  },
                  {
                    "category": "product_version",
                    "name": "2.15.0",
                    "product": {
                      "product_id": "CSAFPID-0002",
                      "name": "Apache log4j-core 2.15.0"
                    }
                  }
                ]
              }
            ]
          }
        ]
      }
    ]
  },
  "vulnerabilities": [
    {
      "cve": "CVE-2021-44228",
      // ...
      "product_status": {
        "first_affected": [
          "CSAFPID-0001"
        ],
        "first_fixed": [
          "CSAFPID-0002"
        ],
        "fixed": [
          "CSAFPID-0002"
        ]
      },
      "remediations": [
        {
          "category": "vendor_fix",
          "details": "Apache released updates which fix the problem",
          "product_ids": [
            "CSAFPID-0001"
          ]
        }
      ]
    }
  ]
}

Note: The product_family is optional but recommended to be used to ease sorting in human readable documents.

Does that answer the question? I can probably provide a more detailed example after Christmas.

[rjb4standards]

Thomas, one practice that would greatly help correlate VEX with SBOM data is to enumerate each affected product in a VEX using the NTIA SBOM framing group convention for identifying a primary component, which includes SupplierName+ProductName+ProductVersion as assigned by the authorized package supplier within a product SBOM.

[tschmidtb51]

Thomas, one practice that would greatly help correlate VEX with SBOM data is to enumerate each affected product in a VEX using the NTIA SBOM framing group convention for identifying a primary component, which includes SupplierName+ProductName+ProductVersion as assigned by the authorized package supplier within a product SBOM.

Totally agree. That would be done through the product_tree (and not only for affected products but for any product mentioned in the document). See the excerpt below:

  "product_tree": {
    "branches": [
      {
        "category": "vendor",
        "name": "SupplierName",
        "branches": [
          {
            "category": "product_name",
            "name": "ProductName",
            "branches": [
              {
                "category": "product_version",
                "name": "ProductVersion",
                "product": {
                  "product_id": "CSAFPID-0001",
                  "name": "THE HUMAN READABLE NAME"
                }
              }
            ]
          }
        ]
      }
    ]
  }

However, I can't guarantee that every VEX author will enumerate all vulnerable versions :worried: For those ones, who want to provide version ranges the example above is how it should be done currently.

[rjb4standards]

Thanks, Thomas. I suppose we could always do the between check when ranges are used. As long as I have the SupplierName+ProductName+ProductVersion I should be able to locate an SBOM to associate with a VEX.

Thanks for all your help.

[tschmidtb51]

As long as I have the SupplierName+ProductName+ProductVersion I should be able to locate an SBOM to associate with a VEX.

The author of the VEX can directly link in CSAF to the SBOM using the product_identification_helper. Have a look at the following excerpt:

"product_id": "CSAFPID-0001",
        "name": "THE HUMAN READABLE NAME",
        "product_identification_helper": {
          "sbom_urls": [
            "https://example.com/sbom/whatever-url-was-used-for-that-sbom"
          ]
        }

Then, product matching basically becomes the question of match URLs...

[rjb4standards]

Hi Thomas, I'm unable to respond to your email as I'm not authorized to post using my company email address. Here is the problem I encountered trying to use VEX on an SBOM, using Log4j as a use case: The Log4j VEX identifies affected products, which in this case is Log4j-core. I was not able to directly identify which SBOM components were affected by the Log4j CVE, if a Product SBOM does not explicitly list Log4j-core as a component. This led me to create the open-source SBOM Vulnerability Disclosure Report which contains a listing of known CVE's at the SBOM component level. This enables software vendors to associate any CVE with a component, i.e. the Log4j CVE for any SBOM component, regardless of component name, to indicate that exploitable vulnerabilities are possible for the component and product which it is contained in. A sample VDR is available online showing CVE's at the component level for MS PowerToys application at: https://raw.githubusercontent.com/rjb4standards/REA-Products/master/UseCaseVDR117/PToysVDR.xml

[rjb4standards]

Thomas,

Here is a pointer to the open-source SBOM VDR XML schema, version 1.1.7 containing the UnresolvedVulnerabilities and Exploitable flags for rapid risk assessments; https://raw.githubusercontent.com/rjb4standards/REA-Products/master/SAGVulnDisclosure.xsd

[rjb4standards]

Thanks, Thomas.

Thursday, 6.1.22 09:30 EST is good for me. Zoom is preferred, but I'm ok with MS Team or Webex also.

Thanks for sending along the example VEX. This clearly shows that a VEX can be associated with a specific product supplier, product name and product version, which is the "primary key" for an SBOM component. This makes it very easy to correlate a VEX with software product and that's valuable to software consumers. This example also uses the enumeration method to list products, which is the preferred approach to correlate with installed product SBOM's.

But there is still a risk assessment function which VEX is not well suited; here is one use case:

-An alert is issued for Log4j CVE-2021-44228 showing the affected product: Apache Software Foundation, Log4j, 2.13.0

• Apache issues a VEX for Log4j identifying this CVE and this specific product and version

As soon as the CVE and Apache VEX are issued the end user proactively searches their existing SBOM repository of installed products to find affected software products. Affected products are reported by the consumer to the software supplier, requesting action to address the vulnerability. The software vendor issues a Vulnerability Disclosure Report (VDR) in response, identifying the exact SBOM and component that is affected by CVE-2021-44228. The consumer processes the XML VDR artifact to determine the vendors Fix Status, exploitability and findings/analysis with regard to the affected component.

VEX appears to be a many to many cardinality where multiple CVE's can be associated with multiple product entries.

VDR is a one-one cardinality, one VDR is associated with one SBOM, which aligns with the consumers findings during the SBOM search function for a CVE in the above example.