Explain My BuildSoftware bill of materials (SBOM), explained
Last updated: July 26, 2026
A software bill of materials (SBOM) is an ingredients list for your app: every third-party package it depends on, and their versions. It matters because when one of those packages is found to be vulnerable or compromised, an SBOM lets you know in minutes whether your app is affected.
What is a software bill of materials?
A software bill of materials is a complete, itemized list of the third-party building blocks your app is made of. Modern apps are assembled, not written from scratch: your code sits on top of dozens or hundreds of open-source packages ("dependencies"), and those packages depend on others in turn. An SBOM writes all of that down, with names and versions, like a nutrition label for software.
There are standard formats for it, mainly SPDX and CycloneDX, so an SBOM can be read by tools, not just people. But the core idea is simple: know what you shipped.
Why does knowing your dependencies matter?
Knowing your dependencies matters because you can only protect against a problem you know you have. When a widely used package turns out to be vulnerable or gets tampered with, the urgent question is "do I use it, and which version?" With an SBOM, that is a lookup that takes minutes. Without one, it is a manual hunt through your build, and every hour counts.
This is especially relevant to AI-built apps for two reasons:
- The AI added packages on your behalf. You may be depending on things you've never heard of and didn't choose.
- A single compromised package flows to everyone who uses it, which is how a supply-chain attack works. An inventory is your first line of response.
A worked example
Imagine a news headline: "Popular npm package X, versions 4.2 through 4.5, was compromised to steal secrets." If you have an SBOM, you search it for package X, see you are on version 4.3, and know immediately you need to act. If you don't, you are left guessing whether your AI builder ever pulled X in, buried three layers deep in dependencies you never saw.
Explain My Build reads your project's dependency files and gives you a plain-English inventory of what your app is built from, as part of the founder runbook. Paired with the continuous audit, it can also flag when a dependency changes between scans. Note the honest boundary below.
What this does and doesn't do
An inventory tells you what you depend on. It is not, by itself, a live vulnerability scanner or a guarantee that every package is safe. It is the map you need before you can check the territory.
Frequently asked questions
What is the difference between an SBOM and a vulnerability scan?
An SBOM lists what your app is made of. A vulnerability scan checks that list against known security problems. The SBOM comes first: you need the inventory before you can meaningfully check it. Explain My Build focuses on giving you a clear, plain-English inventory of your dependencies.
Do I need an SBOM for a small AI-built app?
You don't need a formal, standards-compliant document. But you do benefit from knowing what your app depends on, because the AI added packages you didn't choose. A plain inventory is enough to answer "am I affected?" when a package makes the news. See supply-chain attack.
What SBOM formats exist?
The two main machine-readable standards are SPDX and CycloneDX. They let tools exchange dependency lists in a consistent way. For most founders, the format matters less than simply having an accurate list of what your app is built from.
Turn your app into a guide your users can follow.
Paste a public GitHub link and get your founder runbook + fix-list free in about a minute — no sign-up. Private code runs entirely in your browser.