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 here | Why |
|---|---|---|
| A project directory | Run Syft against dir:. | Fastest way to get package inventory from source, manifests, and lock files |
| A container image | Scan the image with Syft | Better match for Docker, Kubernetes, and release workflows |
| An existing SBOM file | Go straight to the SBOM Validator | Validation tells you whether the file is structurally useful before you trust it |
| A Maven, npm, Go, Rust, or Python project | Use the language-specific command below | Build-tool-native generators can capture ecosystem details that broad scanners may miss |
What You Will Do
In one short session you will:
- install or run an SBOM generator
- create a CycloneDX or SPDX file
- validate the output
- decide what to do next with the result
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 syftcurl -sSfL https://get.anchore.io/syft | sh -s -- -b /usr/local/binwinget install Anchore.Syftdocker run --rm -v "$(pwd)":/src anchore/syft:latest dir:/src -o cyclonedx-json=/src/sbom.jsonStep 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.jsonIf 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
Usejq 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.jsonIf 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.jsonValidation 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.jsonPython
pip install cyclonedx-bom
cyclonedx-py -r requirements.txt -o sbom.jsonJava with Maven
mvn cyclonedx:makeAggregateBomGo
go install github.com/CycloneDX/cyclonedx-gomod/cmd/cyclonedx-gomod@latest
cyclonedx-gomod mod -json -output sbom.jsonRust
cargo install cargo-cyclonedx
cargo cyclonedx --format json --output sbom.jsonWhat 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 formatmetadata: who or what generated the filecomponents: the actual inventory of software piecespurl: 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.Recommended Path After This Page
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.