By Surendra Pathak, Interlynk
Original post originally appeared on Medium, and has been revised for the OpenSSF.
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 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 CSAF 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, each 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. In contrast, 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 vulnerabilities, 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. There are four implementations of VEX: CSAF, CycloneDX, SPDX and OpenVEX. Examples include CycloneDX 1.4 SPDX 3.0 release candidate, and 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 is an implementation of VEX with a formal schema already in place.
OpenVEX Example
OpenVEX Example (document fragment)
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 the 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 now v0.2.0 as of the first week of September 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:
- 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 assembled with underlying projects, use a tool such as sbom-assemble for assembling and tracking the SBOM for the final product.
- 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.
- Record Vulnerability Status: For each product release, use a system to record the status of key vulnerabilities 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 a 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.
- 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, 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.
- 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.
About the Author
Surendra Pathak is the Founder and CEO of Interlynk – a platform for managing Software Supply Chain security. Surendra has over twenty years of experience leading application, risk, security, and DevOps teams.