In an enlightening YouTube presentation, Adolfo delved into the fascinating world of VEX and SPDX, detailing the implications of software vulnerabilities and how these can be tracked, assessed, and communicated. Understanding this process is pivotal for tech enthusiasts, software developers, and cybersecurity professionals, as it aids in managing software vulnerabilities efficiently. This blog post aims to break down the key takeaways from this enriching talk.
Understanding VEX
Vulnerability Exploitability Exchange, or VEX, is a pivotal tool used to comprehend the actual impact of a vulnerability on a specific software. As visibility into the software supply chain continues to increase exponentially, so do false positives and other pieces of information that can light up security dashboards. VEX is particularly useful in such scenarios where base images might include unnecessary software that could potentially flag vulnerabilities, affecting software security.
To simplify, let’s consider a hypothetical example of ‘Bob’s browser’, which contains a version of ‘Carl’s compression engine’. If someone finds a CVE (Common Vulnerabilities and Exposures) affecting Carl’s compression engine, Bob’s browser would consequently start getting flagged as vulnerable. The immediate response to this should be issuing an ‘under investigation’ VEX statement to communicate the known impact a vulnerability could have on the software is being researched.
The Role of SPDX
SPDX plays a pivotal role in this scenario by effectively communicating our understanding of a vulnerability’s impact. SPDX, with its multitude of relationships, allows one to comprehend how different elements relate to each other. Security profiles in SPDX supercharge these relationships with more information, thereby conveying the VEX statuses efficiently.
Let’s take our example forward: Bob investigates the CV and realizes his browser is affected. His next step should be to inform people about the impact and offer any advise to mitigate it. The beauty of this system lies in its machine-readability, meaning that when Bob issues an ‘affected’ message, tools can react to it instantaneously by enacting relevant policies while the optional human-readable portions of VEX statements advise people in language anyone can understand
Mitigating Vulnerabilities
In a scenario where Carl is unable to patch the vulnerability in his compression engine, Bob could choose to take action and fix it himself. He releases a new version of his browser with a mitigation for the CVE contained in Carl’s compression engine. Despite this, the CVE might still show up in scanners because, even when Bob mitigated the vulnerability, the affected component is still the same. Bob can then issue a new message stating that although he’s shipping Carl’s compression engine affected by a CVE, he has mitigated it and marked it as ‘not affected’ in the security document of SPDX. VEX has a number of justifications to express why software is not affected, for example inlineMitigationsAlreadyExist would fits this scenario.
The VEX and SPDX Connection
VEX is defined by a working group organized by the Cybersecurity and Infrastructure Security Agency (CISA) from the US. As a ‘spec of specs’, SPDX now joins OpenVEX, CSAF, CDX… as VEX implementations. As of the date of the talk, SPDX and OpenVEX were the only two implementations of VEX meeting the minimum requirements as defined by the working group.
One critical point to note is that VEX is not solely based around a software version; it is built around a “product”. VEX can describe the impact of CVEs or any other vulnerability that can be tracked and is registered in a tracking system. In other words, it provides a more extensive and comprehensive analysis of software vulnerabilities.
The Document Flow
SPDX’s VEX implementation extends the security data that can be expressed in the format beyond the software bill of materials. In addition to the Security Profile’s capabilities to relate a piece of software and a vulnerability, VEX lets authors create machine-readable statements of its effect, resolution, and possible mitigations. Each statement carries a VEX status label describing the impact of the vulnerability on the software product.
In the video, Adolfo describes a process where the original software product, represented by an SPDX document, remains static. This document is essentially a ‘bill of materials’ for the software, detailing all of its components.
For example, let’s take the hypothetical situation in the video involving “Bob’s browser” and “Carol’s compression engine”. If a vulnerability is identified in Carol’s compression engine that affects Bob’s browser, Bob starts an investigation and, if it’s found to impact his software, Bob would issue an ‘affected’ message through a new SPDX document. This document would reference the original SPDX document of Bob’s browser and convey the status of the identified vulnerability in Carol’s compression engine.
The document flow would typically follow this pattern:
1. An original SPDX document is created for a piece of software, detailing all its components: A software bill of materials (SBOM)This remains static once published.
2. If a vulnerability is identified in a component, an investigation is started. An SPDX security document is created to link the vulnerability and the component. The same document can include an ‘under_investigation’ VEX message to let consumers know the impact is being assessed.
3. If the vulnerability impacts the software, an ‘affected’ VEX message is issued in a new SPDX document. This triggers responses from software consumers, like patching or mitigation actions. The document can contain advise to mitigate or upgrade.
4. Once the vulnerability is patched, a ‘fixed’ VEX message is issued in another new SPDX document.
5. Each new SPDX VEX document references the original SPDX bill of materials to specify the software product and the initial SPDX security document when updating the changing status of the vulnerability.
In this way, VEX and SPDX work together to accurately communicate the evolving status of software vulnerabilities and how they impact different software components.
In conclusion, the addition of VEX into SPDX’s Security Profile presents an efficient way to track, assess, and communicate software vulnerabilities and the evolution of their impact. This mechanism provides an expansive coverage, extending beyond the traditional scope of CVEs, thus enabling a more proactive approach towards software security.
