Trust but Verify: A Practical Guide to Supplier SBOM Validation

Imagine this: you ask a supplier for an SBOM, and they provide one. You dutifully load it into your compliance system, and you point to it as evidence when auditors and customers ask you for details about your supply chain. These seem like solid building blocks for a reputable security program. But what happens when the SBOM is wrong? For most manufacturers of connected products, that situation is unfortunately common.

Modern products are assembled largely from code that other people wrote, including component vendors, integrators, foundational-software providers, and their suppliers in turn. Whatever regulation applies to you, whether the EU Cyber Resilience Act, FDA premarket cybersecurity expectations, ISO/SAE 21434 and UNECE R155 in automotive, or IEC 62443 in industrial settings, the accountability for that software now rests with the company that ships the finished product, not the supplier who wrote it. And the SBOMs you receive are frequently incomplete, inconsistent, or generated by tools that miss whole categories of components.

How should a manufacturer operate in an environment in which inaccurate information from your suppliers creates risk for you? Trust, but verify.

What is SBOM validation and how does it work?

SBOM validation is the process of comparing a software bill of materials against the actual binary it describes, confirming that every component is present, correctly identified, and current.

An SBOM is a machine-readable list of the software components inside a product. Learning what an SBOM is is the easy part. The harder question is whether the one in your hand is true. Most supplier SBOMs are produced from a build manifest, which records what the build system thinks went into the software. Validation checks that against what actually shipped by running binary software composition analysis on the firmware image itself, then reconciling the two lists. A validated SBOM is grounded in the binary, not in a manifest.

Why is SBOM validation critical for software supply chain security?

Because accountability sits with whoever ships the finished product. An unverified SBOM means you are vouching for software you never checked, and regulators now expect proof, not assurances.

An SBOM you cannot back up is a liability, not an asset. When a new vulnerability like Log4Shell breaks, the first question is simple: is the affected component in your product, and in which version? If your inventory is wrong, you either scramble to answer or answer incorrectly. Validation is what turns the SBOM from a document you hope is right into a system of record you can act on.

What Makes Supplier SBOMs Unreliable

Not all SBOMs are created equal. Some are generated with IDE plugins or basic manifest tools that miss critical dependencies, misstate versions, or omit binary-linked components entirely. Others carry only minimal metadata or describe what the supplier intended to ship rather than what actually ended up in the final firmware. Many lack the context you need to assess vulnerability exposure, license risk, or software lineage. Over a product’s lifetime, those omissions harden into long-term liabilities.

None of this means your suppliers are careless. An SBOM can be well-intentioned and built with mature tooling, and still incomplete. The supplier may not have visibility into its own full dependency tree, may rely on older tooling, or may not share your reading of what the regulation requires. A supplier SBOM is a starting point, but it needs verification before you can rely on it.

Shifting Accountability

Whatever framework applies to you, the expectations are converging. Each requires a form of continuous vulnerability monitoring, responsible disclosure, and ongoing security throughout the product's entire lifecycle, including for the software you did not write and cannot easily inspect.

A connected vehicle pulls ECU firmware from dozens of suppliers, much of it built on shared AUTOSAR stacks and statically compiled into each image, while the OEM still owes type-approval and audit evidence for the whole car under UNECE R155 and ISO/SAE 21434. A medical device carries embedded code that has to meet FDA premarket cybersecurity expectations and keep meeting them across a service life measured in years. An industrial controller or grid component often ships once and runs for a decade or more under IEC 62443, long after the supplier's original toolchain is gone. Software sold into government now ships with a secure-development attestation attached, under frameworks like NIST's SSDF, and that attestation is only as credible as the inventory behind it. In every case, the manufacturer answers for software it did not write and cannot fully see from the manifest alone. To answer with confidence, the manufacturer must be able to validate the supplier SBOM against actual product binaries.

Building the Verification Process

Verification does not have to be adversarial–remember, trust, but verify. Handled well, it works as a cooperative assurance step that serves both sides.

At its core, verification is a direct comparison. You run binary analysis on the same firmware or software image that the SBOM describes, then check one against the other:

• Confirm the key components are present and correctly identified.
• Flag anything in the binary-derived SBOM that the supplier missed or appears inconsistent.

Sometimes the comparison turns up genuine surprises; sometimes it confirms that a supplier's process is mature and their SBOM holds up. Either way, you come away with a security program grounded in what you actually ship.

Day to day, this runs as a seamless workflow. Supplier SBOMs come in alongside a binary scan of the matching firmware; the results are correlated automatically, and discrepancies are flagged and written up in audit-ready form. That lets you catch missing or misrepresented components, confirm whether high-risk libraries or known-vulnerable versions are present, and track how all of it changes across releases and supply-chain updates. What you end up with is a living inventory of what your products actually contain, maintained release over release instead of assembled by hand at audit time.

Verifying SBOMs is a core capability for the Finite State Product Security OS. Our platform runs the comparison at scale, and our product security analysts work with you to understand and take action on the results. We help manufacturers stand the process up across a whole portfolio, including producing the evidence you need for internal governance and regulatory response. The final decisions stay with you.

What are SBOM validation best practices?

Treat validation as continuous, not a one-time check. Keep a retained archive of every SBOM version, tie checks into your release process, use VEX to record exploitability, and revalidate on every supply-chain update.

A few practices separate teams that stay ahead of this from teams that scramble:

• Keep an SBOM archive. Retain an SBOM for every version of every product as long as it stays in the field. When the next Log4Shell lands, that archive is how you answer in minutes instead of weeks.
• Gate releases on it. Fold validation into your existing release checks so a build with an unresolved discrepancy does not ship quietly.
• Record exploitability with VEX. A component being present is not the same as it being reachable. VEX lets you document which findings actually matter and why.
• Revalidate on change. A supplier update, a new firmware revision, or a dependency bump can all change what ships. Validation is only as current as your last comparison.
• Monitor continuously after release. New vulnerabilities appear against components that were clean when you shipped. Continuous monitoring against a validated inventory is what keeps the answer accurate over a product's whole life.

The Organizational Challenge

Undertaking a new SBOM verification process has the potential to create friction. Long-standing supplier relationships and hard-won trust can make verification feel like an accusation, especially where there is no contractual precedent for checking someone else's work.

The hesitation is understandable, but the same discipline already applies to the physical side of the product, where incoming parts and safety-critical components are inspected as a matter of course; software has simply joined that list. Teams that frame SBOM verification as routine quality assurance tend to keep their supplier relationships intact and bring a whole portfolio into compliance with far less friction than teams that treat it as a one-off audit.

Verification Is Accountability

In regulated markets, supply-chain risk has become a compliance question as much as a procurement one. Trust in your suppliers still matters, and verification is what lets you extend that trust responsibly across a product you are accountable for. Confirming the SBOMs you receive is a mark of a mature program, and it is how you ship products you can vouch for and defend the decisions behind them when a regulator or a major customer asks you to show your work.

If you are building that capability now, we can help you stand it up, across one product line or a whole portfolio, and run it alongside your team. Talk to us about a managed CRA program and what it would look like for your products.