Skip to main content

SBOM Bill of Material View

The SBOM Bill of Material view provides two tabs that present different perspectives of the same SBOM, depending on whether you want to review Sonatype analysis results or inspect the original SBOM content as it was imported.

Each tab serves a distinct purpose and is described below.

  • Report is the default view that shows the analyzed SBOM, including vulnerability, policy, and release status summaries.

  • Original BOM is a read-only view of the original bill of materials as it was imported.

Report

The Report tab displays the analyzed view of the SBOM after it has been processed by SBOM Manager. This view presents derived information such as component relationships, vulnerability summaries, policy violations, and release status based on Sonatype analysis.

The Bill of Material view summarizes the components and their risk found in the SBOM, focusing on annotating the vulnerabilities with VEX audit details.

Actions

  • Use the Version Switcher dropdown to navigate to other application versions.

  • Use the Export SBOM: Dropdown to download the annotated SBOM. Options under the dropdown include:

    • Export Original SBOM: Download the original unmodified SBOM. The original SBOM filenames are in the following format:

      Original_<public-id>_<version>_<timestamp>.{cdx|spdx}.{json|xml}
    • Additional Export Options: Choose between CycloneDX or SPDX in either JSON or XML file formats. The annotated SBOM filenames follow the format below:

      <public-id>_<version>_<timestamp>.{cdx|spdx}.{json|xml}

      The export will always use the latest version of the supported specification.

    • Export PDF: Save a PDF report of the policy violations including a list of vulnerabilities, licenses, and components.

  • Select a component from the list to open the component details view.

SBOM_Bill_of_Material_View.png

Summary

Relationship of the reported dependencies. See Software Dependencies: A beginner's guide to learn more.

  • Component Summary
    • Direct: The explicit dependencies that a software component defines and employs.

    • Transitive: Dependencies indirectly used by a software component brought into your application as dependencies for other components.

    • Unspecified: When the component's dependency information was not declared in the SBOM.

  • Vulnerabilities Summary

    Provides a total of known vulnerabilities for the components in the SBOM.

  • Release Status
    • Release Ready: The SBOM contains no high or critical vulnerabilities, or all high and critical vulnerabilities are VEX annotated.

    • Partially Annotated: The SBOM includes some high or critical vulnerabilities, and not all of them are VEX annotated.

    • Needs Attention: The SBOM contains some high or critical vulnerabilities, and none of them are VEX annotated.

  • Policy Violation Summary

    Provides a total of known policy violations for the components in the SBOM.

Components

The component list displays the components found in the SBOM with their dependency information, vulnerabilities, and licenses. The percentage annotated provides feedback at a glance on how well your teams are doing monitoring risk in your SBOMs.

  • Use the search bar to filter by either the component name or license.

  • The Filter By menu narrows results by vulnerability and dependency type.

  • Selecting a component navigates to the component details view.

Original BOM

The Original BOM tab displays the complete, original bill of materials as it was imported into SBOM Manager. This view is provided for reference only and reflects the raw SBOM structure without enrichment or modification.

Original_Bom.png
  • Displays the original SBOM in an expandable and collapsible hierarchical tree format

  • Includes metadata, components, dependencies, and evidence as defined in the imported SBOM

  • Does not include vulnerability enrichment, policy evaluation, or Sonatype annotations

  • Cannot be edited from the UI

Use this view to inspect the source SBOM content and verify how components and dependencies were defined at import time.

Automatic Expansion for Small SBOMs

When the Original BOM view is opened, the SBOM tree automatically expands if the total node count is below a configurable threshold.

If the SBOM exceeds the configured threshold, the tree opens in a collapsed state.

Intelligent Array Item Titles

Array items in the Original BOM tree display meaningful titles derived from available fields instead of numeric index values (for example, 0, 1, 2).

When identifying fields such as name, type, version, or ref are present, those values are shown as the array item title. If no identifying field is available, a shortened preview of the object content is displayed.

SBOM_Manager_Original_BOM.png

Supported SBOM formats

The Original BOM view supports the following SBOM formats and versions:

- CycloneDX
  - JSON and XML (versions 1.4–1.6)
- SPDX
  - JSON and XML (versions 2.2–2.3)

The document is rendered in a readable, structured format with preserved hierarchy.

Use cases

Use the Original BOM view for the following scenarios:

  • Audit and compliance

    • Verify supplier-provided metadata included in the SBOM

    • Confirm regulatory and compliance requirements using the original SBOM data

  • Ingestion debugging

    • Compare the original SBOM with the analyzed view to understand processing differences

    • Identify discrepancies introduced during SBOM ingestion

  • Security review

    • Review vulnerability-related metadata, including CVE references, as provided in the original SBOM

  • License verification

    • Identify and document license information declared in the original SBOM

Export PDF Report

The generated PDF includes the Analysis Status for VEX annotated vulnerabilities and third-party reported vulnerabilities stored in the SBOM.

See the VEX Workflow for details.

SBM-Export-PDF-Analysis_Status.png

Missing Vulnerabilities in Imported SBOMs

If an uploaded SBOM includes vulnerability information but no vulnerabilities appear in the Bill of Material view after import and evaluation, it may be due to incomplete or insufficient vulnerability metadata within the SBOM file.

To ensure vulnerability data from the SBOM is properly recognized and retained after evaluation, the following fields are required or strongly recommended in the vulnerabilities section of the SBOM:

  • id: a unique identifier for the vulnerability (e.g., CVE-2022-42003).

  • ratings: must include at least one rating object. Each rating must include a score (numerical CVSS score).

    • source: it is highly recommended to include metadata about the source of the vulnerability (e.g., NVD or GHSA). If multiple sources are available, SBOM Manager prioritizes NVD data.

  • affects: must link vulnerabilities to components using the affects field that references the components' bom-ref.

Example of a properly structured vulnerability entry:

 {
  "vulnerabilities": [
    {
      "id": "CVE-2022-42003",
      "source": {
        "name": "NVD",
        "url": "http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-42003"
      },
      "ratings": [
        {
          "source": {
            "name": "NVD"
          },
          "score": 7.5,
          "severity": "critical",
          "method": "CVSSv3",
          "vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H"
        },
        {
          "source": {
            "name": "NVD"
          },
          "score": 7.5,
          "severity": "critical"
        }
      ],
      "cwes": [
        502
      ],
      "analysis": {
        "state": "resolved_with_pedigree",
        "justification": "requires_environment",
        "response": [
          "workaround_available",
          "update"
        ],
        "detail": "Analysis Detail"
      },
      "affects": [
        {
          "ref": "pkg:maven/com.fasterxml.jackson.core/[email protected]?type=jar"
        }
      ]
    }
  ]
}

How SBOM Manager Processes Vulnerability Data

It's important to note that SBOM Manager is responsible for merging third-party vulnerability data from the SBOM with vulnerability insights from Sonatype’s proprietary data.

  • If no valid rating (with score) is present in the SBOM, the vulnerability is considered informational only and will not be included in policy evaluation results.

  • Vulnerabilities with missing or invalid id, no score, or lacking ratings will not be used for risk assessment and will not appear in the Bill of Material view.