Most SBOM confusion comes from a handful of assumptions. Here are six, each checked against text from CISA, the SPDX specification or the CycloneDX specification. The short version: an SBOM is an inventory with a stated method, not a verdict.
Myth 1: An SBOM is a vulnerability report
Fact: it is an ingredients list. CISA describes an SBOM that way. Vulnerability data comes from matching components against advisories, and that is a separate step. A file can list a vulnerable component and say nothing about it.
Myth 2: There is one kind of SBOM
Fact: a CISA facilitated working group describes six types: design, source, build, analyzed, deployed and runtime. They are created differently and see different things. See the six SBOM types.
Myth 3: Listing direct dependencies is enough
Fact: reporting on the 2026 minimum elements says there is no minimum depth, so transitive dependencies must be included. Our post on SBOM depth shows how to test it.
Myth 4: NONE and NOASSERTION mean the same thing
Fact: in SPDX 2.3.1, NOASSERTION means not determined or not stated, and NONE is a definite statement that nothing exists. See NOASSERTION versus NONE.
Myth 5: A signed SBOM is an accurate SBOM
Fact: a signature helps confirm the file is genuine and unaltered. Reporting on the 2026 guidance says it does not fully verify accuracy. More in what an SBOM signature proves.
Myth 6: The 2021 seven fields are still the standard
Fact: CISA says its 2026 document updates and replaces the 2021 minimum elements. The 2026 list has 17 fields according to reporting. The older seven carry over, some renamed. See which version to follow.
A bonus myth: SBOMs are legally required everywhere
Fact: it depends on the sector and the contract. The pages I fetched do not describe the 2026 guidance as creating a new legal requirement. Check the rules that apply to you instead of assuming.
Why myths matter
Wrong assumptions cause wrong decisions. A buyer who thinks an SBOM is a vulnerability report may accept a file with no matching process. A producer who thinks one source scan covers everything may claim completeness it cannot back up.
Quick check
Does an SBOM tell me what is exploitable?
No. It lists components. Exploitability needs vulnerability matching and, ideally, context such as reachability.
Is there one right SBOM type?
No. The right type depends on the question you are asking.
Sources
- CISA, Types of Software Bill of Materials (SBOM)
- CISA, 2026 Minimum Elements for a Software Bill of Materials
- FOSSA, CISA releases 2026 minimum SBOM elements
- SPDX 2.3.1 specification, package information
Last reviewed: 19 October 2026.
