What a 'Good' SBOM Actually Looks Like. And What Reviewers Reject

The Software Bill of Materials has become the most misunderstood requirement in medical device submissions.

Teams treat it as a one-time spreadsheet exercise. Reviewers treat it as a window into the maturity of your software supply chain. The gap between those two readings is where most SBOM-related deficiencies live.

What A Defensible SBOM Looks Like In 2026

Generated, not authored. A spreadsheet someone typed is not an SBOM. The SBOM is produced by your build pipeline; CycloneDX or SPDX format, generated automatically, regenerated on every release. If a human is maintaining it by hand, it's already wrong.

Complete to the transitive dependency level. Direct dependencies are the easy part. Transitive dependencies are where the vulnerabilities hide. Your SBOM has to include both; and it has to be honest about components you couldn't fully resolve.

Accurately versioned. Vague versions ("OpenSSL 3.x") are a reviewer's first red flag. Exact versions, including patch level. If you're using a fork, say so and identify the fork commit. The reject line we see most often looks like openssl, 3.x, MIT. The line that passes looks like pkg:generic/openssl@3.0.13?download_url=... with a SHA-256 hash, an SPDX license ID, and a supplier field that names a human-readable upstream; not "open source community."

Tied to a Software of Unknown Provenance (SOUP) analysis. Every third-party component is SOUP unless you can prove otherwise. Your SBOM should map to a SOUP list that documents what each component does in your device, what risks it introduces, and how you're managing them.

Paired with a vulnerability management plan. The SBOM is the input. The vulnerability monitoring process; how you watch CVEs, how you triage, how you respond; is what the reviewer is actually trying to evaluate.

Updated postmarket. An SBOM frozen at submission time is a postmarket deficiency waiting to happen. Reviewers increasingly want to see the operational process that keeps the SBOM accurate for the life of the device.

Where Reviewers Actually Look First

When a reviewer opens an SBOM, they are not reading line by line. They are running a small set of sniff tests, and the SBOM either passes them in the first few minutes or it does not.

They check whether the format is machine-readable and current (CycloneDX 1.5 or SPDX 2.3 at minimum). They look at five or ten randomly chosen lines and ask whether a human could uniquely identify and download exactly that component. They search the file for any version string ending in .x, latest, *, or a blank field. They look for at least one component they recognize as having had a recent high-severity CVE, and they cross-check whether your vulnerability management documentation acknowledges it.

If a submission fails any of those quick checks, the SBOM section is effectively flagged before substantive review begins. The deficiency letter writes itself.

The Failure Modes We See Most

A handful of patterns account for the majority of SBOM-related findings.

The "we use Yocto" non-answer. Inheriting a base image is fine. Treating the base image as a single line item is not. Yocto, Buildroot, Alpine, Debian slim; whatever the base, the components inside it are still your components. Generate the SBOM from the actual image, not from the manifest someone wrote describing it.

The container that hides a second SBOM. Cloud-side services shipped as containers have their own dependency trees. If your device talks to a cloud component that processes patient data, that component's SBOM matters too, and reviewers are increasingly asking for it.

Firmware blobs treated as opaque. A vendor-supplied binary blob with no SBOM is still SOUP. "We can't inspect it" is not a finished sentence. The finished sentence ends with "and here is the supplier attestation, the version pinning policy, and the compensating monitoring."

Licenses left blank. Missing SPDX license IDs are not just a legal problem; they signal to the reviewer that the generation pipeline is incomplete. A real SBOM resolves licenses for almost every component.

The submission SBOM and the production SBOM diverge. Whatever you filed has to match what is actually on the device. If a postmarket audit pulls firmware from a deployed unit and the components don't match the filed SBOM, the conversation is no longer about cybersecurity. It is about design controls.

Tie It To A Process A Reviewer Can See

The SBOM by itself is just a file. What earns trust is the operational pipeline around it: generation on every build, signing, storage, automated CVE matching against an authoritative feed, defined triage SLAs, defined patch SLAs, and a feedback loop into the postmarket plan.

Document that pipeline in a paragraph. Reference it from the SBOM section of the submission. The reviewer is not trying to catch you; they are trying to confirm that someone, somewhere, is actually running this every week. Show them that person and that process and the document underneath them looks completely different.

The SBOM is small. The discipline behind it is large. Reviewers read both at once.