Chapter 2. Analyze CVE risk with Exploit Intelligence


Submit analysis requests by using Software Bill of Materials (SBOM) files, direct repository URLs, or RPM packages, then review the generated exploitability reports and VEX documents.

2.1. Submit SBOM analysis

Submit a CycloneDX Software Bill of Materials (SBOM) file with CVE identifiers to analyze exploitability based on your application’s actual code usage. Use this workflow when analyzing specific CVEs affecting individual application components with a pre-generated SBOM.

Prerequisites

Prerequisites

  • An SBOM file in JSON format that meets the following requirements:

    • For multi-component product analysis: SPDX 2.3 with the following requirements:

      • spdxVersion must be SPDX-2.3.
      • A DESCRIBES relationship identifying the product package.
      • The product package must have a name.
      • Components must be linked via PACKAGE_OF relationships.
      • Each component must have an OCI package URL (pkg:oci/) in externalRefs.
      • At least one valid OCI component is required.
    • For single-component analysis: CycloneDX 1.6 with the following requirements:

      • bomFormat must be CycloneDX.
      • specVersion must be 1.6.
      • metadata.component must be present and have a non-empty name.
      • A components array must be present.
  • Source code metadata must be carried in metadata.properties as name-value pairs, including the source repository URL and commit hash or tag. For Syft-generated SBOMs, source code metadata properties use the syft:image:labels prefix. Exploit Intelligence accepts both prefixed and unprefixed property names.
  • Authenticated access to Exploit Intelligence UI or API.
  • A Git repository accessible to Exploit Intelligence, either publicly or through configured access tokens.
  • An Exploit Intelligence cluster with all core services running.
  • MongoDB 8.0 or later configured for report storage.
  • MinIO or S3-compatible storage configured for artifact retention.

Procedure

  1. Open the Exploit Intelligence application, select Home from the left menu, click Request Analysis, and then select the SBOM option.
  2. Enter the required fields:

    CVE ID
    CVE identifiers to assess (for example, CVE-2024-50602)
    SBOM file

    Upload your SBOM file by dragging and dropping or clicking Upload

    Note

    Supported formats: SPDX 2.3 (multi-component) or CycloneDX 1.6 (single-component).

    Accepted file type: JSON.

  3. Optional: Enable the Private repository toggle if the source repository referenced in the SBOM metadata requires authentication.
  4. Click Submit Analysis Request.

    The client-side throttling checks queue capacity. If the queue is full, your request queues until capacity is available. The Nginx gateway caches duplicate requests to improve performance.

    The engine runs code evaluation and generates exploitability verdicts and evidence. If you have enabled contextual CVSS, recalculation occurs.

  5. Open the Exploit Intelligence web application and click on Reports to view the analysis report.

    Note

    If analysis shows a Failed status, this might indicate invalid input data. For example, when analyzing RPM packages, ensure that you use the correct N-V-R (Name-Version-Release) syntax.

2.2. Submit repository analysis

Analyze CVEs directly from source code by providing a Git repository URL and commit identifier instead of a pre-generated Software Bill of Materials (SBOM). Use this workflow when analyzing CVEs directly against source code without a pre-generated SBOM, or when testing unreleased code.

Prerequisites

  • You have authenticated access to Exploit Intelligence UI or API
  • Exploit Intelligence cluster deployed with all core services running
  • You have MongoDB 8.0 or later database configured for report storage
  • MinIO or S3-compatible storage configured for artifact retention
  • Git repository is accessible to Exploit Intelligence (public or private with configured access tokens)

Procedure

  1. Open the Exploit Intelligence application, select Home from the left menu, click Request Analysis, and then select the Single Repository option.
  2. Enter the required fields:

    CVE ID
    CVE identifiers to assess (for example, CVE-2024-50602)
    Source Repository
    Full Git repository URL (for example, https://github.com/org/repo)
    Commit ID
    Specific commit identifier for analysis snapshot (for example, v1.0.0 or full commit SHA f76b3537930637666e7be800008f69731ea642d)
  3. Optional: Enable the Private repository toggle if analyzing a private repository that requires authentication.
  4. Optional: Expand Advanced options to configure additional settings:

    Manifest path
    Path to the dependency manifest file (for example, services/api/go.mod)
    Programming language
    Select the primary programming language from the dropdown
  5. Click Submit Analysis Request. The system validates repository accessibility and queues the analysis.

Verification

  1. Navigate to the Reports page to view the analysis report.

    The report includes:

    Exploitability verdicts
    Classification for each CVE
    Evidence summaries
    Detailed reasoning
    Vulnerable component information
    Dependency tree location
    Justification categories
    Reasoning for non-exploitable classifications
    VEX output
    CSAF 2.0 document

2.3. Submit RPM analysis

Analyze CVE exploitability for RPM packages by providing the package name, version, release, and architecture. Use this workflow when analyzing CVEs affecting specific RPM packages without a pre-generated Software Bill of Materials (SBOM).

Prerequisites

  • You have authenticated access to Exploit Intelligence UI or API
  • Exploit Intelligence cluster deployed with all core services running
  • You have MongoDB 8.0 or later database configured for report storage
  • MinIO or S3-compatible storage configured for artifact retention

Procedure

  1. Open the Exploit Intelligence application, select Home from the left menu, click Request Analysis, and then select the RPM option.
  2. Enter the required fields:

    CVE ID
    CVE identifiers to assess (for example, CVE-2024-50602)
    Package N-V-R

    Package name, version, and release in N-V-R format using hyphens as separators (for example, openssl-3.0.7-5.el9)

    Note

    Use hyphens between the package name, version, and release (N-V-R). The format is critical for proper analysis.

    Architecture
    Select the target architecture from the dropdown (for example, x86_64, aarch64, ppc64le, s390x)
  3. Click Submit Analysis Request.

    The client-side throttling checks queue capacity. If the queue is full, your request queues until capacity is available. The Nginx gateway caches duplicate requests to improve performance.

    The engine runs code evaluation and generates exploitability verdicts and evidence. If you have enabled contextual CVSS, recalculation occurs.

  4. Open the Exploit Intelligence web application and click on Reports to view the analysis report.

    Note

    If analysis shows a Failed status, verify the following:

    • The N-V-R format uses hyphens (not spaces or other separators)
    • The package name, version, and release match an existing RPM package
    • The architecture is appropriate for the package

Verification

  1. Navigate to the Reports page to view analysis results.
  2. Verify the report includes:

    Exploitability verdicts
    Classification for each CVE
    Evidence summaries
    Detailed reasoning
    Vulnerable component information
    RPM package details
    Justification categories
    Reasoning for non-exploitable classifications
    VEX output
    CSAF 2.0 document

2.4. Review analysis reports

Access completed analysis reports to review exploitability verdicts, evidence details, and download VEX documents.

Prerequisites

  • You have submitted an SBOM or repository analysis request.
  • The analysis has completed and the status badge shows a final state (Vulnerable, Not vulnerable, Uncertain, or Failed).

Procedure

  1. Log in to the Exploit Intelligence browser interface.
  2. In the left navigation panel, click Reports.
  3. Select the analysis type tab:

    SBOMs: View reports for Software Bill of Materials analysis

    Single Repositories: View reports for individual repository analysis

    RPM: View reports for RPM package analysis

    1. (Optional) Filter and search the reports:

      • Click the Repository Name dropdown to filter by repository
      • Use the search field to search by repository name
      • Use the pagination controls to navigate between pages
  4. Review the analysis results table:

    The table displays the following information for each analysis:

    ID: Unique identifier for the analysis request

    Repository: Repository URL or name that was analyzed

    Commit ID: Git commit or branch that was analyzed

    CVE ID: CVE identifier associated with the finding

    Finding: Status badge showing the exploitability verdict:

    • Vulnerable (red badge): Exploitable vulnerability detected
    • Not vulnerable (green badge): Vulnerability confirmed as not exploitable
    • Failed (gray badge): Analysis could not complete

      Date Requested: Timestamp when the analysis was initiated

      Date Completed: Timestamp when the analysis finished

  5. Click on an analysis ID to view the detailed report with:

    • CVE exploitability verdicts and justification categories
    • Detailed evidence explaining code reachability, function calls, and environmental factors
    • VEX Justification Status Labels bound to CVE lines
    • Custom text blocks detailing dependency paths and reasoning
  6. Download artifacts from the detailed report:

    • VEX document (CSAF 2.0 JSON format)
    • Full analysis report (PDF or JSON)
    • Evidence checklist generated by LLM planner

Verification

  1. Verify that the analysis report displays exploitability verdicts for all submitted CVEs.
  2. Confirm that you can download the VEX document from the report page.
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat Documentation

Legal Notice

Theme

© 2026 Red Hat
Back to top