SBOM Component Risk Analyzer

Introduction

A software bill of materials, usually shortened to SBOM, is an inventory of the components that make up an application, image, device, or release. It matters during security review because a release owner often needs to know which packages are present, which known vulnerabilities are tied to those packages, and whether license or identity gaps should stop approval.

Component risk is broader than a raw CVE count. A library with a critical vulnerability deserves attention, but a package with an unknown license, no package URL, or no version can also slow a release because reviewers cannot match it reliably across scanners, advisories, or follow-up tickets. The useful review question is not only whether a vulnerability appears. It is which component needs owner action first and why.

SBOM formats can carry different amounts of evidence. CycloneDX data may include components, package URLs, license entries, vulnerability ratings, and affected references. SPDX data often centers on packages and declared or concluded license fields. CSV exports can be enough for triage when they keep component, version, license, severity, vulnerability, state, scope, and package URL columns together.

An SBOM risk score is a triage aid, not proof that a component is exploitable or safe. It can help a team find the next review queue, but it cannot replace source advisory checks, runtime exposure analysis, license counsel, or an exception process for accepted risk.

Technical Details:

SBOM risk review starts with component identity. A useful component row has a name, version, license expression, and a stable reference such as a package URL or BOM reference. Vulnerability data becomes much more useful when it points back to that same reference, because the reviewer can connect a CVE or advisory to the exact package entry instead of matching by name alone.

Severity labels usually come from the advisory source or from a CVSS-style numeric score. CVSS is a severity method, not a complete risk measure, so release triage also needs license status, component identity, dependency scope, and whether the vulnerability evidence actually maps to a component in the SBOM.

Rule Core

The review model reads component inventory, assigns vulnerabilities to matching components, then gives each component risk points from vulnerability, license, identity, and scope signals.

The vulnerability portion is capped at 62 points so a component with many advisories does not erase license and identity signals. The final component score is rounded on a 0 to 100 scale.

Input shape determines how much can be matched. CycloneDX-style JSON reads components and vulnerability objects. SPDX JSON reads packages and any vulnerability array that appears in the document. Syft-style JSON reads artifacts as components. CSV rows can work with headers, while headerless rows are interpreted as component, version, license, severity, vulnerability ID, status, scope, and package URL.

The artifact-level score combines the highest component score, average component score, and the count of non-clear policy findings. It does not query a vulnerability database, rescan packages, validate license obligations, or decide exploitability. It summarizes the evidence already present in the SBOM text and selected settings.

Everyday Use & Decision Guide:

Start by pasting the exact release, image, package, or product name in Artifact label. That label appears in the summary and exported JSON, so use the versioned name reviewers will recognize in a release ticket.

For a first pass, leave Vulnerability gate on High and critical and keep UNKNOWN in Denied licenses. That combination catches severe vulnerability signals while also flagging components whose license data is missing. Move the gate to Medium and above when early development triage should include more advisories, or to Critical only when the review is only looking for immediate blockers.

Paste CycloneDX JSON, SPDX JSON, Syft-style JSON, or CSV rows into SBOM source. A local file can be loaded with Browse SBOM, and Load sample restores a CycloneDX example for checking the workflow. After parsing, the summary line names the source type and shows component and vulnerability counts.

• Component Risk Ledger ranks components by risk, showing component, version, license, vulnerability count, max severity, and risk score.
• SBOM Policy Finding Queue lists vulnerability, license, identity, and unmatched-vulnerability items that need review.
• Component Risk Stack compares the vulnerability, license, and identity/scope portions for up to the top ten scored components.
• JSON gives a structured copy of the artifact score, band, component rows, policy findings, chart rows, unmatched vulnerabilities, and warnings.

A low score does not mean the release is safe, and a high score does not prove exploitability. Treat the output as a prioritization brief. Before accepting a result, check whether SBOM Policy Finding Queue contains unmatched vulnerabilities, unknown licenses, or incomplete component identity. Those rows often explain why a clean-looking vulnerability count still needs review.

When the result is used for a ticket or release note, copy the policy row or JSON only after confirming that the Artifact label, source type, Vulnerability gate, and denied license list match the policy you meant to apply.

Step-by-Step Guide:

Use the fields in order so the summary and policy queue reflect the same review rule.

1. Enter the release, image, or product name in Artifact label; check later that the summary line starts with the same label.
2. Choose Vulnerability gate. Medium and above sends medium, high, and critical vulnerabilities to the queue, High and critical sends only high and critical rows, and Critical only keeps the vulnerability queue focused on critical rows.
3. Edit Denied licenses as a comma-separated list. Leave UNKNOWN in the list when missing license data should create a policy finding.
4. Paste SBOM text into SBOM source, drop a file onto the text area, or use Browse SBOM. The helper line changes to the loaded file name and byte count when a file is read.
5. If the alert says SBOM input needs attention, fix the source text. Empty input asks for CycloneDX JSON, SPDX JSON, or component CSV rows. Invalid JSON falls back to CSV, and headerless CSV is read in the documented column order.
6. Review the summary badges for component count, high-plus signals, unknown licenses, and policy findings. Then open Component Risk Ledger and SBOM Policy Finding Queue before using the chart or JSON output.

Finish by checking the first few queue rows and any unmatched vulnerability row; those entries usually decide whether the next action is an upgrade, license review, SBOM regeneration, or normal monitoring.

Interpreting Results:

Read the main SBOM risk score as a release triage signal. Critical queue starts at 75/100, High review starts at 55/100, Elevated starts at 30/100, and Monitor covers scores below 30/100.

Component Risk Ledger is the best place to see which component created the pressure. A high component score can come from a severe vulnerability, a denied license, missing identity data, or a combination of smaller signals. Component Risk Stack helps separate those causes visually for the highest-scored rows.

• Policy finding rows deserve attention even when the overall score is modest, especially for denied licenses, unknown licenses, incomplete identity, and unmatched vulnerabilities.
• High+ signals counts high and critical vulnerability entries in the source data, including entries whose state later reduces risk points.
• No gate-level vulnerability, license, or identity finding was parsed means the selected rules found no queue item. It does not mean the SBOM is complete or the release is approved.
• Unmatched vulnerability means the vulnerability evidence could not be linked to a component reference. Preserve BOM references, package URLs, and affects references before rerunning the review.

Do not treat a risk band as a legal, compliance, or exploitability decision. Verify the source advisory, component owner, package use at runtime, license expression, and any waiver process before closing a security review.

Worked Examples:

Release SBOM with a critical library

The sample CycloneDX SBOM labels the artifact orders-api:2.8.0. It includes log4j-core with CVE-2021-44228 marked critical and exploitable, legacy-xml with an UNKNOWN license and no package URL, and mocha with a high vulnerability marked not_affected. With Vulnerability gate set to High and critical, SBOM risk shows 38/100 Elevated. SBOM Policy Finding Queue includes the critical Log4j finding, the unknown license, the incomplete identity row, and the high not-affected row.

Critical-only review of a CSV export

A CSV export contains core-api,1.4.2,MIT,high,CVE-2026-1001,affected,runtime,pkg:npm/core-api@1.4.2 and another medium row. With Vulnerability gate set to Critical only, those vulnerabilities still affect Component Risk Ledger, but they do not create vulnerability rows in SBOM Policy Finding Queue. If license and identity fields are complete, the queue can show the clear policy message even though the high-plus badge reports one high signal.

Denied license with no vulnerability

An SPDX JSON package named reporting-agent has version 3.0.0, license AGPL-3.0, and no vulnerability object. If AGPL-3.0 remains in Denied licenses, the component receives license risk points and SBOM Policy Finding Queue adds AGPL-3.0 needs policy review. The next action should be a license obligation and exception check, not a vulnerability patch task.

Headerless CSV warning

A copied CSV line such as express,4.18.2,MIT,medium,CVE-2024-29041 can parse without headers. The warning says columns were read as component, version, license, severity, vulnerability ID, status, scope, and package URL. Add a header row when the source columns are in another order, then compare Component Risk Ledger and JSON warnings before trusting the queue.

FAQ:

Glossary:

SBOM

A software bill of materials, listing components and related evidence for a product or release.

CycloneDX

An SBOM format that can describe components, dependencies, licenses, vulnerability data, and relationships.

SPDX

A software supply chain standard commonly used for package and license information.

Package URL

A package identifier that helps match the same component across tools and vulnerability records.

CVSS

A vulnerability severity scoring method whose numeric ranges often map to low, medium, high, and critical labels.

Policy finding

A queue row created by a gate-level vulnerability, denied license, incomplete identity, or unmatched vulnerability.

References:

• Software Bill of Materials (SBOM), Cybersecurity and Infrastructure Security Agency.
• Software Bill of Materials (SBOM), CycloneDX.
• Specifications, SPDX.
• SPDX License List, Software Package Data Exchange, February 20, 2026.
• Vulnerability Metrics, National Vulnerability Database, updated June 27, 2024.
• CVSS v3.1 User Guide, FIRST.