Export the licence field for every component in your SBOM, normalise the values to SPDX identifiers, fill the gaps by hand, compare against your approved list, and send the unclear cases to someone qualified to advise. This is an engineering process, not legal advice.
Why the SBOM is the right starting point
Licence questions come up at release time, in due diligence, and when a customer asks. If the answer lives in your SBOMs, you can give it without cloning repositories. CycloneDX lists licensing conflicts alongside outdated components and vulnerabilities as risks that component inventories help identify.
Step 1: export the licence data
Pull component name, version, ecosystem and licence from every SBOM in scope. Note which SBOM revision and date you used.
Step 2: normalise to SPDX identifiers
The SPDX License List gives each commonly found licence a standardised short identifier, a full name and a canonical URL, so licences can be identified efficiently and reliably. The listed version at the time of writing was 3.29.0, dated 16 September 2026. Map free text such as "MIT License" or "Apache 2" to the identifier. Where a licence has an exception, SPDX expresses it with the WITH operator.
Step 3: measure coverage first
Before judging licences, count how many components have no licence value. If that is a large share, the review is incomplete however the rest looks. See NOASSERTION versus NONE for what empty values mean.
Step 4: fill gaps
For each unknown, open the package metadata and the repository licence file. Record what you found, where, and the date. Do not guess.
Step 5: apply a policy
Write the policy once, as a list your team can read.
| Category | Typical handling |
|---|---|
| On the approved list | Pass |
| On a review list | Needs a named approver |
| On a blocked list | Fail the release or require removal |
| Unknown | Treat as review until resolved |
Whether a licence belongs on which list depends on how you distribute your software, so your policy should come from your counsel and your own product facts. A hosted service, a downloadable app and a library each interact with licences differently.
Step 6: keep the record
Store the decision with the component, version, reviewer and date. When the component changes version, the licence can change too, so re-check on upgrade.
Step 7: automate the repeat
After the first pass, run the same check in your pipeline so new components with unknown or blocked licences are flagged when they arrive, not at release.
One practical tip: keep a short glossary beside the policy, so reviewers use the same words for the same cases. "Unknown", "unreviewed" and "approved with condition" are different states, and mixing them is how a component slips through. Review the glossary when your product changes how it distributes software.
Safeguard stores SBOMs and evidence in one place, and its policies and gates can act on dependency findings. A free scan is a quick way to see your component list.
Quick check
Can the SBOM tell me whether I can ship a component?
It tells you the declared licence. Whether that licence fits your distribution model is a question for your counsel.
What if a licence field is empty?
Treat it as unknown, check the source, and record what you find. Do not assume permissive.
Sources
Last reviewed: 19 October 2026.
