What does a NOASSERTION supplier field in an SBOM tell a consumer?
answer
- A claim about the author, not the part
- Different from an empty or absent field
- Different from NONE
- Declared known unknown
- Version still matches advisories; provenance does not
basics
~20 sA NOASSERTION supplier field means the document's author explicitly declined to name the supplier, not that none exists. The component and version still count as inventory, but the document cannot tell you its origin or who to ask for a fix.
solid answer
~50 sNOASSERTION is a claim about the author, not about the component: whoever produced the SBOM did not establish the supplier and is explicitly saying so rather than guessing. SPDX makes several fields mandatory, so it needs a token that means "I am not asserting this"; that is different from `NONE`, which means "there genuinely is nothing here". For a consumer that is still useful, because it is a *declared known unknown* — it marks exactly where the author's knowledge stopped, in a form you can count. A row that is simply absent gives you no such signal, and every query you run against the document answers "not present" with false confidence. Practically: if the version and package identifier are exact, the row is still usable for advisory matching; what you lose are the provenance questions — is this the upstream build or a patched fork, and who do I chase for a patch.
code
json · 20 lines{
"packages": [
{
"SPDXID": "SPDXRef-Package-openssl",
"name": "openssl",
"versionInfo": "3.0.13",
"supplier": "NOASSERTION",
"downloadLocation": "NOASSERTION",
"filesAnalyzed": false,
"externalRefs": [
{
"referenceCategory": "PACKAGE-MANAGER",
"referenceType": "purl",
"referenceLocator": "pkg:deb/debian/[email protected]"
}
]
}
...
]
}go deeper
Be ready to say plainly that NOASSERTION records what the document's author did not claim, and that it is not the same as an empty field or a finding against the component. Know that name plus version still drives advisory matching.
Explain why an explicit non-claim is more useful than an omission: an undeclared gap makes every query answer "not present" with false confidence. Be able to contrast NOASSERTION with NONE, and note that CycloneDX just omits the field instead.
Show that you triage unknowns by consequence, not by count — chase provenance on cryptography and untrusted-input parsers, ignore it on inert libraries — and that your estate store keeps unknowns visible rather than rendering them blank.
Own the reporting consequence: a dashboard that converts declared unknowns into green is a governance failure, because it destroys the one honest signal in the document. Decide what level of asserted coverage you require before an inventory counts as evidence at all.
## What the field is for An SBOM is an inventory of what is inside a piece of software. Of each row, a consumer asks three different questions: **what is it** (a name, a version, ideally a package URL such as `pkg:deb/debian/[email protected]`), **where did it come from** (supplier or originator, download location), and **how does it relate to the rest** (dependency relationships). `NOASSERTION` in the supplier field answers the second question with a refusal. ## NOASSERTION is a statement about the author SPDX makes a number of fields mandatory — the document must carry *something* there — so the format supplies a token meaning "the creator of this document is not making a claim". That is what `NOASSERTION` is. It does **not** mean the component has no supplier, it does not mean the supplier is unknowable, and it is not a security verdict about the component. SPDX also has `NONE` for the opposite case, where the author positively means there is nothing to record — a package that declares no licence at all. `NONE` says "I looked, there is nothing"; `NOASSERTION` says "I am not claiming". CycloneDX has no equivalent token: optional fields are simply absent, which is weaker for a consumer, because an absent field cannot distinguish *not applicable* from *not investigated* from *deliberately withheld*. ## Why an explicit non-claim beats silence The dangerous failure mode of an inventory is not a gap; it is a gap you cannot see. If a component is missing from the document altogether, nothing in the document tells you so, and every downstream query — "do we run this?", "are we exposed?" — returns a confident, wrong *no*. A `NOASSERTION` field is a **declared known unknown**: it puts the edge of the author's knowledge on the page, where a machine can count it and a human can chase it. The NTIA minimum elements make the same argument at document level, asking producers to state known unknowns explicitly rather than let absence imply absence of risk. This is the whole reason a consumer should prefer a document that admits its holes to one that quietly rounds them off. "41 rows, supplier asserted for 4 of them, versions exact for 37" is a coverage statement you can act on. A document with no holes visible is not the same thing as a document with no holes. ## What the row is still good for With an exact version and a package identifier you can still do the main job: match the component against advisories and answer "where else do we run this". Identifier precision is what makes that work — a package URL names ecosystem, name and version unambiguously, whereas vendor-keyed identifier schemes need exactly the supplier string you do not have. What you lose with the supplier missing: - **Provenance and authenticity.** Is this the upstream release, a distribution's patched build, or a vendor fork carrying backported changes? Fix status often differs between them. - **Who to contact.** When an advisory lands, the supplier is who you chase, and who is expected to publish an exploitability statement. - **Licence and export questions**, which frequently key on the originating organisation. ## Reading a document that is full of them Where the `NOASSERTION`s cluster matters more than how many there are: | Shape | What it means for you | |---|---| | Supplier is NOASSERTION on OS base-layer packages, versions exact | Common and workable; advisory matching still functions | | Version is NOASSERTION | The row is unusable for matching — a far worse defect than a missing supplier | | Nearly every field is NOASSERTION | You were handed a template, not an inventory; treat it as no evidence at all | ## What to do about it Triage by consequence rather than by count. Decide which components you would actually need provenance for — the TLS and cryptography libraries, parsers that touch untrusted input, anything that would drive an emergency patch — and pursue the gap only there. Record the unknowns in whatever store holds your estate inventory so that they are visible as *unknown* rather than silently rendered as blank, and never let a report roll a `NOASSERTION` up into a clean, green count. The point of an inventory is to know what you do not know; converting a declared unknown back into a blank throws away the only honest thing on the row.
- Which is worse for you as a consumer: NOASSERTION in the supplier field, or NOASSERTION in the version field?Version, decisively. Name plus version is what matches a component against advisory version ranges, so a version-less row cannot answer "are we affected" at all — it is inventory theatre. A missing supplier costs you provenance and a contact point, which hurts when you need to know whether a patched fork is in play, but the row still does the main job.
- A component is not listed in the SBOM at all. How does that differ from a NOASSERTION field?An omission is invisible: nothing in the document distinguishes "not present in the product" from "present but not found", so a query returns a confident false negative. NOASSERTION is a declared unknown — you can count them, report them as coverage, and chase the ones that matter. Undeclared gaps are the defect; declared ones are just work.
- Does NOASSERTION mean the component failed some check?No. It carries no security meaning whatsoever. It records that the document's author did not establish that piece of metadata. Treating it as a red flag on the component wastes triage effort; treating it as harmless boilerplate loses the signal. It is neither — it is a marker of where the inventory's knowledge ends.
It is the difference between a witness saying "I did not see who delivered the package" and the delivery simply never appearing in the log. Both leave you without a name, but only one tells you where to start asking.
saying these in an interview costs you the question
- Reads NOASSERTION as "the component has no supplier"
- Treats NOASSERTION as a security finding against the component
- Cannot distinguish an explicit non-claim from an absent field
- Assumes a NOASSERTION row cannot be matched to advisories
- Rolls declared unknowns into a clean count in reporting