The licenses in an SBOM name the terms under which each component is made available to you. They appear as short standard codes such as MIT or Apache-2.0. You do not need to be a lawyer to review the list: sort it, flag the unknowns and the unfamiliar, and send those to someone who can read the terms.
This post is general information, not legal advice.
TL;DR
- Every open source component comes with a license, and the SBOM can record it.
- CISA's 2026 guidance adds Component License as a minimum element and recommends standard SPDX identifiers.
- SPDX has two license fields that mean different things: declared and concluded.
- Your review job is triage: approved, needs a look, or unknown.
Definition. A software license is the set of terms from the author that says how others may use, change and share the software. The SPDX License List gives each common license a short standard identifier so tools and people can refer to it the same way.
Why does an SBOM list licenses?
An SBOM is mainly known for security. But the same inventory answers a legal question: what terms come with each part?
The 2026 minimum elements for a software bill of materials, published by CISA with partner agencies, define a Component License element. It is "the identifier(s) for the license(s) under which the software component is available." The identifiers "should allow an organization receiving the SBOM data to find the full details of the licenses."
The guidance recommends using SPDX license identifiers when possible. If there is none, the contents should say where the full license is available, for example with a web address. It also says this field should include information about "the existence of proprietary license conditions," and that if the author is not aware of the license, the author should say the license information is unknown.
CISA's SBOM FAQ makes a related point about risk. It says "License obligations are incurred whenever licensed software is present and these obligations are independent of SBOMs." The SBOM does not create the obligations. It makes visible what you already have.
What are SPDX license identifiers?
The SPDX License List, maintained by the SPDX project, is "a list of commonly found licenses and exceptions used in free and open or collaborative software, data, hardware, or documentation." Each entry has a "standardized short identifier, the full name, the license text, and a canonical permanent URL."
The list shows how short identifiers look. As of the version I fetched, 3.29.0 dated 2026-09-16, it included entries such as these:
| Identifier | Full name |
|---|---|
| MIT | MIT License |
| Apache-2.0 | Apache License 2.0 |
| 0BSD | BSD Zero Clause License |
| AGPL-3.0-only | GNU Affero General Public License v3.0 only |
Notice the pattern in the last row. Some identifiers say "only" or "or later," because different versions of a license are different licenses. The details matter, which is why a standard code is better than a casual name like "GPL."
Licenses can also be combined. The SPDX list describes "exceptions" that can be added with the word WITH. A component may also be available under more than one license. SPDX handles this with license expressions, which are covered in the specification's Annex D.
What do declared and concluded mean?
SPDX has several license fields for a package. Two are easy to mix up.
| Field | What it holds | Who decides |
|---|---|---|
| Declared license | The licenses declared by the authors of the package, usually found in a file such as COPYING in the source | The package authors |
| Concluded license | The license the SBOM creator concluded governs the package | The SBOM creator |
The SPDX specification says the declared field should not include license information from a third party source, such as a repository page. It also says that if the concluded license differs from the declared one, "a written explanation should be provided in the Comments on License field."
In everyday terms: declared is "what the author says about their own work," and concluded is "what the person making the list decided after looking." When they disagree, ask why.
Either field can also hold NONE or NOASSERTION. These mean different things, and this post explains the difference.
How do I review the licenses in my SBOM, step by step?
- Get the list. Pull out each component name, version and license from the SBOM into a simple table.
- Group by license. Count how many components use each one. A few identifiers usually cover most of the list.
- Mark each group. Use three labels: approved, needs review, and unknown.
- Define "approved" with your legal or compliance contact. Not you alone. They decide which licenses your company accepts for which uses.
- Send "needs review" groups to that contact. Include the component names, where they are used and whether you changed them.
- Chase the unknowns. Check the package's own files and the source repository for a license. If you still cannot tell, record it as unknown, which is what the guidance says to do.
- Write the decisions down. Keep a short record so you do not repeat the review at the next release.
- Automate the repeat. Put your approved list into a policy check that runs on each new dependency.
- Re-review on upgrade. A new version of a package can change its license, so look when the identifier changes between SBOMs.
Worked example: a 200 component app
All numbers here are invented.
| License group | Invented count | Label |
|---|---|---|
| MIT | 112 | Approved |
| Apache-2.0 | 41 | Approved |
| 0BSD | 6 | Approved |
| AGPL-3.0-only | 2 | Needs review |
| Other named licenses | 11 | Needs review |
| Proprietary, from vendors | 4 | Needs review (check contract) |
| NOASSERTION | 24 | Unknown |
| Total | 200 |
Check: 112 plus 41 plus 6 plus 2 plus 11 plus 4 plus 24 equals 200.
The team's first pass shows 159 components (112 plus 41 plus 6, which is about 80 percent) on the approved list. That leaves 41 to look at, which is a manageable afternoon instead of an impossible review of 200.
For the 24 unknowns, the team finds license files for 15 in the source repositories. Nine remain unknown. They record those nine as unknown and open a ticket to replace or ask about each.
For the two components under AGPL-3.0-only, they write a short note to the compliance contact: the names, the versions, whether anything was modified, and whether the application serves users over a network. The contact decides what to do. The developers do not decide the legal question.
How do I keep license review from becoming a bottleneck?
A few habits help.
- Decide the rules once. A policy that says "these licenses are fine, these need review" saves a debate each time.
- Check at the door. Review a new dependency when it is proposed, not after it ships.
- Share a clear answer when customers ask. CISA's guidance notes that some licenses require disclosure that you include their software. An SBOM helps you meet that kind of request.
- Refresh with each release. The guidance says each version should have its own SBOM, so license data stays tied to what you ship.
For more on what else is worth checking, see enriching SBOMs with vulnerability and license metadata.
Try it yourself
In the demo below, watch how a pull request is checked against a policy before it is allowed through. Think about how a rule such as "unknown licenses need review" could work the same way.
Click through it at your own pace, or open it full screen.
How can Safeguard help?
Safeguard's SBOM and dependency scanning inventories your components and exports SPDX or CycloneDX files that carry license identifiers. Policies and gates let you check changes as they are proposed. Compliance and evidence automation helps you keep your review records in one place, and it does not certify anything on its own.
You can try a free scan at gold.safeguard.sh/scan. The Safeguard CLI runs scans where developers work, and it can also write code, for example when you decide to replace a component.
Quick check
Does an SBOM tell me whether I am allowed to use a component?
It tells you which license applies. Whether that license fits your use is a legal question for your counsel or compliance contact.
What is the difference between declared and concluded licenses?
Declared is what the package authors state. Concluded is what the SBOM creator decided after reviewing. If they differ, the specification asks for a written explanation.
What should I do about unknown licenses?
Look in the package files and source repository. If you still cannot tell, record the license as unknown, as the guidance says, and decide whether to ask, replace or accept the component.
Sources
- CISA and partners, 2026 Minimum Elements for a Software Bill of Materials (SBOM): https://www.cisa.gov/resources-tools/resources/2026-minimum-elements-software-bill-materials-sbom
- SPDX Specification 2.3.1, Package information: https://spdx.github.io/spdx-spec/v2.3.1/package-information/
- SPDX License List: https://spdx.org/licenses/
- CISA, SBOM FAQ: https://www.cisa.gov/resources-tools/resources/sbom-faq
Last reviewed: 19 October 2026.
