SBOM basics: generating and reading one

TL;DR

An SBOM is an ingredient list for your software: every component, its version, and its license, in a machine-readable format. Generate one per release from your build, keep it with the artifact, and read it by searching for the component you care about. The first SBOM is the hard one, after that it is a build step.

SBOM basics: generating and reading one

Use this when

• A customer, auditor, or contract asks you for an SBOM
• You are starting supply-chain security and need a component inventory
• A CVE drops and you need to know which of your releases contain the bad component
• You want reproducible knowledge of what actually ships

Not for

• Signing SBOMs or supply-chain attestation (thats the next layer)
• Comparing SBOM generators feature by feature
• License compliance enforcement (SBOM feeds it, but it is a separate process)

Steps

1. Pick a format: SPDX or CycloneDX.

Both are standard. CycloneDX is the more common choice for vulnerability workflows, SPDX for license-heavy shops. Pick one and stick with it.

Expected: a format decision the whole team uses.

2. Generate the SBOM from your build, not by hand.

Run a generator against your built artifact or your lockfile as part of CI. The SBOM should describe the release artifact, generated at release time.

Expected: one SBOM file per release, produced automatically.

3. Verify it lists what you expect.

Open it and check: your direct dependencies are there, versions match the lockfile, and transitive dependencies are included. A spot check of three known components catches broken generators.

Expected: the SBOM matches your lockfile on the spot check.

4. Store it with the release.

Keep the SBOM next to the artifact it describes, versioned together. An SBOM you cant find for release 2.3.1 is useless when the CVE hits that version.

Expected: release 2.3.1 has its SBOM retrievable in one lookup.

5. Read it by searching, not by reading.

Nobody reads an SBOM top to bottom. To answer is component X in this release, search for the component name and read its version entry. To list everything, extract the component names and versions into a table.

Expected: a yes or no answer with the exact version, in under a minute.

6. Feed it to your scanner.

Point your vulnerability scanner at the SBOM instead of re-resolving dependencies. This gives you CVE matches per release, which is the real payoff.

Expected: per-release vulnerability reports generated from the SBOM.

Variant phrasings

What is an SBOM and do I need one

An ingredient list for your software. You need one if customers, regulators, or your own incident response ever asks what is inside a release.

How to generate an SBOM for my app

Generate from the build or lockfile in CI, in CycloneDX or SPDX format, one per release, stored with the artifact.

How to check if a CVE affects my SBOM

Search the SBOM for the component, compare its version against the advisory range. That is the whole check.

Why it happens

Modern apps ship hundreds of components you never chose directly, and without an inventory you are guessing about exposure every time a CVE drops. The SBOM exists because transitive dependencies made it impossible to know what you ship from memory. Regulations and big customers started requiring them, which is why this went from nice-to-have to mandatory.

Edge cases

• Generated SBOM misses vendored code: generators read package metadata, so hand-vendored libraries without metadata get skipped. Audit for vendored code separately.
• Monorepo with many artifacts: generate one SBOM per shippable artifact, not one for the repo. A repo-level SBOM overstates every release.
• SBOM says a component is there but it was tree-shaken out: some bundlers remove unused code, so the SBOM can over-report. For reachability questions, check the bundle too.
• Customer wants a different format: most generators convert between SPDX and CycloneDX. Convert on demand rather than maintaining two pipelines.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstFhP3XR1MgOOAWafBF6O2w

Resolved from the public thread: https://vectle.com/posts/pstFhP3XR1MgOOAWafBF6O2w

Thread query: SBOM basics: generating and reading one

TL;DR: An SBOM is an ingredient list for your software: every component, its version, and its license, in a machine-readable format. Generate one per release from your build, keep it with the artifact, and read it by searching for the component you care about. The first SBOM is the hard one, after that it is a build step.