7 min readJun 26, 2023
Photo by Nathan Dumlao on Unsplash

Software transparency has been getting a much-needed and long-awaited push. The Software Bill of Materials (SBOM) aims to become the key artifact for software transparency and vulnerability coordination within and across organizations. As SBOM formats pack necessary details, including software components and their origins, a good SBOM can be used to track and monitor known vulnerabilities in the software.

SBOM Component list can be used with Vulnerability Databases (e.g., NVD) to create a vulnerability list for the product

However, SBOM alone may not encode enough detail to separate non-exploitable vulnerabilities from exploitable ones. This can lead to a new stream of noise in an already noisy environment of security data points.

Early adopters of SBOM have understood this and have proposed new standards as well as updates to existing standards to specify the status of each vulnerability alongside the SBOM itself. In this context, existing practices such as VDR, CSAF, and emerging standards VEX and OpenVEX are playing a key role.

VDR: Vulnerability Disclosure Report

VDR is the list of known vulnerabilities published by the software vendor. A typical document lists vulnerabilities, associated CVE, CVSS, Impact, Timeline, and mitigation strategies, along with the contact information within the vendor. The VDR is not designed for programmatic consumption, and the actual format (HTML, Excel, PDF, CSV) may vary by organization.

Sample Vulnerability Disclosure Report at Invicti

NIST-800–161r1: Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations recommends the following role for VDR to demonstrate a detailed understanding and proactive management of vulnerabilities.

Enterprises, where applicable and appropriate, may consider providing
customers with a Vulnerability Disclosure Report (VDR) to demonstrate
proper and complete vulnerability assessments for components listed in
SBOMs. The VDR should include the analysis and findings describing the
impact (or lack of impact) that the reported vulnerability has on a
component or product. The VDR should also contain information on plans
to address the CVE. Enterprises should consider publishing the VDR
within a secure portal available to customers and signing the VDR with
a trusted, verifiable, private key that includes a timestamp indicating
the date and time of the VDR signature and associated VDR. Enterprises
should also consider establishing a separate notification channel for
customers in cases where vulnerabilities arise that are not disclosed
in the VDR. Enterprises should require their prime contractors to
implement this control and flow down this requirement to relevant
sub-tier contractors.

VDR reports known vulnerabilities with the product but has no direct relationship with the SBOM

While, in theory, VDR can describe the status of each vulnerability, the lack of a common reporting standard makes it less practical for programmatic consumption and, therefore, a bottleneck in vulnerability exploitability assessment.

VEX: Vulnerability Exploitability eXchange

The concept of VEX evolved within the same NTIA multistakeholder group that formalized SBOM recommendations into SBOM Framing and SBOM Minimum Elements. VEX is not formalized yet, but its proposition aims to share an assertion about the status of a vulnerability in specific products or versions. The status can be — Not Affected, Affected , Fixed , Under Investigation.

VEX: Single Document covering Multiple Products, Multiple Vulnerabilities, Multiple Statuses

Earlier this year, the working group also agreed upon the Minimum Requirements for VEX, where each VEX document is described as a set of VEX statements, with each statement carrying one status for one vulnerability.

VEX Document and Statements from Minimum Requirements for VEX

In other words, when SBOM and VEX are used together, a well-described SBOM can be mapped to components and possible vulnerabilities, while VEX can be used to apply to reduce the number of truly applicable vulnerabilities. One community member had nicely described it as “First, SBOM turns on all relevant lights, and VEX turns off all the unnecessary ones.”

VEX Varieties: VEX1 embedded in SBOM to turn off some statuses, VEX2 released later to turn off newly discovered vulnerability, VEX3 released later to declare work in progress for a different vulnerability

Although not strictly necessary, a VEX document is intended to be a direct companion to the SBOM. VEX can be directly embedded in CycloneDX 1.4 and is included in the Security profile of the SPDX 3.0 release candidate. VEX is also a profile in CSAF version 2.0 (See CSAF below).

OpenVEX: Open Vulnerability Exploitability eXchange

OpenVEX is an implementation of VEX designed to be interoperable and embeddable. While VEX, in principle, provided a mechanism for communicating the status of vulnerabilities alongside the SBOM itself, the embedding of these statuses was not possible outside of CycloneDX or CSAF. OpenVEX aims to be agnostic to the SBOM specification and acts as an alternative to VEX with a formal schema already in place.

OpenVEX Example

CSAF: Common Security Advisory Framework

OASIS CSAF is an open specification for the “creation, update, and interoperable exchange of security advisories as structured information on products, vulnerabilities, and the status of impact and remediation.”

In other words, CSAF makes disclosure of vulnerabilities and their impact programmatically accessible. However, CSAF aims to be significantly more than vulnerability disclosure and coordination. As of version 2.0, approved in November 2022, CSAF supports five different Profiles:

  • CSAF Base (defaults)
  • Security incident response (for security incidents such as leaks)
  • Information Advisory (for non-vulnerability information such as misconfiguration)
  • Security Advisory (for vulnerability information)
  • VEX (for vulnerability exploitability information)
A CSAF Advisory from RedHat declaring Vulnerability in OpenShift

Best Practices

Vulnerability Disclosure through VDR is a well-established practice, and CSAF has been improving since 2017 as well (e.g., Red Hat CSAF). VEX and OpenVEX aim to be a direct companions to SBOM to control the vulnerability noise. However, there is no formal specification for VEX (besides the CISA examples), and OpenVEX is still v0.0.0 as of the end of June 2023. In other words, vulnerability status disclosure alongside SBOM remains an active area.

At Interlynk, we recommend the following processes to demonstrate the best security practices and limit the vulnerability noise in the organization:

  1. Build SBOM per release: Many SBOM generator tools, including open-source ones, can generate SBOM from dependency graphs, CI/CD, image scans, or software composition analyses. For products that are assembled with underlying projects, use a tool such as sbom-assemble for assembling and tracking the SBOM for the final product.
  2. Store and track SBOM: While it is possible to get some value from SBOMs through tools such as sbom-grep, a formal system (such as SBOM Link) can make connecting SBOM to known vulnerabilities effortless and keep the artifacts preserved for the future.
  3. Record Vulnerability Status: For each product release, use a system to record the status of key vulnerabilities as identified by the SBOM analysis. The definition of key vulnerability will vary by the scope of the application and the organization’s risk tolerance. However, at a minimum, organizations should prepare to have record for vulnerabilities reported as Critical or High. The end goal should be to capture the state of each key vulnerability in a single and spec-agnostic place. This will facilitate translation to standards such as CycloneDX VEX, OpenVEX, and SPDX3.0 or CSAF as needed.
  4. Release Product with SBOM AND Vulnerability Statuses/VDR: A product release including SBOM should also include a Vulnerability Status document. An SBOM without the Vulnerability Status disclosure is likely to create unnecessary noise. If the organization produces security advisory via CSAF, then it is an excellent place for Vulnerability Status Disclosures. If not, then statuses can be embedded in CycloneDX 1.4, SPDX 3.0 (Coming soon), or included alongside SBOM with OpenVEX.
  5. Release VEX for newly discovered vulnerabilities: If a newly reported vulnerability applies to a previously released product, one or more new VEX must be generated to record the analysis of the vulnerability against the product. We recommend starting with ‘Under Investigation’ asap and updating as the vulnerability’s scope is found. Note that we DO NOT recommend generating Vulnerability Status for all newly reported vulnerabilities. Instead, we recommend focusing on Vulnerabilities that are discovered in one of the components included in the SBOM previously released. This is why Storing and Tracking SBOM is a vital part of the practice.

Software transparency via SBOM has the potential to bring much-needed attention and resources to security practices during development. However, vulnerability management has been a resource-intensive problem even before SBOM became part of the conversation. VEX and related specifications aim not to cause additional stress on the security teams and turn off unnecessary alerts. This remains a work in progress, but organizations can still build robust practices around it to minimize distractions.




Enabling Transparency and Compliance in the Software Supply Chain. Reach us at https://interlynk.io