How to generate an SBOM: a step-by-step guide for engineering teams

How to generate an SBOM: a step-by-step guide

Learning how to generate an SBOM takes an afternoon; making SBOM generation a reliable, per-release habit is the part that pays off. This guide walks through the full workflow—from choosing what to scan to wiring SBOM output into vulnerability triage—so a single engineer can stand up the pipeline this sprint.

This guide covers:

Choosing scan targets (source, container images, or binaries)
Picking a generation tool that fits your stack
Generating SPDX and CycloneDX output in one pass
Automating generation in CI/CD so SBOMs never go stale
Storage, versioning, and quality checks buyers actually test

Building the pipeline

GIF via GIPHY

Related guides:

Key takeaways

Scan the artifact you ship, not just the source repo—container image scans catch OS packages source scans miss.
Syft, Trivy, and cdxgen cover most stacks and are free to adopt today.
CI integration is the whole game: a manually generated SBOM is stale by the next merge.
Store SBOMs versioned with release artifacts so historical questions ("what was in v2.3?") are answerable.
SecureSlate turns your generation pipeline into evidence for SOC 2, ISO 27001, and buyer questionnaires.

Before you start

Decide three things up front:

Owner — typically a platform or security engineer owns the pipeline; GRC owns external requests.
Formats — generate both SPDX and CycloneDX JSON unless a customer dictates one.
Scope — start with your primary customer-facing product, then expand.

Step 1: Choose what to scan

Scan target	What it captures	Best when
Source repository / lockfiles	Declared dependencies with exact resolved versions	You want SBOMs early in the pipeline
Container image	OS packages + application dependencies actually shipped	You deploy containers (most accurate for SaaS)
Built binary / artifact	What is genuinely inside the deliverable	You distribute installers or firmware

For containerized SaaS, scanning the final container image is typically the highest-fidelity option because it includes base-image OS packages that lockfile scans never see.

Step 2: Pick a generation tool

Common open source starting points:

Syft — fast, broad ecosystem support, emits SPDX and CycloneDX; pairs with Grype for scanning
Trivy — SBOM generation plus vulnerability scanning in one binary; strong container support
cdxgen — CycloneDX-native with wide language coverage, including SaaSBOM
Ecosystem-native plugins — Maven, Gradle, npm, and Go all have SBOM plugins that capture build-time truth

See our full SBOM tools comparison for commercial options and selection criteria.

Step 3: Generate your first SBOM

With Syft against a container image:

# CycloneDX JSON
syft registry:your-org/your-app:v2.3.0 -o cyclonedx-json > sbom-v2.3.0.cdx.json

# SPDX JSON from the same scan target
syft registry:your-org/your-app:v2.3.0 -o spdx-json > sbom-v2.3.0.spdx.json

Open the output and sanity-check it: component count should be in the hundreds for a typical web app, versions should be exact (not ranges), and most components should carry a PURL identifier.

Step 4: Automate in CI/CD

Add generation to your release pipeline so every tagged build produces SBOMs automatically:

# GitHub Actions example
- name: Generate SBOM
  uses: anchore/sbom-action@v0
  with:
    image: ghcr.io/your-org/your-app:${{ github.ref_name }}
    format: cyclonedx-json
    output-file: sbom.cdx.json

- name: Attach SBOM to release
  uses: softprops/action-gh-release@v2
  with:
    files: sbom.cdx.json

The equivalent works in GitLab CI, CircleCI, or Jenkins—the principle is the same: SBOM generation runs on every release tag, with zero human steps.

Step 5: Store and version SBOMs

Attach SBOMs to the release artifact (GitHub/GitLab release assets, artifact registry, or OCI attestations)
Keep retention aligned with contracts—buyers may ask about versions shipped a year ago
Consider signing SBOMs (Sigstore/cosign) if you distribute software externally; signed SBOMs are increasingly requested in federal and defense contexts

Step 6: Connect to vulnerability triage

An SBOM nobody queries is shelf-ware. Feed SBOMs into a scanner (Grype, Trivy, or a dependency analysis platform) so that when a new CVE drops, you match it against what you actually ship, not what you think you ship. This is the workflow that turns "are we affected by the new OpenSSL CVE?" from a fire drill into a query. Pair it with your vulnerability management policy SLAs.

How to check SBOM quality

Before sharing externally, verify:

Check	Target
Machine-readable format	SPDX or CycloneDX JSON validates against schema
Unique identifiers	>90% of components carry PURLs
Exact versions	No version ranges or "unknown" entries
Transitive depth	Full resolved tree, not top-level only
NTIA data fields	Supplier, author, timestamp all present
Freshness	SBOM matches the currently shipped release

SBOM generation as compliance evidence with SecureSlate

SecureSlate maps your SBOM pipeline to SOC 2 change management and vulnerability management criteria, ISO 27001 Annex A controls, and buyer questionnaire answers—so the pipeline you built this sprint keeps paying off every audit cycle.

Get started for free · Free readiness score

FAQ: Generating SBOMs

How long does it take to set up SBOM generation?

For a containerized app with standard CI, many teams have automated generation running in under a day. Multi-artifact products with legacy build systems take longer.

Should I scan source code or the container image?

Prefer the shipped artifact (container image or binary). Add a source-level scan earlier in the pipeline if you want faster feedback on new dependencies.

Do I need a commercial tool?

Not to start. Open source tools produce compliant SBOMs. Commercial platforms add management, sharing portals, and vulnerability correlation at scale—see best SBOM tools.

How do I handle monorepos or many microservices?

Generate one SBOM per deployable artifact. A product-level "roll-up" SBOM can aggregate them for buyer requests.

What about dependencies we vendored or copied in?

File-level scanners (Syft with cataloger options, or SCA tools with snippet matching) can detect vendored code, but declare known gaps in the SBOM's "known unknowns" rather than pretending coverage is complete.

Disclaimer (legal note)

SecureSlate is not a law firm, and this article does not constitute legal advice or create an attorney-client relationship. Security and compliance obligations vary by industry, contract, and jurisdiction—consult qualified counsel as needed.