Step-by-step guide to generate your first software bill of materials with practical Syft, CycloneDX, SPDX, and validation workflows.

Updated:

Quick Start Guide: Generate Your First SBOM in 10 Minutes

This guide is the fastest path from zero to a usable SBOM. The goal is simple: generate one CycloneDX or SPDX file, validate it, and understand what to do next. We start with Syft because it works across languages and build systems, then show quick alternatives for common ecosystems.

Choose Your Path

Start with the path that matches what you have in front of you. The best first SBOM is the one that describes the artifact you actually need to review or share.

If you have...Start hereWhy
A project directoryRun Syft against dir:.Fastest way to get package inventory from source, manifests, and lock files
A container imageScan the image with SyftBetter match for Docker, Kubernetes, and release workflows
An existing SBOM fileGo straight to the SBOM ValidatorValidation tells you whether the file is structurally useful before you trust it
A Maven, npm, Go, Rust, or Python projectUse the language-specific command belowBuild-tool-native generators can capture ecosystem details that broad scanners may miss

What You Will Do

In one short session you will:

  1. install or run an SBOM generator
  2. create a CycloneDX or SPDX file
  3. validate the output
  4. decide what to do next with the result
If you are new to the topic, read What Is an SBOM? first. If you already have a file and just want to check it, go straight to the SBOM Validator.

Option 1: Universal SBOM Generation with Syft

Syft is the easiest default for a first SBOM because it can analyze directories, container images, and many common package ecosystems without much setup.

Step 1: Install Syft

Use the installation method that matches your environment.

macOS (Homebrew)
brew install syft
Linux/macOS (install script)
curl -sSfL https://get.anchore.io/syft | sh -s -- -b /usr/local/bin
Windows (PowerShell)
winget install Anchore.Syft
Docker
docker run --rm -v "$(pwd)":/src anchore/syft:latest dir:/src -o cyclonedx-json=/src/sbom.json

Step 2: Generate Your First SBOM

From your project root, run one of these commands:

# CycloneDX JSON
syft dir:. -o cyclonedx-json=sbom.json

# SPDX JSON
syft dir:. -o spdx-json=sbom-spdx.json

If you only want one output format at the start, use CycloneDX. It is usually the easiest format for a first security-oriented workflow.

Step 3: Inspect the Output

Use jq to confirm the file contains real component data.
# Pretty print the SBOM
jq '.' sbom.json

# Count components
jq '.components | length' sbom.json

# Show package names and versions
jq '.components[] | {name: .name, version: .version}' sbom.json

If your file contains package names, versions, and metadata, you already have a workable first SBOM.

Step 4: Validate the SBOM

Do this before you share or automate anything.

Fastest option

Use the SBOM Validator to validate CycloneDX or SPDX output directly in the browser.

CLI examples

# Validate CycloneDX with the CycloneDX CLI
cyclonedx validate --input-file sbom.json

# Validate SPDX with tools-python
pyspdxtools -i sbom-spdx.json

Validation catches format errors, missing required fields, and common structural issues before the SBOM enters a downstream workflow.

Option 2: Language-Specific Generators

If you want tighter integration with a package manager or build system, use a language-specific tool.

JavaScript and Node.js

npm install --global @cyclonedx/cyclonedx-npm
cyclonedx-npm --output-format JSON --output-file sbom.json
For a deeper workflow, see JavaScript SBOM Generation.

Python

pip install cyclonedx-bom
cyclonedx-py -r requirements.txt -o sbom.json
For Poetry, virtualenv, and Conda workflows, see Python SBOM Generation.

Java with Maven

mvn cyclonedx:makeAggregateBom
For build-system-specific guidance, see Java SBOM Generation.

Go

go install github.com/CycloneDX/cyclonedx-gomod/cmd/cyclonedx-gomod@latest
cyclonedx-gomod mod -json -output sbom.json
See Go SBOM Generation for module-specific details.

Rust

cargo install cargo-cyclonedx
cargo cyclonedx --format json --output sbom.json
See Rust SBOM Generation for a full walkthrough.

What a Basic SBOM Looks Like

A minimal CycloneDX JSON file usually includes:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.7",
  "version": 1,
  "metadata": {
    "timestamp": "2026-03-09T12:00:00Z",
    "component": {
      "type": "application",
      "name": "my-app",
      "version": "1.0.0"
    }
  },
  "components": [
    {
      "type": "library",
      "name": "express",
      "version": "4.18.2",
      "purl": "pkg:npm/express@4.18.2"
    }
  ]
}

The important fields for beginners are:

  • bomFormat: the SBOM format
  • metadata: who or what generated the file
  • components: the actual inventory of software pieces
  • purl: the package identifier used by many downstream tools

What to Do Next

1. Run vulnerability analysis

If your goal is security, scan the generated SBOM with a tool such as Grype or another vulnerability platform that accepts SBOM input.

2. Add SBOM generation to CI/CD

Your first manual SBOM is only a starting point. The real value comes when every release produces one automatically.

See CI/CD SBOM Integration.

3. Compare tooling options

If Syft is not the right fit, use the SBOM Tools Comparison page to compare open source and enterprise options.

4. Learn the format tradeoffs

If you are unsure when to use CycloneDX versus SPDX, read SBOM Formats.

Common Problems

Before assuming the generator failed, check the artifact you scanned. Many first SBOM problems come from scanning the wrong directory, scanning source when you meant to scan a container image, or validating an old file from a previous build.

No packages found

You may be running the generator from the wrong directory or scanning a project without installed dependencies. For source scans, run the command from the project root where the manifest or lock file lives. For release checks, scan the built image or artifact instead.

Missing transitive dependencies

Some tools see more than others depending on build context. If the output looks thin, compare a filesystem scan with a build-tool-native generator.

Validation errors

These usually come from missing required fields, malformed JSON, invalid PURLs, or unsupported schema versions. Use the SBOM Validator to narrow down the issue.
  1. What Is an SBOM?
  2. SBOM Formats
  3. SBOM Validator
  4. SBOM Tools Comparison
  5. SBOM Vulnerability Management

Bottom Line

Do not overcomplicate your first SBOM.

Generate one file, validate it, confirm the component inventory looks reasonable, and then automate the workflow. That alone puts you ahead of most teams that are still treating SBOMs as a future project.

Share this article