SBOM Component Risk Analyzer

Introduction:

A software inventory becomes useful for release review only when its component rows can be trusted. A dependency name is a weak clue by itself; reviewers also need a version, a license signal, a package URL or similar identifier, and vulnerability links that still point to the component that was actually shipped.

Software bills of materials often arrive from several scanners and formats. CycloneDX, SPDX, Syft JSON, and CSV exports can all carry useful evidence, but they do not keep the same field names or relationship shapes. A BOM reference, SPDX identifier, package URL, version string, and license expression all reduce ambiguity when a security team tries to match advisory data back to a product build.

Component risk is not only a vulnerability count. A dependency with no matched CVE can still need review when the license is unknown, copyleft-heavy, or outside policy. A severe vulnerability can move lower in the queue when the evidence says it is fixed or not affected, but that state still has to line up with the product version and runtime packaging.

The practical result is a triage queue, not an automatic approval. A good review starts with the highest-risk rows, then checks scanner freshness, advisory records, runtime reachability, owner assignment, and license exceptions before anyone treats the artifact as ready.

How to Use This Tool:

Use the most complete SBOM export available and keep the artifact label close to the release, container image, or service you plan to review.

1. Set Artifact label to the image, service, product, or release name that should appear in the summary and exported evidence.
2. Choose Vulnerability gate to decide which severity levels create policy rows: Medium and above, High and critical, or Critical only.
3. Edit Denied licenses for the policy you want to enforce. Leave UNKNOWN in the list when missing license data should be treated as a review finding.
4. Paste or browse for CycloneDX JSON, SPDX JSON, Syft JSON, or CSV rows. CSV can include component, version, license, severity, vulnerability, state, scope, and package URL columns.
5. Check Component Risk Ledger first. It ranks parsed components by risk score and shows version, license, vulnerability count, maximum severity, and risk band.
6. Open SBOM Policy Finding Queue to separate vulnerability-gate findings from license findings, incomplete identity findings, and unmatched vulnerability records.
7. Use Component Risk Stack when you need to explain why a row is high. The chart separates vulnerability, license, and identity or scope points for the top components.

Interpreting Results:

The headline score weights the worst component more heavily than the average because one urgent runtime component can decide release priority. Policy findings add extra pressure, so an artifact with several license or identity repairs can score higher than its vulnerability count alone would suggest.

A low score is strongest when the SBOM itself is strong. Confirm that key components have versions, package URLs or equivalent identifiers, license data, and preserved vulnerability links before treating a quiet queue as reassuring.

Technical Details:

SBOM risk scoring is a structured triage model over the evidence already present in the pasted inventory. It does not perform software composition analysis, fetch advisory updates, or resolve licenses from registries. The quality of the result depends on how completely the SBOM preserves component identity, vulnerability relationships, license fields, and scope.

Component matching uses stable references first, then weaker name and version clues when needed. A vulnerability that keeps an affected reference, package URL, BOM reference, or matching component name can be assigned to the right row. A vulnerability without a usable relationship remains visible as an unmatched finding because silently dropping it would hide an SBOM-quality problem.

Formula Core

Each component score combines capped vulnerability points, license risk, missing identity evidence, and runtime scope. Scores are rounded after clamping to a 0 to 100 range.

The artifact score keeps the highest component in front, adds part of the average component risk, and gives each non-clear policy row extra weight.

Rule Core

Numeric vulnerability scores are normalized to common qualitative bands before they are used. A score of 9 or higher is critical, 7 to below 9 is high, 4 to below 7 is medium, and a positive score below 4 is low. Text labels such as critical, high, medium, moderate, low, informational, and unknown are also recognized.

All scoring is deterministic for the pasted data and selected settings. Changing the vulnerability gate changes policy rows, while changing denied licenses can change both license findings and risk scores.

Review Limits and Privacy:

This is a local triage aid for security and compliance review. It helps organize SBOM evidence, but it cannot replace source advisories, scanner freshness, legal review, runtime reachability analysis, or product-owner judgment.

• The pasted SBOM is parsed in the browser session; the analyzer does not query an advisory database or package registry.
• Stale scanner data stays stale in the output. Refresh the SBOM before using the queue for release decisions.
• License labels are treated as policy signals, not legal conclusions. Confirm obligations and approved exceptions outside the score.
• Unmatched vulnerability rows are data-quality warnings. Repair the SBOM or scanner export before assuming the affected component is absent.

Worked Examples:

Advanced Tips:

• Keep the vulnerability gate aligned with the review meeting. Use Critical only for a quick release stop check, and use Medium and above when the goal is backlog grooming.
• Treat UNKNOWN as a denied license during audit preparation, then remove it only when missing license rows are being handled in a separate workflow.
• Regenerate noisy CSV exports with package URLs or BOM references when the queue shows unmatched vulnerabilities; stronger identifiers prevent false splits.
• Compare the Component Risk Stack against the policy queue before assigning work, because a high score may come from license and identity evidence rather than fresh vulnerabilities.
• Refresh scanner output before release decisions. The score only reads the pasted SBOM evidence and does not fetch newer vulnerability or license data.

FAQ:

Glossary:

SBOM

A software bill of materials that lists components and supply-chain evidence for a software artifact.

Package URL

A standardized package identifier that can include ecosystem, namespace, name, version, qualifiers, and subpath.

BOM reference

A stable reference inside an SBOM that can link components, dependencies, and vulnerability records.

Denied license

A license identifier or label that the selected policy treats as requiring review.

VEX-like state

A vulnerability state such as not affected, fixed, resolved, or false positive that reduces but does not erase review weight.

Unmatched vulnerability

A vulnerability record that could not be linked back to a parsed component.

References:

• 2025 Minimum Elements for a Software Bill of Materials (SBOM), CISA.
• CycloneDX specification overview, OWASP Foundation, 2025.
• SPDX Specification 2.3 package information, SPDX Workgroup.
• Package-URL (PURL), Ecma TC54, 2025.
• CVSS v3.1 Specification Document, FIRST.
• Syft output formats, Anchore.