Your Supplier Sent You an SBOM. Can You Actually Trust It?
| Interlynk
A supplier SBOM is a claim, not a verified fact. Here is how to tell whether the one you received is good enough to act on, framed by the ENISA advisory and scored with sbomqs.
Overview
More teams are asking suppliers for an SBOM, and more suppliers are sending one back. That is progress. But receiving a file tells you very little about whether it accurately describes the software you were delivered.
The SBOM might have been generated from a source tree that differs from the shipped binary. It might omit transitive dependencies or bundled components. Or its component identifiers might be too weak to support reliable vulnerability matching.
In each case, the organization can say it has an SBOM. The harder question is whether it can rely on it.
In October 2026, ENISA published a Technical Advisory for Software Bill of Materials that treats this as a lifecycle problem: generation, validation, distribution, and the threats to SBOM integrity along the way. It is a useful frame, and it is a timely reason to be clear about something that often goes unsaid. Collecting SBOMs is not the goal. Being able to act on them is.
The line to hold is this: do not measure your SBOM program by how many files you collect. Measure it by how confidently you can use them to make a security decision. This post lays out the three levels of trust an SBOM has to earn, five concrete checks to apply to a supplier's SBOM, and how to score quality in practice with sbomqs without overstating what a score proves.
Key Facts
Receiving an SBOM is not the same as trustworthy transparency. An SBOM is a claim about software composition. It has to be assessed before you rely on it.
There are three levels of trust: syntactic validity (does it parse and conform), inventory quality (are the components complete and usable), and artifact confidence (does it describe the thing you were actually delivered). Passing one does not give you the others.
A quality score surfaces weaknesses; it does not certify truth. A tool like sbomqs will flag missing fields, weak identifiers, and absent integrity data. It cannot prove that a supplier disclosed every component or that a binary matches the inventory.
Coverage determines usefulness. The SBOM should cover the components relevant to the product and its intended security use. Depending on the software, that may require transitive dependencies, bundled runtimes, static libraries, vendor SDKs, operating-system packages, or components identified through binary analysis. A manifest alone may not be enough.
Validity is not integrity. A perfectly valid SBOM can still fail to describe the delivered artifact. Release traceability needs separate evidence: hashes, signatures, and build provenance can help associate an SBOM with a release and establish artifact identity or origin, but they do not, individually, prove that the inventory is complete.
An SBOM Is a Claim, Not a Verified Fact
Be blunt about what a supplier SBOM is. It is a statement from the supplier that says "here is what we believe is inside this product." It is evidence, and useful evidence, but it is not self-proving. The supplier may have generated it from the wrong input, may have tooling that misses whole classes of component, or may simply not know everything that a complex product contains.
Treating the file as settled fact is how teams end up with a library of SBOMs they cannot actually use when a vulnerability lands. The more useful posture is the one a security reviewer takes with any supplier claim: accept it, then assess it. The rest of this post is how to do that assessment efficiently.
Three Levels of Trust
For practical supplier reviews, it helps to separate SBOM trust into three questions. These levels are a working framework for evaluating an SBOM, not an official classification from ENISA or CISA, and they are not interchangeable. Confusing them is the single most common mistake in SBOM programs.
Syntactic validity. Can the file be parsed, and does it conform to CycloneDX or SPDX. This is the floor. A validator or schema check answers it. It is necessary and it is the weakest of the three, because a file can be flawless JSON and still describe the wrong software.
Inventory quality. Are the components identified unambiguously, with versions and relationships, and is the inventory complete enough to be useful. This is where most of the day-to-day value and most of the failure lives. A valid SBOM with vague identifiers or a shallow component list will not support vulnerability matching, which is the whole point.
Artifact confidence. Is there evidence that this SBOM corresponds to the exact software artifact the supplier delivered. This is the hardest level and the one most often skipped. An SBOM generated from a source tree can be valid and high quality and still not describe the binary that shipped, because something changed between source and release.
A supplier SBOM can clear the first level, do reasonably well at the second, and offer nothing at the third. Knowing which level you are looking at tells you how much weight the file can bear.
Five Checks for a Supplier SBOM
Run this pass on any SBOM a supplier hands you. For each check, the same four things: what to inspect, why it matters, what a failure looks like, and what to do next.
1. Identity
Inspect how components are identified. Look for unambiguous identifiers such as package URLs (purl) and CPEs, with concrete versions, not just names.
Why it matters: vulnerability matching is only as good as the identifiers. If a component is named one way in this SBOM and another way in a feed, the match silently fails.
What failure looks like: components with names but no versions, missing or inconsistent purls, or the same component identified differently across the supplier's own SBOMs.
What to do: ask the supplier to regenerate with proper identifiers, or treat the weakly identified components as a known gap you have to resolve manually.
2. Coverage
Inspect how deep the inventory goes. A real product is more than its direct dependencies.
Why it matters: a vulnerable or malicious component may be transitive, bundled into a larger SDK, statically linked into firmware, or baked into a container image. An SBOM that stops at the top level can miss components that matter to your security assessment.
What failure looks like: a short, tidy list of direct dependencies with no transitive graph, no operating-system packages for a container, or no vendored and static libraries for firmware.
What to do: ask what generation method produced the SBOM, and whether it was built from the final artifact or from a manifest. A manifest-only SBOM for an embedded or containerized product should prompt further questions about which components it captures and which remain outside its scope.
3. Artifact Alignment and Integrity
This is the check teams skip, and it is worth breaking into three separate questions rather than one.
First, can the supplier associate the SBOM with a specific product version or release artifact. Second, can you verify that the artifact you received is the one the supplier intended to deliver. Third, is there evidence that the SBOM was generated from, or otherwise accurately represents, that artifact.
Why it matters: a valid, complete SBOM for the wrong build is misleading in a way that a missing SBOM is not. The OVHcloud CLI compromise in October 2026, where attackers swapped the published binaries while the source stayed clean, is the reminder that the artifact and the source can tell different stories.
What the integrity tools actually prove, and do not: a component hash identifies a particular component artifact. A hash provides a fingerprint of the release artifact. Comparing it with a trusted reference hash can help verify that the delivered artifact is the expected one. A signature can verify that a document or artifact was signed by a particular key, but the trustworthiness of that signature also depends on how the key and its identity are verified. Provenance describes how an artifact was built. None of these, on its own, proves the software is benign or that the SBOM lists every component. They establish alignment and origin, not safety or completeness.
What failure looks like: an SBOM with no version binding, no hashes, no signature, and no way to tell which release it belongs to.
What to do: ask the supplier to associate the SBOM with a specific product release and, where feasible, provide verifiable evidence linking the inventory to the delivered artifact. This may include artifact hashes, a signed SBOM, or build provenance. Verify what each piece of evidence establishes rather than treating any one of them as proof of completeness or safety. For firmware, embedded software, and anything with statically linked or vendor-supplied components, press hardest here, because that is where source and artifact diverge most.
4. Freshness and Generation Context
Inspect when and how the SBOM was generated. Look for a timestamp, the generating tool, and the author or supplier.
Why it matters: an SBOM generated months ago, or before a later build step changed the artifact, may no longer describe what you run. The 2026 SBOM Minimum Elements expand the metadata available to assess an inventory, including generation context, tool name and version, component hashes, and an SBOM author signature. These fields provide useful evidence about how the SBOM was produced and what it identifies, although they do not independently prove that it accurately represents the delivered artifact.
What failure looks like: no timestamp, no tool identification, no author, or a generation date that predates the release you were given.
What to do: ask for an SBOM generated as part of the build that produced your artifact, not a one-off produced by hand after the fact.
5. Actionability
Inspect whether you can actually use the SBOM to answer a security question. The practical test: when a CVE or a malicious-package advisory names a component, can you match it against this SBOM and get a reliable answer.
Why it matters: this is the reason you asked for the SBOM in the first place. Everything above feeds into it. Our companion piece on what an SBOM does during a supply-chain attack covers the response side in detail.
What failure looks like: identifiers that will not match feeds, coverage too shallow to trust a clean result, or no way to tie the SBOM back to the product and version in your environment.
What to do: run the checks above, close the gaps that matter for your risk profile, and keep the SBOM somewhere it can be matched against vulnerability intelligence on an ongoing basis, not just filed.
Putting the Checks into Practice with sbomqs
Running these checks by hand across a stack of supplier SBOMs does not scale. That is where a quality scorer comes in. sbomqs is an open-source tool for assessing SBOM quality, and the ENISA advisory lists it, alongside eBay's sbomscorecard, among the quality-scoring tools in its indicative open-source tool stack. ENISA names these tools as part of the landscape; it does not certify or endorse them, and the advisory is explicit that the list is indicative rather than exhaustive. Interlynk maintains sbomqs as an open-source project.
sbomqs produces a 0-10 quality score for a CycloneDX or SPDX SBOM, broken down across categories that line up closely with the checks above: identification, completeness, structural conformance, integrity, provenance, licensing, vulnerability, and component information. It can score against NTIA and BSI TR-03183-2 profiles, which is useful when a specific baseline applies. It can quickly surface issues such as missing versions, weak component identification, incomplete metadata, and absent integrity fields, helping reviewers focus their manual investigation on the gaps that matter.
Now the honest limit, and it matters. A quality score measures defined aspects of an SBOM's structure and content, such as whether expected fields are populated, component identifiers are present, dependency relationships are documented, and integrity or provenance information is included. It cannot establish that the inventory contains every component actually present in the delivered software. sbomqs scoring "integrity" high means the SBOM contains integrity data such as component hashes, not that anyone verified the delivered binary against them. Scoring "completeness" high means the expected fields are populated, not that the supplier actually disclosed every component. The score is a fast, repeatable way to find weaknesses and compare SBOMs on a common scale. It is not a certificate of truth, and no quality tool can be one. Used with that understanding, it turns the five checks into something you can run at scale and track over time.
Known Unknowns
A mature SBOM program does not treat every missing field as an automatic failure, because some gaps are real and unavoidable. A supplier may genuinely not know every component in a complex product. A vendor-supplied binary may arrive with no detailed metadata. A statically linked dependency may be hard to identify precisely. Pretending these do not exist produces a worse outcome than naming them.
The ENISA advisory makes the same point in its own language, recommending documented treatment of known unknowns and missing metadata. The goal is to make the gaps visible rather than invisible: record what is unknown, understand why, and decide whether that uncertainty is acceptable for the product's risk profile. A medical device or an industrial controller warrants a lower tolerance for unknowns than an internal tool. An SBOM that honestly flags what it could not determine is more trustworthy than one that looks complete because the generator quietly dropped what it could not resolve.
Where Interlynk Fits
These three jobs are distinct, and keeping them distinct is the point.
sbomqs is the entry point: an open-source way to assess the quality of an SBOM and surface its weaknesses, yours or a supplier's. It is free to run and it is where this kind of review starts.
lynkctl is for generation: it generates build-aware SBOMs for supported builds and software environments, helping teams capture transitive dependencies, static libraries, vendor SDKs, bundled runtimes, and components in firmware and container images that a manifest-only approach may miss. It is how a supplier produces an SBOM that passes the checks above in the first place.
The Interlynk platform is the operational layer: it ingests SBOMs and CBOMs, evaluates their quality, risk-assesses components against vulnerability data, manages the VEX assertions that record your position per product, and notifies stakeholders when a new disclosure changes the exposure of something already shipped. Our guide to operationalizing VEX covers that workflow, and our note on the CISA 2026 minimum elements sets the baseline the quality checks build on.
None of these replaces the others, and a quality score does not substitute for generation or for the operational workflow. A supplier or manufacturer first needs an inventory that is actually useful, then needs to connect that inventory to products, releases, vulnerabilities, and response decisions. Quality scoring helps you assess the inventory you have. Generation helps you produce better inventories. The platform connects those inventories to products, vulnerabilities, VEX assessments, and response workflows.
The Bottom Line
A supplier SBOM is a claim about software composition. Before relying on it, assess three things: whether the file is valid, whether its contents are useful, and whether it accurately represents the artifact you received.
Five checks help structure that review: identity, coverage, artifact alignment, freshness, and actionability. A quality scorer such as sbomqs can make parts of the review repeatable, but it cannot certify that the inventory is true.
Collecting SBOMs was never the goal. The goal is to reach the point where a new vulnerability or a compromised package produces a fast, reliable answer about which of your products are affected. That only happens when the inventories you hold are good enough to act on. Measure the program by that, not by the size of the folder.
Frequently Asked Questions
How do I know if an SBOM is good quality? Assess it at three levels: does it parse and conform to CycloneDX or SPDX, are its components identified and documented well enough to be useful, and is there evidence it describes the exact artifact you were delivered. A quality scorer such as sbomqs can quickly assess many aspects of structure and content. Assessing actual inventory coverage and confirming alignment with the delivered artifact require additional evidence and investigation.
Can I trust an SBOM a supplier gave me? Not on receipt. An SBOM is a claim about software composition, not a verified fact. Run a quality and coverage check, confirm it is tied to the specific release, and decide whether any gaps are acceptable for that product's risk profile before relying on it.
What is sbomqs and what does it check? sbomqs is an open-source tool, maintained by Interlynk, that scores the quality of a CycloneDX or SPDX SBOM on a 0-10 scale across categories including identification, completeness, structural conformance, integrity, provenance, licensing, and vulnerability, with NTIA and BSI profiles available. The ENISA SBOM advisory lists it among quality-scoring tools in its indicative tool stack.
Does a high SBOM quality score mean the SBOM is accurate? No. A high score indicates strong results across the quality checks included in the scoring configuration. It does not prove that the supplier disclosed every component or that the delivered binary matches the inventory. Even a high score for integrity-related checks does not establish that anyone verified the delivered artifact against the SBOM. A score surfaces weaknesses; it does not certify truth.
What should a good SBOM contain? A useful SBOM should identify components as precisely as possible, include versions and dependency relationships where available, and provide metadata about its generation, such as the tool and timestamp. Coverage should reflect the product and the SBOM's intended use. Where artifact-level assurance matters, hashes, signatures, or build provenance can provide additional evidence linking the SBOM to a specific release. The applicable requirements and the 2026 SBOM Minimum Elements provide further guidance.
How do I verify that an SBOM matches the software I was delivered? Ask whether the SBOM is associated with a specific release artifact. Where possible, verify the delivered artifact against an independently authenticated hash or signature, and look for build provenance or an attestation linking the SBOM to that artifact. A signed SBOM alone does not prove that its inventory is complete or that it accurately represents the delivered software.
Sources
ENISA, Technical Advisory for Software Bill of Materials (v1.10, October 2026)
2026 Minimum Elements for a Software Bill of Materials (CISA and international partners, via ACSC)
AWS, "sbomqs and open source tools to quality-check your SBOMs"
About Interlynk. Interlynk helps teams generate, manage, and operationalize SBOMs across the software supply chain. sbomqs, its open-source quality scorer, assesses SBOMs against NTIA, BSI, and other baselines. lynkctl produces build-aware SBOMs for embedded and firmware software, capturing bundled runtimes and transitive, static, and SDK components with precise identifiers. The Interlynk platform ingests SBOMs and CBOMs, evaluates them for completeness and quality, risk-assesses components against vulnerability data, manages VEX assertions, and notifies teams when exposure changes.
This article is informational and does not constitute security or legal advice. Confirm current standards, advisories, and tool capabilities against the primary sources before acting.