Episode 2

What’s in Your SBOM?

Episode Overview

Your software has a supply chain. Your SBOM is supposed to tell you what’s inside. But what makes a Software Bill of Materials truly useful; and why is everyone suddenly asking for one? In this episode of Sushi Bytes, Shinobi unpacks what an SBOM is, why regulatory pressure is turning it from best practice to business-critical and why spinning off “AI-BOMs” and “API-BOMs” just adds noise. Software is software. Let’s keep it simple… and get it right.

Show Transcript

Welcome back to Sushi Bytes—sharp insights on software supply chain integrity.

I’m Shinobi, your AI-generated Software Composition Analysis ninja, helping you navigate open source license compliance, security, and regulatory chaos… one byte at a time.

Today’s topic: What’s in your SBOM?

It’s more than just a checklist item. It’s the blueprint of your software supply chain. And, it may be a regulatory requirement for your business – if not now, soon.

Let’s start simply with What is an SBOM and Why they exist.

An SBOM, or Software Bill of Materials, is a structured list of all the components in your software.

Think of it like a nutrition label for an application—it tells you:

What components are inside (open source, third-party, proprietary)
What versions they are
What licenses they’re under
Where they came from

Why does this matter?

Because you can’t secure or manage what you can’t see. And in a world of nested dependencies, transitive packages, and AI-assisted code, visibility is your first line of defense.

SBOMs started as a best practice. Now? They’re becoming a compliance obligation.

Here’s what’s changing:

U.S. Executive Order 14028 pushed federal agencies to require SBOMs from their vendors.
For instance, the U.S. Army mandated in August 2024 that software vendors provide SBOMs for all new software contracts, including commercial off-the-shelf products, effective February 2025.
The NTIA and CISA are driving SBOM standardization through SPDX, CycloneDX, and others.
In Europe, the CRA (Cyber Resilience Act) and Product Liability reform are raising the bar for software transparency. And this will have global implications.
And in regulated industries like telecom, medical devices, automotive, and aerospace, SBOMs are fast becoming a prerequisite for market entry.

In short: If you build or sell software, plan on someone asking you for an SBOM. You just need to ask yourself – will it be ready? And will it be reliable?

But lately there has been a BOM Explosion – AI-BOMs, API-BOMs, SaaS-BOMs… Wait, What?!

Yeah, here’s where things get messy.

As awareness of SBOMs has grown, and we’ve discovered different commonalities within a software type or an industry, new BOM terminology is flying around.

You’ll hear things like:

AI-BOMs for tracking machine-generated code
API-BOMs for listing connected services and external interfaces
Cloud-BOMs, SaaS-BOMs, and even Data-BOMs

Now don’t get me wrong – visibility is good.

But fragmenting the BOM concept into dozens of specialized documents? Makes me want to drop an F-BOM!

Let’s not lose the plot:
In my humble ninja opinion, Software is software. Whether it’s written by a human or a language model, compiled on-prem or running in a container – it should be tracked in one unified bill… a software bill of materials. Let’s not derail our progress by creating a Tower of Babel.

At FossID, we believe in keeping it simple:
Complexity doesn’t improve compliance – it just obscures risk. OK, stepping off my soap box.

What makes an SBOM actually useful?

A good SBOM is:

Complete – including all direct and transitive third-party components
Informative – with clear license, version, and source metadata
Shareable – using standard formats like SPDX or CycloneDX
Tied to scans – not a stale artifact, but a reflection of current reality
Connected to policy – ideally with insights on obligations, risks, or gaps

Most importantly, an SBOM should integrate into your workflow, not live in a spreadsheet graveyard.

Alright, you may be asking, so what should I do next?

Here’s how to get ahead of the SBOM curve:

Run an SCA scan across your projects – not just a simple dependency analysis of your package managers. Enterprise tooling like FossID detect all components, including code snippets and modified files which is more and more common with AI coding assistants.
Export your SBOM in SPDX or CycloneDX format. Make sure it’s machine-readable and up to date.
Align with policy – use your SBOM not just as inventory, but as a control mechanism for license compliance and security posture.
Push back on BOM inflation – don’t drown in a sea of acronyms. Keep it simple and consistent. Stick to one clear SBOM that reflects what’s running.

So, what’s in your SBOM?

If the answer is “I’m not sure” – you’re not alone. But now’s the time to get clarity. Because regulators, customers, and your own security team will soon expect you to know.

I hope that helps! Have a comment or question, hit us up! Thanks for tuning in to Sushi Bytes.

In our next episode, we’ll decode another acronym: VEX— how it relates to SBOMs and how it separates security noise from real risk.

Until then – scan early, scan often, and sharpen your software supply chain.

Talk to you later!