An SBOM (software bill of materials) for an application is a machine-readable list of every component inside it: your direct dependencies, the libraries those pull in, their versions, licenses and the relationships between them. To make one that is worth

having, generate it inside your build, ship it in CycloneDX or SPDX, record which dependencies are direct and which are transitive, pair it with VEX statements, and regenerate it on every release.

Most teams can produce the file in an afternoon. The hard part is the second month, when a new CVE lands and someone asks, “Are we affected?” This guide covers both halves: what to put in the document, and how to make sure you can actually query it.

TL;DR

  • An application SBOM is an ingredients list. CISA’s July 2026 minimum elements now include component hash, component license, SBOM tool name and generation context.
  • Pick CycloneDX or SPDX based on what your customers’ tools can read, and generate the SBOM during the build, not after it.
  • Include dependency relationships. A flat list is much less useful for prioritizing fixes.
  • Publish VEX alongside the SBOM, and automate regeneration on every build so the document never goes stale.
  • Build the query path and the incident runbook before you need them.

Table of Contents

What an SBOM covers in an application

Think of the label on a food package. OWASP’s DevSecOps Guideline describes an SBOM as a formal, machine-readable inventory of the components that make up a piece of software, including open-source and third-party dependencies, versions and relationships. NIST describes it in similar terms, citing the definition in Executive Order 14028 as a formal record of the details and supply chain relationships of the components used in building software.

For a typical web or mobile application, that means:

  • Package manager dependencies (npm, PyPI, Maven, RubyGems, Go modules and so on), including the ones you never chose directly.
  • Container base images and the operating system packages inside them.
  • Vendored or copied code, bundled front-end libraries and SDKs.
  • Build tooling that ends up in the artifact.

The unit matters. An SBOM describes one application at one version, built one way. The SBOM for your API service is not the SBOM for your admin dashboard, and the SBOM for last month’s release is not the SBOM for today’s.

The fields every application SBOM needs

CISA, the NSA, the FBI and international partners released the 2026 Minimum Elements for a Software Bill of Materials on July 29, 2026, updating and replacing the earlier baseline. The core data fields include component name, version, producer, license and cryptographic hashes. Newer additions are the component hash algorithm, component license, SBOM tool name and SBOM generation context.

In practice, check your output for each of these:

Field Why it matters to you
Component name and version The basis for matching against vulnerability databases
Producer or supplier Tells you who to contact or who has to patch
License Lets legal review copyleft and attribution obligations without reading code
Hash and hash algorithm Confirms the component you shipped is the one you listed
Dependency relationships Separates direct from transitive dependencies for triage
Tool name and generation context Shows how the SBOM was made, for example during build or from a scan of the finished artifact

If your tool emits names and versions only, you have a start but not a complete document. Run it against the current CISA list and see what is missing.

CycloneDX or SPDX

The two machine-processable formats in wide use are CycloneDX and SPDX. OWASP’s guidance notes that CycloneDX is often cited for strong vulnerability-analysis tooling, while SPDX is an international standard, ISO/IEC 5962:2021. Current versions are CycloneDX 1.7 (standardized as ECMA-424) and SPDX 3.0.x.

Here is how we decide for an application team:

  1. Ask your consumers first. If a customer’s procurement team or scanner reads one format and not the other, that settles it. The guidance is to make sure your format stays compatible with the tools of the people receiving it.
  2. Default to CycloneDX for security-driven workflows. It lines up well with vulnerability scanning and VEX.
  3. Choose SPDX when license compliance or an ISO-recognized format is the main driver.
  4. Emit both if it is cheap. Most open-source generators can output either. A 2026 comparison of generators shows that tools such as Syft, Trivy and cdxgen read source directories and container images, and that several produce both CycloneDX and SPDX.

Do not agonize. Format choice is reversible. Missing relationships and stale data are the mistakes that hurt.

Generate it during the build

This is the single most common mistake we see. Scanning a finished artifact and calling that your SBOM is convenient, but OWASP warns that post-build SBOMs are reconstructions that often miss critical path details. Generating during the build captures the exact resolved dependency tree: the versions your lockfile and resolver actually pulled in on that run.

A workable pattern for a CI pipeline:

  1. Run the generator as a build step, after dependencies resolve and before packaging.
  2. Write the SBOM to a versioned artifact path tied to the commit and build number.
  3. Sign or attest it if your pipeline supports that, so consumers can verify it.
  4. Store it somewhere queryable, not just as a zipped file on a build server.
  5. Fail the build, or at least raise a warning, if the SBOM is missing or empty.

If your pipeline is a tangle of hand-edited scripts, this is a good moment to look at it as a whole. Our Continuous Integration (CI) Assessment reviews exactly where such a step belongs, and our guide to the SLSA framework maps build integrity levels to common CI/CD builders.

Show the relationships, not a flat list

A list of 1,400 packages tells you little when a critical CVE appears in one of them. What you need to know is whether your code calls it directly, or whether it arrived three levels down through a library you barely remember adding.

Guidance cited by the FBI’s IC3 says a quality SBOM must explicitly define relationships between components, such as direct versus transitive dependencies, because that hierarchy is essential for prioritizing risk and remediating vulnerabilities. Many teams still ship flat lists.

What to do about it:

  • Confirm your generator reads lockfiles, not just manifests. Manifests show what you asked for. Lockfiles show what you got.
  • Open the output and check that a known transitive dependency has a parent.
  • Keep one SBOM per deployable, with the container layer and the language layer connected, not two unrelated files.

Pair the SBOM with VEX

An SBOM lists what is inside. It does not say whether a given vulnerability can actually be exploited in your application. Without that context, every consumer’s scanner lights up for every CVE in every component.

That is what Vulnerability Exploitability eXchange (VEX) is for. OWASP’s guidance says not to publish an SBOM without an accompanying VEX document, because blanket alerts for unreachable or non-exploitable issues erode trust in your transparency efforts. The CISA minimum elements document also points to security advisories such as VEX as part of the broader approach.

In practice, a VEX statement says something like: this component is present, the vulnerable function is never called in our code, so this CVE is not affected. Your security reviewer or a senior engineer has to make that call. It cannot be guessed, and it should not be generated by a tool that only sees the dependency list.

Keep it alive: lifecycle beats compliance

A one-time SBOM is stale the moment a new vulnerability is disclosed. OWASP’s guidance describes SBOMs as living documents and recommends automated, recurring generation alongside every build, so the data reflects what runs in production.

The NIST SSCA Forum presentation on SBOM lifecycle management frames the real question as “what do I do with it?” once you have one. The uses it points to include spotting end-of-life components, managing license risk and responding quickly when new CVEs are announced.

A minimal operating loop looks like this:

  • Every build: generate, store and index the SBOM.
  • Daily or on disclosure: match stored SBOMs against fresh vulnerability data.
  • On a hit: check the dependency path, write a VEX statement or open a fix ticket.
  • Quarterly: list components that are end-of-life or unmaintained and plan replacements.

The traps: compliance theater and missing runbooks

OWASP calls out a pattern worth naming: generating SBOMs nobody ever queries. The document exists, the box is checked, and when a headline vulnerability arrives, the team greps repositories by hand. The fix is to build the query capability and the incident response runbook before the crisis.

A short runbook to write this week:

  1. Who is on call for a supply chain disclosure?
  2. Where do you search to find every application that includes component X at version Y?
  3. How long should that answer take? Set a target and test it with a drill.
  4. Who decides whether something is exploitable, and who publishes the VEX?
  5. How do customers hear from you?

Run the drill with a real past CVE. You will find the gaps in an hour.

Our perspective: AI-generated code makes the inventory harder

We see a pattern in the applications that come to us. A founder or small team used an AI assistant to get a prototype running. It works. It also pulled in a pile of packages nobody reviewed, pinned some versions and left others floating, and copied snippets from who knows where. That is the prototype trap: the demo runs, but nobody can say what is inside it.

An SBOM is the quickest honest answer to that question. When we review an application, whether it was hand-written, assisted or fully vibe-coded, the dependency inventory is one of the first things we look at, because it tells us how much surface area exists and how much of it anyone chose on purpose.

Our view, in plain terms:

  • Generate in the build, every build. Anything else is a reconstruction.
  • Smaller is safer. The cheapest vulnerability to fix is the dependency you removed. We often cut dozens of packages that only existed because an assistant reached for a library when ten lines of code would do.
  • A document you never query is not a control. Tie it to alerts and a runbook.
  • Keep a human in the loop. Tools produce the list. An experienced engineer decides what is reachable, what to replace and what to leave alone.
  • Support does not end at launch. The SBOM changes every release, so someone has to own it afterward.

If your code is the product, treat the inventory as part of the product.

— Chad

When you need more than a tool

An open-source generator will give you a file. It will not tell you whether your pipeline is sound, whether your AI-written code has deeper problems, or who will keep this running next quarter. That is where we come in.

At Bowtie, a few offers fit this work, with prices as published on our site:

  • Vibe Check, $449 one-off. A review aimed at nontechnical founders holding AI-generated or vibe-coded apps, so you know what is inside before customers or auditors ask. Details are on our vibe code review page.
  • ShipDoctor scan, $59 one-off, on the same page, for a fast first look.
  • Continuous Integration (CI) Assessment, $4,500 one-off, which looks at where SBOM generation, signing and storage belong in your pipeline.
  • Ship Shape Service, from $1,850 per month, and Crew Service, from $2,950 per month, for ongoing support after launch.

You can see the full list of one-off services on our pricing page. If your question is broader than the SBOM, our application security assessment guide explains how we approach it.

Putting it together: a one-week plan

You do not need a program to begin. Here is a week that gets a small team from nothing to something useful.

Day 1: Inventory the applications. List every deployable you ship, with its repo, language, package manager and container image. Skip nothing because it is internal.

Day 2: Pick a format and a generator. Confirm what your customers read. Try one open-source generator on one repository and compare the output with the CISA fields above.

Day 3: Add it to CI. Generate during the build, store the artifact with the build number, and fail loudly if it is missing.

Day 4: Check the relationships. Pick three transitive dependencies and confirm each has a parent in the output. If not, switch generator mode or inputs until it does.

Day 5: Write the runbook and run a drill. Choose a real past CVE, search your stored SBOMs, time it and record who decided what.

After that, add VEX for the findings that matter, and schedule a quarterly review of end-of-life components. If you want a second pair of eyes on the pipeline or on code you did not write yourself, our software architecture review checklist is a good place to start.

Putting it together: a one-week plan — overview diagram

Beyond SBOM: CBOM and cryptographic inventory

You will see the term CBOM next to SBOM. A Cryptographic Bill of Materials inventories cryptographic assets such as algorithms, keys and certificates, rather than application components. A NIST presentation on the evolving BOM ecosystem describes CBOM as a way to track their security posture, including alignment with NIST cryptographic standards.

If your application handles regulated data, it is worth knowing about. Start with the SBOM, though. It is the foundation, and the same generation pipeline can be extended later.

FAQ

What does SBOM mean in cybersecurity?

It stands for software bill of materials, a nested, machine-readable inventory of the components inside a piece of software. Security teams use it to find out quickly whether a newly disclosed vulnerability affects them, and to understand where components came from. CISA’s SBOM topic page describes it as a list of ingredients.

What is the difference between an SBOM and a CBOM?

An SBOM lists application and dependency components. A CBOM lists the cryptographic assets used inside an application, such as algorithms, keys and certificates. They complement each other, and CycloneDX can describe both.

Should I choose CycloneDX or SPDX?

Choose the one your customers and tools can consume, since compatibility matters more than preference. CycloneDX is widely used in vulnerability workflows, and SPDX is an ISO/IEC standard (5962:2021). Many generators can output both, so you can serve each audience.

How often should I regenerate my SBOM?

On every build that you deploy or ship. A one-time SBOM goes out of date as soon as a new vulnerability is disclosed, and a document that does not match production misleads more than it helps. Automating generation in CI removes the effort.

Do I need VEX if I already have an SBOM?

If you share the SBOM outside your team, yes. Without VEX, recipients get alerts for every vulnerability in every component, including ones that cannot be exploited in your application. A VEX statement tells them which findings actually matter.

Sources