sbomify logo

How to Generate an SBOM: Tools and Guides (2026)

Complete SBOM generation guide: how to generate an SBOM from a lockfile, container image or build system, which SBOM generation tools to use for each ecosystem, and how to automate it in CI/CD. Covers Syft, cdxgen, native ecosystem tools and sbomify-action, in CycloneDX and SPDX.

On this page

Step-by-step guides for generating SBOMs across every major programming language and platform. New to SBOMs? Start with What is an SBOM? for the basics, or jump straight to your ecosystem below.

Generating a Software Bill of Materials is the first step in the SBOM lifecycle. It is also the step that determines the quality of everything downstream: a vulnerability scan, a compliance attestation, and a customer-facing Trust Center are all only as good as the SBOM they are built from.

Just want a working pipeline? The setup wizard scans your repository, finds your lockfiles, and writes a ready-to-commit CI workflow.

Run the Setup Wizard

How to Generate an SBOM

Every SBOM generation workflow comes down to four decisions.

1. Choose your source: lockfile, image, or build system

This is the decision that matters most, and the easiest one to get wrong.

  • From a lockfile (recommended) – uv.lock, poetry.lock, package-lock.json, pnpm-lock.yaml, Cargo.lock, go.sum, gradle.lockfile, Gemfile.lock. A good lockfile already pins an exact version for every transitive dependency, and in most ecosystems a cryptographic hash too, which is precisely what an SBOM needs. In CycloneDX terminology this is a pre-build or source SBOM. Not every ecosystem has one — Maven has no traditional lockfile, since versions in pom.xml can be ranges or inherited from parent POMs, which the Java guide covers.
  • From an installed environment – reading what the package manager actually installed. Useful when there is no usable lockfile, but the output inherits whatever the environment happens to contain.
  • From a container image – scans the image filesystem. Essential for containerised delivery, with an important caveat covered in the Docker guide: image scanning sees packages installed by a package manager, and can miss binaries copied in during a multi-stage build.
  • From a build system – embedded build systems emit their own manifests. See the Yocto guide.

The general rule: the SBOM is only as good as the lockfile. A requirements.txt with version ranges and no hashes cannot produce an accurate source SBOM, because the exact version is genuinely unknown until install time. If your SBOM quality is disappointing, fix the lockfile before blaming the tool.

2. Choose a generation tool

There is no single best SBOM tool — the right one depends on your ecosystem.

ToolBest forNotes
Native ecosystem toolsA single languagecyclonedx-py, cyclonedx-maven-plugin and similar read their own lockfile format directly. Which tool fits which ecosystem is covered per-language in the guides below.
SyftBreadth, container imagesHandles many ecosystems and image formats from one binary.
cdxgenBreadth, monoreposWide language coverage, CycloneDX-native.
sbomify-actionCI/CD, and not choosingBundles the above, selects the right generator for your ecosystem, then enriches and publishes the result in one step.

A note on tool safety: we no longer consider Trivy safe following two successful supply chain attacks in March 2026, and have removed it from sbomify-action. SBOM tooling sits inside your build pipeline with access to your source and often your registry credentials — it deserves the same scrutiny as any other dependency.

3. Choose a format: CycloneDX or SPDX

Both are mature, both are accepted by every major compliance framework, and you do not need to pick a side permanently — see converting between CycloneDX and SPDX and which formats sbomify supports. If you have no existing constraint, either is a safe default; the guides below use CycloneDX output in their examples.

4. Automate it in CI

An SBOM generated by hand is out of date the moment the next commit lands. Generate one on every build, from the same lockfile that produced the artefact, and attach it to the release. The CI/CD integration guide covers why this belongs in the pipeline rather than in a quarterly checklist, and runtimes covers GitHub Actions, GitLab CI, Bitbucket, Jenkins, CircleCI, Travis CI, Azure DevOps and TeamCity.

Generation is also the right moment to sign the SBOM, while you still have build-time provenance to sign with.

Language Guides

Platform Guides

General Guides

The sbomify Action

The sbomify action generates an SBOM from any of the lock files above, enriches it, and publishes it - in one step, on any CI platform. It covers 17 ecosystems plus Docker images, directory scans and Yocto builds, and outputs both CycloneDX and SPDX.

After Generation

A generated SBOM is an input, not a deliverable. What usually follows:

  • Enrichment - filling in licence, supplier and metadata the lockfile does not carry. See enrichment and augmentation.
  • Vulnerability monitoring - continuously, as new CVEs are published against components you already shipped.
  • Compliance - mapping the SBOM to whichever framework applies to you. The SBOM compliance guide covers the CISA minimum elements, the EU Cyber Resilience Act, BSI TR-03183-2, NIS2, FDA and PCI DSS.
  • Distribution - sharing with customers and auditors without emailing JSON around. See share and collaborate.

Worked examples of complete SBOMs are in SBOM examples, and Zero to Hero walks the whole path end to end.

Additional Resources

Looking for more tools and resources? Check out our SBOM Resources page for:

  • SBOM generation tools (generic and language-specific)
  • Assembly and enrichment tools
  • Distribution and transportation solutions
  • Analysis and vulnerability scanning tools
  • Official SBOM documentation from CISA and NTIA