Supplier SBOM validation guide¶

How to validate that an SBOM (JSON) received from a supplier or another team meets your quality requirements. After validation, it analyzes the licenses and vulnerabilities and produces a risk report. You only need the SBOM file — no source code required.

For the design background and the internal validation logic, see the maintainer doc Supplier SBOM validation and analysis (Korean).

When to use it¶

Use it when a supplier or another team hands you an SBOM file instead of source, and you need to confirm the SBOM meets your quality criteria and then check its licenses and vulnerabilities. The input can be CycloneDX or SPDX (JSON, Tag-Value); it is converted to CycloneDX internally for analysis.

The criteria check whether an SBOM is good enough for dependency review. Requirements vary by organization; as one reference, see SK Telecom's supply chain security guide and its SBOM requirements.

Category	Criteria
Format	CycloneDX v1.3–1.6 or SPDX v2.2–2.3
Required metadata	timestamp, tool info, top-level component name and version
Required component fields	name, version, PURL (`pkg:generic` not allowed)
Completeness	both direct and transitive dependencies included
Recommended	supplier, license (SPDX ID), hash

Running it all at once¶

From the web UI¶

Open the web UI, choose SBOM upload, and upload the file you received; enter a project name and version, then run.

./scripts/scan-sbom.sh --ui     # opens http://localhost:8080
#   Windows: double-click scripts\sbom-ui.bat

Installation is in Getting started.

From the CLI¶

Pull the scanner image once (docker pull ghcr.io/sktelecom/bomlens:latest), then pass the SBOM file to --analyze:

./scripts/scan-sbom.sh --project supplier-app --version 2.0.0 \
  --analyze "./supplier-sbom.json" \
  --generate-only

--analyze turns on notice and security analysis automatically, so you do not need to add --all. --generate-only leaves only the outputs in a {Project}_{Version}/ subfolder under the current directory and cleans up the temporary working copy. For the remaining options, see the usage guide.

The four outputs¶

Output	File	Meaning
Conformance report	`{Project}_{Version}_conformance.{json,md,html}`	whether the quality criteria are met, and what is missing
SBOM (converted)	`{Project}_{Version}_bom.json`	SPDX inputs converted to CycloneDX 1.6; CycloneDX inputs keep their original spec version
Open-source notice	`{Project}_{Version}_NOTICE.{txt,html}`	components grouped by license
Risk report	`{Project}_{Version}_risk-report.{md,html}`	conformance, vulnerabilities, and licenses combined, with response deadlines

Unlike a self-generated SBOM, a received SBOM additionally produces a conformance report, and its summary goes into section 1 of the risk report.

Reading the conformance report¶

The conformance report is the per-item check of whether the received SBOM meets the quality criteria. Validation is based on the original input before conversion, so even for SPDX it checks the fields of the original SPDX.

If any required item falls short, it is a fail. The required items match the criteria table in When to use it — timestamp, tool info, top-level component, name/version coverage, PURL coverage (no pkg:generic), and transitive dependencies.
If a recommended item (license, hash coverage) falls short, it is a warn, not a fail.
The cards at the top of the HTML report show pass/fail and the list of missing items.

When a fail appears, tell whoever sent the SBOM which fields are missing and ask them to fix it. The most common unmet items are a missing PURL, use of pkg:generic, and missing transitive dependencies (only direct dependencies included).

Reading the risk report¶

The risk report (_risk-report) is a document built by re-aggregating the outputs above without a new scan. It has four parts.

Requirements met — the conformance results table. If fail, the unmet items are stated.
Vulnerability tally and response deadlines — a severity tally plus the recommended deadlines (a response plan or risk justification within 7 days for Critical and 30 days for High), laid out in a table.
License summary — the notice and license coverage.
Next steps — guidance on a response plan.

SPDX input¶

If you supply SPDX (JSON, Tag-Value), it is converted to CycloneDX internally with syft convert and then analyzed through the same pipeline. Conformance validation is based on the original SPDX before conversion, because metadata such as timestamp, tools, or transitive dependencies can be normalized away during conversion. Some SPDX license expressions may be simplified when moved to CycloneDX.

Asking for remediation¶

After validation and analysis, send the risk report (_risk-report.html) to whoever sent the SBOM and ask for the following.

Fix the conformance fail items and send the SBOM again.
Prepare a response plan or risk justification for Critical vulnerabilities within 7 days and High within 30 days (recommended deadlines).

Response tracking, exception approval, and history management are out of scope for this tool — they belong to a separate vulnerability and risk management system. This tool covers validating, analyzing, and reporting on a single SBOM locally.

Limits¶

Validation is based on the presence and coverage of required fields. It does not guarantee semantic accuracy such as whether a PURL points to the exact package or whether a version is real.
Whether transitive dependencies are included is inferred from the presence of edges in the dependency graph; it is not proof that the graph is complete.
The accuracy of vulnerability and license analysis depends directly on the quality of the input SBOM, especially PURL and version accuracy.

Related: Getting started | Scenarios guide | Notice and security guide