You probably have heard about software bill of materials (SBOMs) and the importance of knowing what software components are running in the applications and systems that you use (and what potential security vulnerabilities affect those components). I also recently published a video talking about the Common Security Advisory Framework (CSAF). Ok, but how do all these work together?
Let me try to explain this with stick-figures and high-level diagrams. Let’s say a user (Omar) purchases a product (Product X) from a vendor. Today’s applications and systems are built using numerous open-source and/or commercial software components. Omar wants to know what open-source or commercial software is used in Product X.
Omar is provided with an SBOM. There are different methods that can be used to distribute an SBOM, but I will keep things simple for now. The two “most popular” or “widely-adopted” SBOM machine readable formats are:
- Software Package Data Exchange (SPDX®): an ISO/IEC standard introduced as a Linux Foundation Project.
- CycloneDX: a lightweight SBOM specification and an open-source OWASP
standard.
Note: Check out the “Survey of Existing SBOM Formats and Standards”, created by the NTIA and other collaborators, to learn more about how these standards (along with others) are used in the industry.
No software is immune to security vulnerabilities. Each of these software components can be affected by different security vulnerabilities. Subsequently, the user wants to if any of these components are affected by any security vulnerabilities.
The Vulnerability Exploitability eXchange (VEX) allows a software supplier or other parties to assert the status of specific vulnerabilities in a particular product. As documented in the NTIA’s one-page VEX overview document, VEX can have any of the following “statuses”:
- Not affected: No remediation is required regarding this vulnerability.
- Affected: Actions are recommended to remediate or address this vulnerability.
- Fixed: Represents that these product versions contain a fix for the vulnerability.
- Under Investigation: It is not yet known whether these product versions are affected by the vulnerability. An update will be provided in a later release.
VEX information can be included in the SBOM (SPDX or CycloneDX) document at the time of creation. However, new vulnerabilities are found and disclosed on a regular basis.
This is why the CSAF VEX documents are so important! Any software supplier or other parties can assert the status of specific vulnerabilities in a particular product using the CSAF VEX profiles. The OASIS CSAF TC GitHub Repository includes several examples of CSAF / VEX documents (security advisories). Many vendors (i.e., Cisco, Red Hat, TIBCO, Oracle, Siemens, etc.), CERTs and government institutions (i.e., BSI, CERT@VDE, CISA, etc.) are now consuming and/or producing CSAF security advisories. It is expected that all these standards and formats will see significant adoption by most vendors, software providers, and consumers of technology.
Again, VEX allows a software supplier, provider, vendor, or other parties to assert the status of specific vulnerabilities in a particular product.
VEX information can be included in a Software Package Data Exchange (SPDX®) or CycloneDX SBOM document. However, as I explained in the previous article the VEX information in an SBOM document is “point-in-time” and becomes obsolete as more vulnerabilities are disclosed, fixed, and investigated. CSAF allows to provide a real-time status of the investigation and disposition of a vulnerability (under investigation, affected, not affected, or fixed). You can provide up-to-date VEX information via an application programming interface (API), via a ROLIE feed (see RFC 8322), or rendered/displayed in a web portal, as shown below:
A traditional CSAF security advisory can address one vulnerability or multiple vulnerabilities:
A CSAF VEX advisory can provide the status of one vulnerability in one product, as shown below:
A CSAF VEX advisory can also provide the status of multiple vulnerabilities that may affect/not affect a product:
The OASIS CSAF Technical Committee (TC) provided several examples of CSAF VEX documents in their GitHub repository. These examples were contributed by the German Federal Office for Information Security — BSI. The following are a few of their examples and use cases:
- Use case 1: Disclosing known affected vulnerabilities
- Use case 1: Disclosing fixed vulnerabilities
- Use case 1: Confirming not affected
- Use case 1: Vulnerability under investigation
- Use case 2: Confirming not affected
- Multiple vulnerability statuses
- Example VEX Document Use Case 4
- Example VEX Document Use Case 5
- Example VEX Document Use Case 6
- Example VEX Document Use Case 7
- Example VEX Document Use Case 8
- Example VEX Document Use Case 9
- Example VEX Document asserting that Secvisogram is not affected by Log4Shell
The CSAF VEX compliments SBOMs and can be used to provide the most up-to-date status of a given vulnerability in a product or multiple products. It can also be used to provide the status of multiple vulnerabilities in a single product.