Product-based filtering in vexctl

[ferozsalam]

This ticket is something between a discussion item and a bug report, let me know if there is a better place for it.

vexctl can currently filter out entries from a SARIF file, but it doesn't seem to take into account the value of the products array when doing so.

My expected behaviour would be this:

If I vexctl filter a SARIF against a VEX, and for a given vulnerability ID, a value in the locations array in the SARIF matches a value in the products array of the VEX document, the vulnerability ID should be filtered for that particular result. If there is no match between the locations array in the SARIF and the products array, then the value should continue to be reported.

There are some complexities to this, based on the non-standard way in which the locations array is constructed by different scanners, but I think at a high level the locations field is generally where the product version is found in a SARIF (perhaps exactly which field to use should be a customisable option?).

However the current behaviour is:

If the vulnerability ID is found in the SARIF results array, then the vulnerability is removed, even if the product is not specifically listed in the VEX statement for the vulnerability.

For workflows where a single golden VEX file is used to maintain VEX statements relating to multiple products, this means that adding a VEX statement for any one product automatically removes vulnerability reporting for all of the products that are covered by the VEX document + vulnerability ID combination, even if other products may not have been assessed for that vulnerability ID.

Some samples to illustrate this behaviour – I would assume that running vexctl filter sample.sarif.json vex-sample.json should return 1 result due to the product/artifactLocation mismatch, but the vulnerability is removed.

sample.sarif.json:

{
  "version": "2.1.0",
  "$schema": "https://raw.githubusercontent.com/oasis-tcs/sarif-spec/master/Schemata/sarif-schema-2.1.0.json",
  "runs": [
    {
      "tool": {
        "driver": {
          "name": "scan-tool",
          "version": "2",
          "informationUri": null,
          "rules": [
            {
              "id": "CVE-2023-29405",
              "shortDescription": {
                "text": "CVE-2023-29405 in go (critical)"
              },
              "fullDescription": {
                "text": "Critical severity CVE-2023-29405 found in go version 1.20.4"
              },
              "help": {
                "text": "",
                "markdown": "| CVE | Severity | CVSS | Package | Version | Fix Status | Published | Discovered |\n| --- | --- | --- | --- | --- | --- | --- | --- |\n| [CVE-2023-29405]
(https://nvd.nist.gov/vuln/detail/CVE-2023-29405) | critical | 9.8 | go | 1.20.4 | fixed in 1.20.5, 1.19.10 | 2023-06-08T21:15:00Z | 2023-08-15T16:01:30Z |"
              }
            }
          ]
        }
      },
      "results": [
          {
          "ruleId": "CVE-2023-29405",
          "level": "warning",
          "message": {
            "text": "Description"
          },
          "locations": [
            {
              "physicalLocation": {
                "artifactLocation": {
                  "uri": "my-product:v1.0.0"
                },
                "region": {
                  "startLine": 1,
                  "startColumn": 1,
                  "endLine": 1,
                  "endColumn": 1
                }
              }
            }
          ]
        }
      ]
    }
  ]
}

vex-sample.json:

{
  "@context": "https://openvex.dev/ns",
  "@id": "test",
  "author": "Feroz Salam",
  "role": "vendor",
  "timestamp": "2023-07-04T17:51:12.004221+01:00",
  "version": "1",
  "statements": [
    {
      "vulnerability": "CVE-2023-29405",
      "products": [
        "random"
      ],
      "status": "not_affected",
      "justification": "vulnerable_code_not_in_execute_path"
    }
  ]
}

[puerco]

I agree @ferozsalam . The main problem is that there is no consistency in the data in the SARIF output of the scanners. I was just looking into the output and it varies wildly, The scanned image is in different places in each tool. For example:

Grype has these logicalLocations:

"logicalLocations": [
      {
        "name": "/usr/share/doc/libtiff6/copyright",
        "fullyQualifiedName": "nginx@sha256:13d22ec63300e16014d4a42aed735207a8b33c223cff19627dd3042e5a10a3a0@sha256:4713cb24eeff341d0c36343149beba247572a5ff65c2be5b5d9baafb345c7393:/usr/share/doc/libtiff6/copyright"
      },
      {
        "name": "/var/lib/dpkg/info/libtiff6:amd64.md5sums",
        "fullyQualifiedName": "nginx@sha256:13d22ec63300e16014d4a42aed735207a8b33c223cff19627dd3042e5a10a3a0@sha256:4713cb24eeff341d0c36343149beba247572a5ff65c2be5b5d9baafb345c7393:/var/lib/dpkg/info/libtiff6:amd64.md5sums"
      },
      {
        "name": "/var/lib/dpkg/status",
        "fullyQualifiedName": "nginx@sha256:13d22ec63300e16014d4a42aed735207a8b33c223cff19627dd3042e5a10a3a0@sha256:4713cb24eeff341d0c36343149beba247572a5ff65c2be5b5d9baafb345c7393:/var/lib/dpkg/status"
      }
]

In Trivy, there is a properties section at the end:

      "properties": {
        "imageName": "nginx@sha256:13d22ec63300e16014d4a42aed735207a8b33c223cff19627dd3042e5a10a3a0",
        "repoDigests": [
          "nginx@sha256:13d22ec63300e16014d4a42aed735207a8b33c223cff19627dd3042e5a10a3a0"
        ],
        "repoTags": []
      }

Snyk uses locations:

  "locations": [
    {
      "physicalLocation": {
        "artifactLocation": {
          "uri": "nginx@sha256_13d22ec63300e16014d4a42aed735207a8b33c223cff19627dd3042e5a10a3a0"
        },
        "region": {
          "startLine": 1
        }
      }
    }
  ]

Which flavor of SARIF are you using? Can you post a SARIF sample here? We may be able to support them with custom code for each tool.

[ferozsalam]

Hey @puerco is this something that would be best as a user-configurable option?

On the SARIF question, in my example above I'm using the Prisma Cloud GitHub action, you can see how it inserts image version into the SARIF here. I've provided a sample SARIF in the issue description above, do you need more than that?