--- title: "What a 'Good' SBOM Actually Looks Like. And What Reviewers…" description: "A defensible SBOM is generated, not authored: transitive deps, exact versions, hashes, named suppliers, SOUP-mapped, CVE-monitored, and kept current postmarket." lang: en json-ld: | [ { "@context": "https://schema.org", "@type": "Person", "@id": "https://christianespinosa.com/#person", "name": "Christian Espinosa", "url": "https://christianespinosa.com/", "image": "https://christianespinosa.com/__l5e/assets-v1/de07e44b-a8e0-4bcc-bcb0-13aec15421f1/headshot-front.jpg", "sameAs": [ "https://www.facebook.com/christian.espinosa.official", "https://x.com/Ironracer", "https://www.instagram.com/christian.espinosa.official/", "https://www.youtube.com/@ChristianEspinosaOfficial", "https://www.linkedin.com/in/christianespinosa/" ], "jobTitle": "Bestselling Author, Keynote Speaker, Entrepreneur", "worksFor": { "@type": "Organization", "name": "Blue Goat Cyber", "url": "https://bluegoatcyber.com/" } }, { "@context": "https://schema.org", "@type": "WebSite", "@id": "https://christianespinosa.com/#website", "name": "Christian Espinosa", "url": "https://christianespinosa.com/", "publisher": { "@id": "https://christianespinosa.com/#organization" }, "inLanguage": "en-US" }, { "@context": "https://schema.org", "@type": "Organization", "@id": "https://christianespinosa.com/#organization", "name": "Christian Espinosa", "url": "https://christianespinosa.com/", "logo": { "@type": "ImageObject", "url": "https://christianespinosa.com/logo.svg" }, "founder": { "@id": "https://christianespinosa.com/#person" }, "sameAs": [ "https://www.facebook.com/christian.espinosa.official", "https://x.com/Ironracer", "https://www.instagram.com/christian.espinosa.official/", "https://www.youtube.com/@ChristianEspinosaOfficial", "https://www.linkedin.com/in/christianespinosa/" ] }, { "@context": "https://schema.org", "@type": "Article", "headline": "What a 'Good' SBOM Actually Looks Like. And What Reviewers Reject | Christian Espinosa", "description": "A defensible SBOM is generated, not authored: transitive deps, exact versions, hashes, named suppliers, SOUP-mapped, CVE-monitored, and kept current postmarket.", "image": "https://christianespinosa.com/__l5e/assets-v1/ae901277-8290-4307-880e-88f6573c0017/what-a-good-sbom-actually-looks-like-card.png", "datePublished": "2026-06-20T14:00:00Z", "dateModified": "2026-06-20T14:00:00Z", "mainEntityOfPage": { "@type": "WebPage", "@id": "https://christianespinosa.com/blog/what-a-good-sbom-actually-looks-like" }, "author": { "@type": "Person", "name": "Christian Espinosa", "url": "https://christianespinosa.com/about" }, "publisher": { "@type": "Organization", "name": "Christian Espinosa", "logo": { "@type": "ImageObject", "url": "https://christianespinosa.com/logo.svg" } } }, { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "What is the core idea behind \"What a 'Good' SBOM Actually Looks Like. And What Reviewers Reject\"?", "acceptedAnswer": { "@type": "Answer", "text": "An SBOM isn't a deliverable. It's a build artifact I keep current" } }, { "@type": "Question", "name": "Who is this post for?", "acceptedAnswer": { "@type": "Answer", "text": "Honestly, security leaders, medical device teams, and technical operators who want the honest version, not the vendor version. If you want a listicle, this is not that. If you want the honest version of what I have actually lived and worked through, keep reading." } }, { "@type": "Question", "name": "How do I actually apply this, not just nod along?", "acceptedAnswer": { "@type": "Answer", "text": "Pick the single line in the post that made you flinch or look away, and change one thing in your week because of it. One choice this week beats a whole framework you never touch." } }, { "@type": "Question", "name": "How does this connect to From the upcoming book?", "acceptedAnswer": { "@type": "Answer", "text": "Medical Device Cybersecurity: An In-Depth Guide; a chapter-by-chapter walkthrough of premarket submissions and postmarket surveillance, written for engineers, regulatory teams, and founders who'd rather not learn this the hard way. If the post landed, that is the natural next step; the preview the book link at the bottom of the page goes straight there." } } ] } ] --- [Skip to content](#main) [](/) [About](/about)[Speaking](/speaking)[Cybersecurity](/cybersecurity)[Programs](/programs)[Books](/books)[Media](/media) Writing Search Ctrl K[Connect](/connect) [Cybersecurity](/blog/category/cybersecurity) # What a 'Good' SBOM Actually Looks Like. And What Reviewers Reject June 20, 2026 4 min read 838 words An SBOM isn't a deliverable. It's a build artifact I keep current ![](/__l5e/assets-v1/9a9ef5b5-9846-4454-8c1e-36e39ca0fddc/what-a-good-sbom-actually-looks-like-hero.webp) Published June 20, 2026 Read time 4 min In this essay 1. [01 What A Defensible SBOM Looks Like In 2026 ](#what-a-defensible-sbom-looks-like-in-2026) 2. [02 Where Reviewers Actually Look First ](#where-reviewers-actually-look-first) 3. [03 The Failure Modes We See Most ](#the-failure-modes-we-see-most) 4. [04 Tie It To A Process A Reviewer Can See ](#tie-it-to-a-process-a-reviewer-can-see) Jump to 1. [01 What A Defensible SBOM Looks Like In 2026 ](#what-a-defensible-sbom-looks-like-in-2026) 2. [02 Where Reviewers Actually Look First ](#where-reviewers-actually-look-first) 3. [03 The Failure Modes We See Most ](#the-failure-modes-we-see-most) 4. [04 Tie It To A Process A Reviewer Can See ](#tie-it-to-a-process-a-reviewer-can-see) The takeaways 1. 01 Generate the SBOM from your build pipeline; never hand-author it. What to do next Ask your security lead this week for the one-page view of sbom in your environment, and read it end to end. 2. 02 Include transitive dependencies with exact versions, hashes, and named suppliers. What to do next Ask your security lead this week for the one-page view of include in your environment, and read it end to end. 3. 03 Map every component to a SOUP analysis that names function, risk, and mitigation. What to do next Ask your security lead this week for the one-page view of risk in your environment, and read it end to end. 4. 04 Pair the SBOM with a documented CVE monitoring and triage process. What to do next Add sbom to the next leadership review as a standing item, not a one-time slide. 5. 05 Keep it accurate postmarket; a frozen SBOM is a future deficiency. What to do next Add postmarket to the next leadership review as a standing item, not a one-time slide. Editor's note Adapted from Chapter 8 of Medical Device Cybersecurity: An In-Depth Guide, which covers third-party components, SOUP analysis, and the practical mechanics of SBOM generation and management. SBOM is the simplest deliverable in a submission and the one that exposes the most about a team's underlying engineering discipline. The Software Bill of Materials has become the most misunderstood requirement in my medical device submissions. My teams treat it as a one-time spreadsheet exercise. I see 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. My build pipeline produces the SBOM; 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. > “A spreadsheet someone typed is not an SBOM. If a human is maintaining it by hand, it's already wrong.” Frequently asked ### What is the core idea behind "What a 'Good' SBOM Actually Looks Like. And What Reviewers Reject"? ### Who is this post for? ### How do I actually apply this, not just nod along? ### How does this connect to From the upcoming book? ### From the upcoming book Medical Device Cybersecurity: An In-Depth Guide; a chapter-by-chapter walkthrough of premarket submissions and postmarket surveillance, written for engineers, regulatory teams, and founders who'd rather not learn this the hard way. [Preview the book](/books/medical-device-cybersecurity) Share this essay [X ](https://twitter.com/intent/tweet?url=https%3A%2F%2Fchristianespinosa.com%2Fblog%2Fwhat-a-good-sbom-actually-looks-like&text=What%20a%20'Good'%20SBOM%20Actually%20Looks%20Like.%20And%20What%20Reviewers%20Reject) [LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fchristianespinosa.com%2Fblog%2Fwhat-a-good-sbom-actually-looks-like) [Facebook](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fchristianespinosa.com%2Fblog%2Fwhat-a-good-sbom-actually-looks-like) [Email](mailto:?subject=What%20a%20'Good'%20SBOM%20Actually%20Looks%20Like.%20And%20What%20Reviewers%20Reject&body=https%3A%2F%2Fchristianespinosa.com%2Fblog%2Fwhat-a-good-sbom-actually-looks-like)Copy link ![Christian Espinosa, headshot](/__l5e/assets-v1/de07e44b-a8e0-4bcc-bcb0-13aec15421f1/headshot-front.jpg) About the author [Christian Espinosa](/about) · Founder & CEO, Blue Goat Cyber I'm the founder and CEO of Blue Goat Cyber, a medical device cybersecurity firm where my team has supported 250+ FDA submissions with zero failing to clear on cybersecurity. I previously founded and sold Alpine Security. I host The Med Device Cyber Podcast and wrote The Smartest Person in the Room and The In-Between: Life in the Micro, with Medical Device Cybersecurity: An In-Depth Guide out in 2026. Air Force Academy grad, 24x Ironman, climber of two of the Seven Summits. Keep reading - [ ### Total Product Lifecycle: The Framing That Fixes Most Submissions Why the SBOM is a postmarket asset, not a premarket deliverable; and what changes when you treat it that way. Read essay → ](/blog/total-product-lifecycle-the-framing-that-fixes-most-submissions) - [ ### FDA Premarket Cybersecurity: What the 2026 Guidance Actually Requires The SBOM and SOUM expectations in the 2026 premarket guidance, summarized for submission teams. Read essay → ](/blog/fda-premarket-cybersecurity-what-the-2026-guidance-actually-requires) [← Previous essay If Your Reviewer Can't See the System, You Don't Have an Architecture | Christian Espinosa ](/blog/if-your-reviewer-cant-see-the-system-you-dont-have-an-architecture)[Next essay → The Ultrasound That Found My Clots: Why Medical Device Cybersecurity Is Personal | Christian Espinosa ](/blog/the-ultrasound-that-found-my-clots) Related, Cybersecurity ### Need medical-device or offensive security expertise? Blue Goat Cyber, Christian's firm, runs FDA-aligned premarket submissions, penetration testing, and SBOM/SOUP analysis for medtech and high-stakes industries. [Explore Blue Goat Cyber](/cybersecurity) Christian Espinosa Bestselling author, keynote speaker, and Founding CEO of [Blue Goat Cyber](https://bluegoatcyber.com/). Helping technical leaders develop the soft skills that turn brilliance into impact. [](https://www.linkedin.com/in/christianespinosa/)[](https://x.com/Ironracer)[](https://www.instagram.com/christian.espinosa.official/)[](https://www.youtube.com/@ChristianEspinosaOfficial)[](https://www.facebook.com/christian.espinosa.official) Explore - [About](/about) - [Timeline](/timeline) - [Speaking](/speaking) - [Cybersecurity](/cybersecurity) - [Programs](/programs) Read - [Books](/books) - [Guides](/guides) - [Blog](/blog) - [Media](/media) - [Podcast Interviews](/podcasts) - [Success Stories](/success-stories) Connect - [Contact Christian](/connect) - [LinkedIn ↗](https://www.linkedin.com/in/christianespinosa/) - [Blue Goat Cyber ↗](https://bluegoatcyber.com/) - [Resources](/resources) © 2026 Christian Espinosa. All rights reserved. [Privacy](/privacy-policy)[Terms](/terms-of-use)