By Puerco Veytia, Alex Goodman, Dan Luhring, and John Speed Meyers
Open source vulnerability scanners now increasingly support OpenVEX, helping open source users reduce the pain of managing vulnerabilities and the burden of false positives. These new integrations with OpenVEX 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 integration, what open source vulnerability scanner support of OpenVEX means, and how 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. This is important for software developers because the status quo of vulnerability management often entails long, custom spreadsheets created in an ad-hoc fashion. This status quo wastes precious development cycles and also impedes organizations, or even teams within one organization, from communicating easily about the status of software vulnerabilities with respect to a piece of software.
OpenVEX is an implementation of VEX. It is not specific to a particular software bill of materials (SBOM) format, has open source libraries and tools that support its use, and a growing community of adopters. It is housed in OpenSSF and supported by a number of companies including Anchore, Chainguard, Intel, Microsoft and others.
OpenVEX is a Special Interest Group (SIG) underneath the OpenSSF Vulnerability Disclosures Working Group. The OpenVEX SIG actively works with the upstream CISA VEX working group to promote the use of VEX in any format.
What does open source vulnerability scanner support of OpenVEX mean for your organization and your developers?
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 to then consume these documents, using for example a tool like Grype, and for your organization to benefit from enriched scanner findings.
For instance, it could be that a scanner 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, the scanner could simply silence this false positive, saving you and your organization the hassle of re-assessing this vulnerability.
Both Grype and Trivy now support ingestion of OpenVEX documents.
How can open source users use OpenVEX?
As an example, this section demonstrates how open source users can use OpenVEX, illustrating how a user can use vexctl to generate an OpenVEX document and how the open source vulnerability scanner Grype can ingest OpenVEX documents.
Let’s start with the motivation. Imagine a user conducts a vulnerability scan and discovers a vulnerability is present.
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 MediumFurthermore, imagine this user knows this vulnerability is a false positive because the vulnerable function is never called. To silence CVE-2014-123456 from the scan results, this demo will create an OpenVEX document with vexctl. You will need several pieces of data to do it:
- The VEX product: This is the 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_affcted to suppress the false positive.
To mark a vulnerability as not_affected, you will also need to provide one of the predefined status justifications. This example uses the vulnerable_code_not_in_execute_path justification. 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 to suppress a vulnerability from the myrepo/test image scan results:
vexctl create \
--vuln=CVE-2014-123456 \
--product='pkg:oci/test' \
--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 reference in –product and the OS package acting as the --subcomponent 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",
"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"
}
]
}As an example of how this can be ingested, 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 can still be displayed by passing –output=json.
Making Vulnerability Management Easier
Vulnerability management has become a source of toil for many software developers, diverting precious time and attention from more valuable tasks. OpenVEX’s integration with open source vulnerability scanners is meant to change this equation, reducing the burden of vulnerability management and allowing developers to focus only on the vulnerabilities that really matter and to ignore the rest.
How to get involved in OpenVEX
For anyone who wants to contribute or get more involved in the OpenVEX community, visit the OpenVEX Community Repository.
About the Authors
John Speed Meyers is the head of Chainguard Labs. He writes, reads, and talks about open source software security. His recent research has focused on the time costs of software vulnerability management, the relationship between open source project funding and security, the efficacy of container debloating technology, and the measurement of SBOM quality.
Dan Luhring is the technical lead for vulnerability management at Chainguard, where he’s focused primarily on finding innovative and sustainable ways of minimizing the CVE count in Chainguard Images. His passion is writing security tooling for software engineers, including his work on creating, launching, and popularizing Syft and Grype.
Adolfo García Veytia (@puerco) is a Staff OSS Engineer at Chainguard Labs where works on advanced SBOM projects and tools. He is also one of the technical leads of the OpenVEX SIG working on the tooling and specs.