Combining SBOMs With Security Data: Chainguard’s OpenVEX

Software Bills of Materials tell you what code is in a program. Chainguard’s OpenVEX will tell you what’s wrong and what’s not quite right, but OK in your code.

Chainguard is already a security programming leader, and now it’s taking another step forward by adding support for Vulnerability Exploitability eXchange (VEX) to . This draft implementation is called OpenVEX.

Vexxed?

VEX, you ask? It’s a new Cybersecurity and Infrastructure Security Agency (CISA) working specification. It’s meant to be a machine-readable security advisory. As such, it’s integrated into existing security management tools and broader vulnerability tracking platforms. VEX data is integrated with SBOM data. You can do this by representing VEX data inside an existing SBOM, or within a dedicated VEX SBOM.

Within VEX records, you’ll find the following elements:

• VEX metadata includes VEX format identifier, identifier string for the VEX document, author, author role, and timestamp.
• Product details must include an identifier or family identifier. For example, a unique identifier or a combination of supplier name, product name, and version string.
• Vulnerability details include the vulnerability data, such as its Common Vulnerabilities and Exposures (CVE) and vulnerability description.
• One of four Product Vulnerability Status notifications:
  •  Not Affected:  No remediation is required regarding this vulnerability.
  • Affected: Actions are recommended to remediate or address this vulnerability.
  • Fixed: These product versions contain a fix for the vulnerability.
  • Under Investigation: It is not yet known whether the vulnerability affects these product versions. An update will be provided in a later release.

VEX gets its vulnerability data from the Common Security Advisory Framework. This is an OASIS reference that describes the creation, update, and interoperable exchange of security advisories as structured data on products, vulnerabilities, and the status of impact and remediation. This information is shared in JSON.

OpenVEX

Chainguard has taken the next logical step and has released an OpenVEX specification and reference toolchain. The company didn’t do it all on its own. It developed it with the support of several industry leaders, including Anchore, HPE, Google, TestifySec, VMware, and The Linux Foundation.

VEX has also been championed by the United States National Telecommunications and Information Administration and supported by the CISA. The goal of VEX is to improve the ability of organizations to identify and mitigate critical security threats.

Complementary Tools

OpenVEX is complementary to SBOM tools, allowing suppliers to communicate precise metadata about the vulnerability status of products directly to consumers and end-users. It was developed in collaboration with CISA’s VEX Working Group and is the first format to meet the VEX minimum requirements.  Chainguard has also put OpenVEX into production in its Wolfi Linux (un)distribution and Chainguard Images product.

The OpenVEX specification enables developers to communicate precise, actionable metadata to improve the signal-to-noise ratio for consumers of their software. OpenVEX makes it easy for software producers to describe their artifacts’ exploitability accurately.

And, just as importantly, OpenVEX makes it easier for software consumers to filter out false positives from vulnerability scanners. This means security professionals spend more time investigating worthwhile security concerns and less time weeding through erroneous findings. OpenVEX encodes false positives and enables consumers to prioritize vulnerability reports much more effectively.

That’s important because, according to Phil Venables, Google Cloud’s chief information security officer,  our increased knowledge of problems can lead to an “uncanny valley” of minor security problems. Lacking context, these minor problems can appear much larger than they are, leading folks to assume their code’s security has gotten worse.

The movement to provide SBOMs will dramatically increase transparency throughout the software supply chain. Forward-thinking organizations have realized that while transparency is great, noise in the vulnerability ecosystem will hamper SBOMs’ adoption and usefulness.

OpenVEX allows developers to generate VEX data for Wolfi packages using the distro’s companion tool, wolfictl. Users can also filter out noise, like false positives, from scanner results with VEX data using vexctl’s filtering feature.

Getting Started

You can start today with OpenVEX using the following steps:

• You can scaffold new documents using `vexctl create`, which creates new vex documents from the command line.
• Beginning upstream, you can produce VEX data for Wolfi packages using the distro’s companion tool `wolfictl.` Generate a VEX document for a Wolfi package using `wolfictl vex package -h`, or for an entire SBOM of Wolfi packages using `wolfictl vex sbom -h`.
• You can assemble VEX data from existing vex sources using `vexctl`’s merge feature.
• And most importantly, you can filter out noise, like false positives from scanner results, with VEX data using `vexctl`’s filtering

End Result

The end result is that OpenVEX has simplified the remediation process for software vulnerability management. This is still a work in progress. We’ll need to work together to build formats and tooling that can be easily integrated into existing development practices.

OpenVEX is being released and maintained out in the open to encourage collaboration and simplify the remediation process for all stakeholders. Eventually, the combination of SBOM and VEX will lead to building programs faster and more securely than ever.

As Ariadne Conill, Chainguard’s principal software engineer, put it, “managing vulnerability sprawl in software distributions is a significant challenge, as each vulnerability has to be researched by security teams to determine whether they are applicable to the versions present in the software distribution.

“The launch of OpenVEX allows all stakeholders, from the upstream developer to distributions and end users, to collaborate together on vulnerability remediation anywhere software is consumed, simplifying the remediation process for everybody.”