VEXed? Then Grype about it: Chainguard and Anchore announce Grype supports OpenVEX

TL;DR Open source vulnerability scanner Grype has added support for OpenVEX, allowing software teams to manage vulnerabilities, especially scanner false positives, with less pain.

‍

Grype, the open source vulnerability scanner from Anchore, has added support for a feature that will reduce the pain of managing vulnerabilities in containers and will particularly help with reducing the burden of false positives. Grype now supports OpenVEX, a standard and tools for machine-readable vulnerability analysis data. The new feature can provide rich context on vulnerabilities in a piece of software, ensuring better scanner results such as a reduced false positive rate.

‍

This post explains the vulnerability exploitability exchange (VEX) and the OpenVEX implementation, what Grype’s support of OpenVEX means, and how Grype users can use OpenVEX to reduce the pain of vulnerability management.

‍

What are VEX and OpenVEX?

A VEX document contains machine-readable statements about the status of software vulnerabilities with respect to a software product. Supported in part by the U.S. Cybersecurity and Infrastructure Security Agency, VEX documents are intended to enable automation of key vulnerability-related tasks, many of which are currently toilsome work for software developers and security engineers.

‍

‍OpenVEX is an implementation of VEX. It is not specific to a particular software bill of materials format, has open source libraries and tools that support its use, and a growing community of adopters. It is housed in the Open Source Security Foundation (OpenSSF) and supported by a number of companies including Anchore, Intel, Microsoft, Chainguard and others.

‍

“The energy, enthusiasm, and industry leadership we see out of the group working behind the VEX format and the OpenVEX projects is amazing,” said Christopher Robinson (CRob), Community Co-Lead at OpenVEX SIG, OpenSSF TAC Chair and Director of Security Communications at Intel. “Puerco (Adolfo García Veytia) and the team really have stepped up to drive these important concepts and helped ensure a simple means for upstream open source to use them and inform their communities about how vulnerabilities affect software!”

‍

What does Grype’s support of OpenVEX mean for your organization?

It means that your organization can now better manage vulnerabilities in your containers and software. By producing OpenVEX documents for your organization’s software or by using OpenVEX documents produced by the organizations that provide your software, it’s possible for Grype to then consume these documents and for your organization to benefit from enriched scanner findings.

‍

For instance, it could be that Grype indicates there is a known vulnerability in the software your organization is using but that your security team (or even your software provider) has assessed it and found it to be a false positive. By encoding this information into an OpenVEX document, Grype could simply silence this false positive, saving you and your organization the hassle of re-assessing this vulnerability.

‍

Savvy Grype users can therefore take advantage of Grype’s ability to cast a wide net and catch all true vulnerabilities while also using OpenVEX to filter out false positives. This is a tradeoff that is much more difficult without OpenVEX.

‍

How should a Grype user use OpenVEX?

This section demonstrates in detail how Grype users can use OpenVEX.

‍

Here’s an example Grype scan of myrepo/test:

grype myrepo/test
 ✔ Scanned for vulnerabilities     [1 vulnerability matches]
   ├── by severity: 0 critical, 0 high, 1 medium, 0 low, 0 negligible
   └── by status:   4 fixed, 0 not-fixed, 0 ignored
NAME   INSTALLED  FIXED-IN  TYPE  VULNERABILITY   SEVERITY
glibc  2.36-r3    2.38-r2   apk   2014-123456   Medium

To suppress 2014-123456 from Grype’s result set, we’ll create an OpenVEX document. You will need a couple of data bits to do it:

• The VEX product: This is your container image

• The VEX subcomponents: these are the components showing up as affected when scanning your image. In our example the affected component is glibc-2.36-r3

• The vulnerability identifier: in CVE-2014-123456

• An assessment of the status of the vulnerability with respect to the product

‍

These data points will be used to assemble a VEX statement, an assertion in time describing how the vulnerability affects (or not) a piece of software.

‍

The VEX statement also requires one of the VEX status flags. There are four status flags in VEX: not_affected, affected, under_investigation, and fixed. In this example we’ll use not_affected to suppress the false positive.

‍

To mark a vulnerability as not_affected, you will also need to provide one of the predefined status justifications. Let’s pick vulnerable_code_not_in_execute_path for this example. Although not required, you should always provide a human readable impact statement for other fellow humans to understand why this is a false positive.

‍

Generate the document using vexctl:

vexctl create \
  --vuln=CVE-2014-123456 \
    --product='pkg:oci/test@sha256%' \
    --subcomponents='pkg:apk/alpine/glibc@2.36-r3' \
    --status=not_affected \
  --justification=vulnerable_code_not_in_execute_path  \
  --impact-statement="The vulnerable function is not called"

Note how the image and OS package are converted into a package URL. The document containing your statement will look like this:

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://openvex.dev/docs/public/vex-ed3fb12bfeeea95f274dcc0a7bbb41d9532f32e8c59de3ed7d83fd5c52c1da8d",
  "author": "Unknown Author",
  "timestamp": "2023-10-04T15:07:43.246099-07:00",
  "version": 1,
  "statements": [
    {
      "vulnerability": { "name": "CVE-2014-123456" },
      "timestamp": "2023-10-04T15:07:43.2461-07:00",
      "products": [
        {
          "@id": "pkg:oci/test@sha256%",
          "subcomponents": [
            { "@id": "pkg:apk/alpine/glibc@2.36-r3" }
          ]
        }
      ],
      "status": "not_affected",
      "justification": "vulnerable_code_not_in_execute_path",
      "impact_statement": "The vulnerable function is not called"
    }
  ]
}

The resulting document can be fed into Grype when scanning the container image to suppress the false positive:

grype myrepo/test --vex=myimage.openvex.json
 ✔ Scanned for vulnerabilities     [0 vulnerability matches]
   └── by status:   0 fixed, 0 not-fixed, 1 ignored

The vulnerability match is gone, but it is still available in Grype’s ignore list. It can be displayed by passing –output=json.

‍

More VEX, more joy

Admittedly, there are still relatively few VEX documents found in the wild. That said, we hope that the Grype’s support of OpenVEX makes the creation of VEX documents more beneficial, allowing Grype users to silence false positives and enhance their vulnerability management.

‍

For users interested in using OpenVEX as part of Grype, check out Grype.

‍

For users interested in zero-know CVE container images, check out Chainguard Images.

‍

‍For anyone that wants to contribute or get more involved in the OpenVEX community, visit the OpenVex Community Repository.