You’ll Soon Be Using Vulnerability Exploitability eXchange
With VEX, you can use SBOMs to help secure your code.
The good thing about software bill of materials (SBOM), pronounced SBOMB — is they show you a complete inventory of your application’s open source components. That’s great, but as you examine all those bits and pieces, you’ll find many potential vulnerabilities. That’s great, but how can you tell the difference between killer holes and weak spots that could matter less? That’s where Vulnerability Exploitability eXchange (VEX) comes in.
Get VEXxed
VEX is a Cybersecurity and Infrastructure Security Agency (CISA) working specification. It’s meant to be a kind of 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.
Put it all together, and the US National Telecommunications and Information Administration (NTIA), says VEX provides users (e.g., operators, developers, and services providers) additional information on whether a product is impacted by a specific vulnerability in an included component and, if affected, whether there are actions recommended to remediate.” The plain English version provides security data and context for the security vulnerabilities found in your components.
The ultimate goal is to support greater automation across the software development pipelines and vulnerability tracking, disclosure, and remediation ecosystem. With VEX, you’ll be able to spot the affected vulnerabilities while letting them ignore component vulnerabilities that aren’t exploitable. This way, you can fix the problems that matter while leaving aside the ones that don’t.
Now, it’s not perfect. You shouldn’t blindly trust VEX. But, it makes it much easier to make informed decisions about your code’s security concerns.
Chainguard Impact
As Chainguard software staff engineer Adolfo García Veytia put it, “While having a list of all software contained in an application package is great, the reality is that a vulnerability found in a component may not necessarily affect the application packaging it. Alerting on these false positives reduces the value of alerts themselves, but it also means that as SBOMs get better and better, the frequency of these false positives increases, causing even more noise.”
For instance, Veytia noted, “a project may work around an old, known but unpatched security issue by adding mitigations in the app code. Libraries sometimes have huge codebases, and it could be the case that an application simply doesn’t trigger the parts of the code where the flaw lives or that there may not be a way for adversaries to trigger the vulnerable code.”
Of course, you can look all that up. For example, Quarkus, the Java framework tailored for Kubernetes, wasn’t affected by the Apache Log4j2 CVE-2021-44228 bug. But, to know that, you’d need to have read Quarkus is not affected by the Log4J Vulnerability. Code security scanners and automated policy tools don’t read security blogs. The result? Your SBOMs and scanners can send you on a wild goose chase. But, by making this kind of information machine-readable VEX-capable scanners will be able to cut down on false positives.
CSAF
How does VEX get its vulnerability data? It does so via Common Security Advisory Framework (CSAF). 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.
CSAF also provides tooling such as CSAF Parser, Visualizer, Trusted Provider, and Aggregator. These can help adopters make good use of CSAF so they can incorporate it into VEX and other security vulnerability management tools.
It’s still the early days for the CSAF and VEX pairing. Programs that support it so far include Chainguard Command Line Interface (CLI) tool vexctl and CycloneDX‘s BOM. I expect soon to see many other companies supporting VEX. It just makes too much sense not to be widely adopted.
Managing security in our development pipelines today is a nightmare. By automating security basics checks and balances, VEX will go a long way to making it a much more pleasant dream, while speeding up the whole process.
