SBOM import

From SBOM or lockfile to a compliance page

If you already generate CycloneDX, npm lockfiles, or similar inputs, here is how to turn them into a reviewed disclosure record.

Last updated: July 2, 2026

If you already generate CycloneDX SBOMs, SPDX files, or exports from FOSSA, Snyk, Mend, or Syft, you have the raw material for license compliance. A software bill of materials lists components: Names, versions, suppliers, hashes. A license compliance page adds reviewed license identifiers, full license text, attribution, and a stable URL for third-party license disclosure.

SBOM work supports security and regulatory programs (including CRA component documentation). License compliance pages answer procurement and legal questions about open-source license obligations. The pipeline from SBOM to compliance page is import, enrich, review, publish. Not export-and-upload unchanged.

What is the difference between an SBOM and a license compliance page?

An SBOM is machine-readable inventory optimized for vulnerability matching and supply-chain tooling; a license compliance page is human-readable third-party license disclosure optimized for procurement reviewers opening a browser tab during vendor diligence. They answer different questions and rarely substitute for each other.

Buyers ask for both in different questionnaire sections. Submitting only an SBOM when they ask for an open-source license page forces them to chase full license text manually, or fail you on incomplete disclosure.

	SBOM	Compliance page
Contents	Component identity, versions, hashes, suppliers	Reviewed licenses, full license text, attribution, product scope
Format	JSON or XML, updated by CI	Public URL with publish gates, plus exports per release
Audience	Security tooling and CRA programs	Procurement and legal reviewers

Step 1: Import SBOM or lockfile

Bring CycloneDX, SPDX, or package lockfiles into your disclosure workflow. Map SBOM components to rows in your review queue. Each row starts as needs review. SBOM license fields are hints, not approvals.

One SBOM per product per release. Do not merge unrelated products into a single license compliance page unless your disclosure model explicitly scopes sections. Procurement expects clarity.

Import from CI artifact, release tag, or SBOM tool export.
Preserve component name, version, and PURL or equivalent identifier.
Note SBOM license field as starting point, not final answer.
Flag components with missing, conflicting, or NOASSERTION license data.
Re-import on every release. Do not manually patch stale JSON indefinitely.

Step 2: Enrich and review

SBOMs often include SPDX license identifiers without full license text. Third-party license disclosure requires text procurement can read. Enrich each approved component with full license content, attribution strings, and copyleft flags from your review policy.

Resolve registry-vs-repo license conflicts. Escalate custom and copyleft licenses. Compliance fails when SBOM metadata is copied to a public page without human verification.

Attach full license text for every approved component.
Confirm license against repo LICENSE, vendor PDF, or legal guidance.
Apply copyleft and distribution review rules before approve.
Add notice and attribution blocks where required.
Document exclusions: Dev dependencies not shipped, test-only packages, etc.
Block publish until zero unreviewed in-scope rows.

Step 3: Publish license compliance page and exports

From the same approved inventory, publish maintained disclosure and release exports. Share whichever format diligence asks for, URL, PDF, or bundle. Exports attach to tickets, release notes, or vendor portals.

When the SBOM changes on the next release (new packages, version bumps, license changes), re-import, re-review, re-publish. Drift checks automate the diff so you are not surprised in a customer audit.

Publish shareable proof per product (hosted page and/or exports).
Verify disclosure loads, full text renders, product scope is clear.
Export JSON, attribution files, and disclosure bundles from same snapshot.
Wire CI to flag when the SBOM drifts from your last approved publish.
Share reviewed disclosure with procurement, not raw SBOM, when they ask for license compliance documentation.

Tools you already use

FOSSA, Snyk, Mend, Syft, GitHub dependency graph, and internal CI pipelines produce SBOMs and license hints. SourceTrust and similar disclosure workflows sit downstream: Reviewed publish record, compliance page URL, exports aligned with what ships.

You do not replace your SBOM tool. You turn its output into third-party license disclosure your customers and auditors can use. License compliance as a maintained product artifact, not a one-time file drop.