◈ TraceUnified
Product Traceability Industries Pricing
Resources
Why TraceUnified Documentation Compare Security & compliance
Book a demo Try for free

Import & triage an SBOM

An end-to-end walkthrough — import a CycloneDX or SPDX SBOM, review the components and their vulnerabilities, and triage what a new CVE affects.

This guide takes a supplier’s SBOM from a file to a triaged set of components on the thread. It uses the universal item actions from Working with items where they apply, and focuses on what’s specific to the software bill of materials. For the concepts behind each step, see Importing, Components, Vulnerabilities, and Suspect propagation.

Import the SBOM

Before you start Have the SBOM file ready — a CycloneDX or SPDX export from your build or supplier.

  1. Open the SBOM module (or the Import flow) and choose to import an SBOM.
  2. Upload the CycloneDX or SPDX file — the format is detected for you.
  3. Review what will be imported, then confirm.

Result Each component in the file becomes a first-class item — with its own identity, links, and history — not a row in a static document. See SBOM import for format detail.

Review the components

  1. Open the imported components in the tree.
  2. Check supplier, version, and License against your policy.
  3. Link components to the parts of your system that use them, so impact is traceable.

Result A connected inventory — each component tied to where it's used and what it affects. See License policies for governing the supply chain.

Review vulnerabilities

  1. Open a component's vulnerabilities to see the CVEs against it and their CVSS scores.
  2. Sort by Severity — Critical and High first — to focus on what matters.

Result A prioritized view of what's exposed across your bill of materials.

Triage a CVE

When a vulnerability lands, decide what it means for your system and act.

Before you start Know which component the CVE affects and where that component is used.

  1. Open the affected component and assess the vulnerability against your usage — does it apply to how you use the component?
  2. Follow the suspect flags: when a CVE lands, the items linked to the component are marked suspect for re-assessment.
  3. Record your decision — mark it Mitigated where a control or version addresses it, and link the fix or justification.
  4. Re-verify the affected items and clear their suspect flags once handled.

Result The vulnerability has a recorded disposition, the affected work is re-verified, and the audit trail shows what you knew and what you did about it.

Note Because components are on the thread, a single CVE shows you everything downstream that depends on it — see Suspect propagation.

Where to go next

To see how a change ripples across the whole thread, see Build & maintain the thread.

Was this helpful?