The Software Bill of Materials (SBOM) gets stymied by SBOM quality and vulnerability-specific noises. CISA has recommended creating VEX information with Minimum Requirements for Vulnerability Exploitability eXchange to tackle the latter.
The VEX Minimum Requirements document recommends including fields in the VEX embedded in an SBOM or as a stand-alone document.
In an earlier post, we focused on detailing where CycloneDX VEX, OpenVEX, and CSAF stand in relation to the vulnerability disclosure.
In this post, we breakdown the field mappings of Minimum Requirements to CycloneDX VEX and OpenVEX.
Minimum Requirements for VEX
VEX, an acronym for Vulnerability Exploitability eXchange, is a structured data format that facilitates the exchange of vulnerability information between software vendors, security analysts, and consumers. It aims to address the challenges associated with legacy vulnerability advisories, which often lack machine-readability and fail to convey whether a vulnerability is truly exploitable in a given product or environment.
CISA’s Minimum Requirements for VEX document defines the minimum elements independent of VEX format or specification with a focus on machine-readability.
It describes a VEX document divided into VEX document metadata and at least one VEX statement, which in turn consists of Statement metadata, Status, Vulnerability Details, and Product Details.
Document metadata
- MUST include Document ID, one or more Document Version, Author, Timestamp first issued, and Timestamp last updated.
- MAY include Tooling and Author Role
VEX statement metadata
- MUST include Statement ID, Statement Version, Timestamp first issued, Timestamp last updated
VEX statement Product
- MUST include Product ID and Supplier
- MAY include subcomponent ID
VEX statement Vulnerability
- MUST include Vulnerability ID and description
VEX statement Status
- MUST include Vulnerability Status and conditionally MUST include Justification (for Status Not Affected) or Impact Statement (for Status Not Affected but no Justification). It conditionally MUST include an Action Statement for Status Affected.
- MAY include Timestamp of Impact or Action statement and MAY include Status Notes
Minimum Requirements in CycloneDX
CycloneDX included vulnerabilities and their analysis as fields with version 1.4 and expanded them with version 1.5. Therefore, CycloneDX is a natural specification for embedding VEX information with the SBOM.
However, some field mappings might not be obvious at first glance.
Interlynk recommends implementing Minimum Requirements for VEX with CycloneDX as following:
Document metadata
- Document ID: [Required] Serial Number
- Document Version: [Required] Version
- Author: [Required] Metadata Authors
- Timestamp first Issued: [Required] Vulnerability analysis firstIssued (Version 1.5+)
- Timestamp last updated: [Required] Vulnerability analysis lastUpdated (Version 1.5+)
- Tooling: [Optional] Metadata Tools (Note: CycloneDX also has a Vulnerabilities: Tools section, but that is designed to list tools for vulnerability identification and analysis).
- Author Role: [Optional] Unmapped
VEX statement metadata
- Statement ID: [Required] Vulnerabilities Analysis Bom-Ref
- Timestamp first Issued: [Required] Vulnerability analysis firstIssued (Version 1.5+)
- Timestamp last updated: [Required] Vulnerability analysis lastUpdated (Version 1.5+)
VEX statement Product
- Product ID: [Required] Vulnerabilities Analysis Affects Ref
- Supplier: [Required] Components Supplier where Component bom-ref is same as Product ID (Affected Product/Component)
- Subcomponent ID: [Optional] Vulnerabilities Analysis Affects Ref
VEX statement Vulnerability
- Vulnerability ID: [Required] Vulnerability ID
- Vulnerability Description: [Required] Vulnerability Description
VEX statement Status [Required]
- Status “Not Affected”: Vulnerability analysis state: not_affected
- Status “Affected”: Vulnerability analysis state: exploitable
- Status “Fixed”: Vulnerability analysis state: resolved
- Status “Under Investigation”: Vulnerability analysis state: in_triage
- Status Notes: [Optional] Vulnerability analysis detail
VEX statement Justification [Conditionally Required]
- Justification “Component_not_present”: Vulnerability analysis justification: requires_dependency
- Justification “Vulnerable_code_not_present”: Vulnerability analysis justification: code_not_present
- Justification “Vulnerable_code_not_in_execute_path”: Vulnerability analysis justification: code_not_reachable
- Justification “Vulnerable_code_cannot_be_controlled_by_adversary”: Vulnerability analysis justification: requires_environment
- Justification “Inline_mitigations_already_exist”: Vulnerability analysis justification: protected_by_mitigating_control
VEX statement Impact Statement
- Impact Statement: [Conditionally Required] Vulnerability analysis detail (Note: CycloneDX vulnerability>analysis>detail is described as Detailed description of the impact including methods used during assessment. If a vulnerability is not exploitable, this field should include specific details on why the component or service is not impacted by this vulnerability. This matches Impact Statement’s CISA note: For [status] “not_affected”, if [justification] is not provided, then a VEX statement MUST provide an [impact_statement] that further explains how or why the listed [product_id]s are “not_affected” by [vul_id].)
- Impact Statement Timestamp: [Optional] Vulnerability analysis lastUpdated (Version 1.5+)
VEX statement Action Statement
- Action Statement: [Conditionally Required] Vulnerability recommendation (Note: CycloneDX vulnerability>recommendation is described as Recommendations of how the vulnerability can be remediated or mitigated. This matches the Action Statement’s CISA suggested role: For status “affected”, a VEX statement MUST include one [action_statement] that SHOULD describe actions to remediate or mitigate [vul_id].)
- Action Statement Timestamp: [Optional] Vulnerability analysis lastUpdated (Version 1.5+)
Minimum Requirements in OpenVEX
OpenVEX specification was updated alongside the CISA working group writing the Minimum Requirements document, and therefore OpenVEX provides the most direct mapping to the referenced fields.
Document metadata
- Document ID: [Required] @id
- Document Version: [Required] version
- Author: [Required] author
- Timestamp first Issued: [Required] timestamp
- Timestamp last updated: [Required] last_updated
- Author Role: [Optional] role
- Tooling: [Optional] tooling
VEX statement metadata
- Statement ID: [Required] statements:@id
- Timestamp first Issued: [Required] statements:timestamp
- Timestamp last updated: [Required] statements:last_updated
VEX statement Product
- Product ID: [Requirement] products:@id
- Supplier: [Required] supplier
- Subcomponent ID: [Optional] subcomponents:@id
VEX statement Vulnerability
- Vulnerability ID: [Required] vulnerbilities:@id
- Vulnerability Description: [Required] vulnerabilities:description
VEX statement Status [Required]
- Status “Not Affected”: statements:status:not_affected
- Status “Affected”: statements:status:affected
- Status “Fixed”: statements:status:fixed
- Status “Under Investigation”: statements:status:under_investigation
- Status Notes: [Optional] statements:status_notes
VEX statement Justification [Conditionally Required]
- Justification “Component_not_present”: statements:justification:component_not_present
- Justification “Vulnerable_code_not_present”: statements:justification:vulnerable_code_not_present
- Justification “Vulnerable_code_not_in_execute_path”: statements:justification:vulnerable_code_not_in_execute_path
- Justification “Vulnerable_code_cannot_be_controlled_by_adversary”: statements:justification:vulnerable_code_cannot_be_controlled_by_adversary
- Justification “Inline_mitigations_already_exist”: statements:vulnerable_code_cannot_be_controlled_by_adversary
VEX statement Impact Statement
- Impact Statement: [Conditionally Required] statements:impact_statement
- Impact Statement Timestamp: [Optional] statements:impact_statement_timestamp
VEX statement Action Statement
- Action Statement: [Conditionally Required] statements:action_statement
- Action Statement Timestamp: [Optional] statements:action_statement_timestamp
Better utilization of SBOM towards vulnerability management and risk assessment does require baseline machine readability of the VEX document. Therefore, we recommend creating VEX within CycloneDX or OpenVEX using a common agreed-upon convention.
Interlynk is trying to make security disclosure easy, obvious, and automated. We are happy to answer any questions you might have. Feel free to reach out to us at hello@interlynk.io or via interlynk.io.
