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.

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 barto filter by either the component name or license.The
Filter Bymenu 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.

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.

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.

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 ascore(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 theaffectsfield 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, noscore, or lackingratingswill not be used for risk assessment and will not appear in the Bill of Material view.