NOASSERTION in an SBOM means the author is making no claim about that field. They may have tried and failed to find the answer, never looked, or chose not to say. It is not the same as "none," and it is not proof of a problem. A few of them are normal. Many of them are a warning.
TL;DR
- NOASSERTION is a value defined by the SPDX standard. It means "no statement is being made."
- NONE means something different: the author concluded there is nothing there.
- Current CISA guidance says authors should say plainly whether information is unknown or withheld.
- Check how many NOASSERTION values your SBOM has, and in which fields. Licenses and download locations matter most.
Definition. NOASSERTION is a keyword in the SPDX format (SPDX stands for System Package Data Exchange). It is placed in a field when the SBOM author does not assert, or claim, a value for it.
Where will I see NOASSERTION?
If you open an SPDX file and search for the word, you will find it in lines such as these:
PackageSupplier: NOASSERTION
PackageDownloadLocation: NOASSERTION
PackageLicenseConcluded: NOASSERTION
PackageLicenseDeclared: NOASSERTION
The SPDX specification allows it in many package fields, including the supplier, the originator, the download location, the home page and several license fields. It is a deliberate placeholder, not an error in the file.
Think of a form with a box labeled "Spouse's name." If you leave it blank, the reader cannot tell whether you forgot, skipped it, or have no spouse. SPDX avoids that confusion by giving you two clear words to write instead of leaving the box blank.
What is the difference between NONE and NOASSERTION?
This is the part people mix up.
- NONE is a claim. The author says there is nothing to report. For the download location, the specification says to use NONE "if there is no download location whatsoever." For a license, it is used when the author concludes there is no license available.
- NOASSERTION is the absence of a claim. The specification says to use it in three situations: the author "has attempted to but cannot reach a reasonable objective determination," or "has made no attempt to determine this field," or "has intentionally provided no information." It adds that no meaning should be implied by choosing it.
| Value | What it says | Example reading |
|---|---|---|
| A real value | The author found it and states it | License is a named license |
| NONE | The author checked, and nothing exists | There is no home page |
| NOASSERTION | The author is not stating a value | Could not tell, did not check, or chose not to say |
The difference matters because NONE can be wrong in a harmful way. If a package really has a license and the author wrote NONE, the reader may assume no license terms apply. NOASSERTION is safer because it does not mislead. It just tells you to look further.
Is NOASSERTION a problem?
It depends on how many there are, and where.
CISA's 2026 minimum elements guidance has a whole practice on this. Under "Explicitly Identifying Unknown Information," it says that if a required field is not provided, "the SBOM author should explicitly state whether the information is unknown to the SBOM author or whether the SBOM author is withholding the information from the SBOM."
The guidance gives two reasons. First, saying "unknown" gives the reader useful information "about both the target software and the SBOM author." Second, it warns that organizations "may consider an SBOM incomplete if the SBOM author withholds essential component data."
The older NTIA material also has a related idea. If contracts or legal agreements prohibit disclosing certain components, the SBOM should indicate the presence of a unique "known unknown" component rather than hide it.
So the rule of thumb is:
- A handful of NOASSERTION values in less important fields is normal. Real projects have missing data.
- NOASSERTION in the license field for many components is a gap. You cannot tell what rules apply to your use.
- NOASSERTION for most of the file suggests a weak tool setup or a rushed export. Treat the SBOM as a draft.
How do I reduce NOASSERTION values, step by step?
- Count them. Search the file for the word and note the total and which fields. A simple text search is enough to start.
- Sort by field. Licenses, versions and identifiers deserve attention first. Home page values rarely matter.
- Check the source information. Many gaps appear because the tool read only a short file. Ask whether it can read the package registry data or the actual package contents.
- Fix the build inputs. If a package of your own has no license file or no declared license, add one. That removes the gap at the source.
- Add identifiers. CISA's guidance lists identifiers such as purls and CPEs, and says to include them all. Better identifiers lead to better lookups for the other fields.
- Record what is truly unknown. If you cannot find the answer, leave NOASSERTION in place. Do not replace it with a guess. The guidance says unknown should be stated, not hidden.
- Regenerate and compare. Run the tool again and count again.
Never swap NOASSERTION for NONE just to make the file look cleaner. That turns "I do not know" into "there is nothing," which is a different and possibly false statement.
Worked example: a small SBOM
All figures below are invented.
An SBOM lists 200 components. A script counts the NOASSERTION values by field.
| Field | NOASSERTION count | Share of 200 |
|---|---|---|
| Home page | 60 | 30 percent |
| Supplier | 25 | 12.5 percent |
| Declared license | 18 | 9 percent |
| Concluded license | 18 | 9 percent |
| Download location | 4 | 2 percent |
The team looks first at the license rows: 18 components with no license information. They find that 11 are internal packages with no license file. They add a license to those 11. For the other 7, they check the package registry pages and find a license for 5. Two stay unknown.
After one afternoon of work, the license gaps drop from 18 to 2. That is 1 percent of the components (2 divided by 200). The home page gaps are left alone, because nothing depends on them.
The team shares the SBOM and notes that two components have unknown license information, as the guidance recommends.
Try it yourself
In the demo below, open the inventory and look at the details shown for each package, such as version and license. Think about what you would see if a field were missing.
Click through it at your own pace, or open it full screen.
How can Safeguard help?
Safeguard's SBOM and dependency scanning builds your inventory and exports it in SPDX or CycloneDX, so you can open the output and check how many fields are unknown. A free scan at gold.safeguard.sh/scan shows what a scan produces for a real project.
The Safeguard CLI and IDE extensions run the scan where developers work. For related reading, see SBOM quality fields auditors check and SBOM validation and quality checks.
Quick check
Is NOASSERTION the same as an empty field?
No. An empty field is ambiguous. NOASSERTION is a clear statement that the author is not claiming a value.
Does NOASSERTION mean the package is unsafe?
No. It means the SBOM does not state that piece of information. It tells you to look further, not that something is wrong.
Can I replace NOASSERTION with NONE to tidy up?
No. NONE claims that nothing exists. If you do not actually know, NOASSERTION is the honest value.
Sources
- SPDX Specification 2.3.1, Package information: https://spdx.github.io/spdx-spec/v2.3.1/package-information/
- 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
- NTIA, SBOM Myths vs. Facts: https://www.ntia.gov/page/software-bill-materials
Last reviewed: 19 October 2026.
