Vulnerability Exploitability EXchange (VEX)

Vulnerability Exploitability eXchange (VEX) reports in Black Duck SCA offer a standardized way to communicate the exploitability status of vulnerabilities in your products. These machine-readable reports help organizations efficiently inform stakeholders about whether specific vulnerabilities affect their offerings.

An SBOM (Software Bill of Materials) serves as a static declaration of components in a product release. After release, it's important to determine the exploitability of any vulnerabilities, and VEX reports facilitate this process. While the SBOM content remains unchanged, VEX allows for on-demand updates regarding the status of vulnerabilities for specific project versions.

Important: To take advantage of this feature, you must have Vulnerability Exploitability eXchange (VEX) enabled on your product registration key.

Creating a Project Version VEX Report

Project Version VEX reports focus on vulnerabilities specific to individual project versions, enabling targeted remediation strategies. Use the steps below to generate a VEX report for a specific project version:

  • Log in to Black Duck SCA.

  • Select the desired project name using the Watching or My Projects dashboard.

  • Select the version of the project for which you want to run the report.

  • Select the Reports tab.

  • Select + Create Vulnerability Report → Vulnerability Exploitability EXchange (VEX): CSAF 2.0.

  • Optionally, you may select Include Vulnerability Comments to include user-generated comments under vulnerability remediation options.

  • Select Create to generate the report.

    The following links appear when the report completes:

    • csaf-report_YYYY-MM-DD_HHMMSS (time stamp in system timezone) for a global version of the report.

  • Select the link to view the report.

VEX Report Format

The VEX report utilizes the CSAF 2.0 (profile 5) format, aligning with industry standards for vulnerability reporting. It clearly indicates which products are unaffected by vulnerabilities, making it a valuable resource for product security teams. This feature facilitates effective communication about security risks, enabling organizations to address customer inquiries and maintain a robust security posture.

Reports will be generated in JSON format, implementing only the minimum required elements for CSAF v2, profile 5. Each report will include entries for CVEs or BDSAs within the selected projects that have one of the following BD status values:

  • Under Investigation

  • Needs Review

  • Known Affected

  • Known Not Affected

  • Remediation Required

  • Remediation Complete

VEX Document Metadata

The VEX report includes essential metadata that is automatically populated and structured according to the CSAF 2.0 specifications. Below are the key elements of the VEX document metadata:

  • Document metadata

    • CSAF Version: Set to 2.0 (cannot be modified).

    • Category: Set to csaf_vex (cannot be modified).

    • Publisher

      • Category: Set to vendor (cannot be modified).

      • Name: Use the value from the existing Project Group SBOM Creator Organization field. If this field is set to the default value of "COMPANY NAME," a warning will be generated indicating that the default value is being used and should be changed. Users will have the option to Cancel or Continue:

        • Cancel: Returns to the report generation screen.

        • Continue: Generates the report using "COMPANY NAME" as the publisher name.

      • Namespace: A new text field will be added under the "Person" field in the Project Group SBOM fields for the Namespace. SBOM generation will utilize the BD namespace value to populate the namespace field in the SBOMs (for applicable SPDX/CycloneDX versions).

    • Title: Defined by Black Duck and currently not modifiable. The title will read: "Vulnerability status report using the CSAF 2.0 Profile 5 specification."

    • Tracking

      • ID: The ID will be the CSAF document filename (e.g., csaf-report_all_projects_2025-07-22_143038). The VEX Product ID can be configured in SBOM Fields.

      • Current Release Date: The date/timestamp of report generation (UTC).

      • Initial Release Date: The timestamp of report creation.

      • Revision History: One entry will be added for the current (latest) information:

        • Date: Report generation date/timestamp (UTC).

        • Number: Hardcoded value of 1 for the version.

        • Summary: Either "Latest information" or "Initial," depending on whether tracking both is necessary.

      • Version: Hardcoded value of 1 for the version.

      • Generator Information:

        • Date: Report generation date/timestamp (UTC).

        • Engine:

          • Name: "Black Duck HUB"

          • Version: The version of Black Duck HUB used to generate the report.

      • Status: Set to draft. (Note: Future support may be added for final and interim options, as referenced in section 3.2.1.12.7 of the CSAF 2.0 specification.)

    • Product Tree: The product_tree section of a VEX report in SCA provides a hierarchical representation of the products that are affected by a specific vulnerability. It is structured to illustrate the relationships between different product versions and their corresponding product names.

      • Branches: The product_tree consists of branches that represent different levels of the hierarchy. Each branch can contain further branches, allowing for a nested structure that captures the relationship between parent products and their versions.

        • Category: Each branch includes a category that defines the type of information it represents. In the example provided, categories might include "product_name" and "product_version."

        • Name: The name of the product or product version.

        • Product: Each product branch contains relevant details such as:

          • Name: The name of the product or product version.

          • Product ID: A unique identifier for the product, which helps in distinguishing it from other products within the tree.

    • Vulnerabilties: The Vulnerabilities section details specific vulnerabilities identified within the software components. This section is essential for understanding the security posture of the application and the associated risks.

      • CVE Identifier: If the vulnerability is a CVE, it is listed with its unique CVE ID (Common Vulnerabilities and Exposures). This identifier allows for easy tracking and reference to the vulnerability in external databases.

        • Notes: Accompanying each CVE entry are detailed notes that provide descriptions of the vulnerabilities. These descriptions explain the nature of the vulnerability, its potential impact, and any relevant technical details.

          • Category: Defines the type of note.

          • Text: The actual free-form text providing the information. If there is a related EUVD ID associated with this CVE, it will be displayed here.

        • Product Status: This section is essential for users to understand the current state of the products affected by vulnerabilities. It provides transparency regarding ongoing assessments and remediation efforts, helping organizations prioritize their actions to maintain security.

        • Scores: This section provides critical information regarding the severity of the identified vulnerabilities, utilizing the Common Vulnerability Scoring System (CVSS).

      • IDs: If the vulnerability has a BDSA ID, it will be found in this section.

    • Distribution

      • TLP:

        • Label: TLP label associated with the component version.

  • Notes: Provides additional information about the document itself. This can include general descriptions, frequently asked questions, summaries, or legal disclaimers.

    • Category: Note type identifier. Displays legal_disclaimer if the project group has a VEX Legal Disclaimer.

    • Text: The actual content of the legal disclaimer. Free-form text containing legal terms, conditions, limitations, and protections as defined by the organization.