Trivy holds a clear lead for generating SBOMs directly within CI/CD pipelines, especially for teams already running vulnerability scans. Syft serves as the usual answer when teams prioritize fast rollout and compliance generation from container images.
Best for: Deep application source-code dependency parsing and multi-language support (supporting 20+ languages and deep component reachability analysis).
Targets: Source code, container images, and binary artifacts/VMs.
Formats: Specialized CycloneDX standard (versions 1.4 through 1.7), supporting various BOM variants like CBOM and SaaSBOM.
There are several solid tools for generating Software Bills of Materials (SBOMs) directly in CI/CD pipelines. The best choice depends on whether you need to inventory application dependencies, inspect container images, scan an entire filesystem, or produce compliance-ready SBOMs in formats such as SPDX and CycloneDX.
Best SBOM generation tools for CI/CD
1. Syft
(Best general-purpose choice)
Generates SBOMs from container images, directories, filesystems, and application packages. Supports both SPDX and CycloneDX output and works well in containerized build runners.
Use for: containers, source/build directories, root filesystems.
CI integration: CLI in GitHub Actions, GitLab CI, Jenkins, or Azure Pipelines.
Link:
2. Trivy
A broad scanner for container images, filesystems, repositories, and application dependencies. Can generate SBOMs and also scan for vulnerabilities and misconfigurations.
Use for: teams wanting SBOM generation and security scanning in the same pipeline.
CI integration: CLI, container image, and CI integrations.
Link:
3. Microsoft SBOM Tool
Designed to generate SBOMs for build artifacts and identify software components from source/build directories. Supports SPDX 2.2 and 3.0, with documented GitHub Actions and Azure DevOps integrations.
Use for: release artifacts, enterprise pipelines, SPDX-oriented workflows.
CI integration: CLI or .NET API.
Link:
4. Docker Scout
Focuses on container images, their software composition, and vulnerabilities. A natural fit for teams already building and publishing images through Docker workflows.
Use for: image-centric build and release pipelines.
CI integration: Docker tooling and supported CI workflows.
Link:
5. CycloneDX tooling
An ecosystem of libraries, generators, and build plugins for creating standardized SBOMs from application dependencies. Particularly useful when you want to generate SBOMs as part of the native build process.
Use for: language-specific dependency manifests and standardized SBOM output.
CI integration: build plugins and language-specific CLI tools.
Link:
6. cdxgen
A useful option for generating CycloneDX SBOMs from applications across many programming languages and package ecosystems.
Use for: application dependency inventories and language-rich repositories.
CI integration: CLI and automation scripts.
Link:
7. OWASP Dependency-Track
This is primarily an SBOM consumption and continuous monitoring platform, rather than a general-purpose generator. It complements pipeline generators by tracking component risk, vulnerabilities, and policy violations after SBOM upload.
Use for: centralized SBOM management and ongoing risk monitoring.
CI integration: upload generated SBOMs through its API.
Link:
Quick comparison
Tool
Applications
Container images
Filesystems
Main strength
Syft
Yes
Yes
Yes
Flexible, standalone generation
Trivy
Yes
Yes
Syft's documentation explicitly covers image, directory, file, and archive scanning, as well as SPDX and CycloneDX output.
Example: Generate SBOMs in a CI/CD pipeline
For a general-purpose pipeline, Syft is a good starting point because it can scan both the application directory and the final container image.
Enterprise-wide SBOM tracking: generate with one of the tools above and feed the results into Dependency-Track.
One important distinction: an SBOM generated from source dependencies may differ from one generated from the final container image. For the most useful release inventory, consider producing both, then storing the SBOM alongside the exact version or digest of the artifact it describes.
Which CI/CD platform are you using — GitHub Actions, GitLab CI, Jenkins, Azure DevOps, or something else? I can give you a ready-to-use pipeline configuration for it.
(Aqua Security) : An all-in-one open-source security scanner that handles container images, filesystems, Git repositories, and virtual machine images. Beyond finding misconfigurations and secrets, it natively exports complete SBOMs in CycloneDX or SPDX formats via a single command or dedicated CI/CD action. [](]()](]()]()
If you'd like to narrow this down, let me know:
Which CI/CD platform you use (e.g., GitHub Actions, GitLab CI, Jenkins)
Your primary target languages or packaging formats
Whether you also need vulnerability scanning attached to the SBOM generation
I can provide a ready-to-use pipeline configuration snippet for your stack.
For automating Software Bills of Materials (SBOMs) across application source code, container images, and filesystems, I’d start with Syft, Trivy, and cdxgen. All three can run as command-line tools in CI/CD jobs, generate machine-readable inventories, and fit into existing build pipelines. The best choice depends on whether you prioritize broad artifact coverage, security scanning, or application dependency analysis.
Microsoft SBOM ToolMicrosoft SBOM Tool : An enterprise-grade, highly scalable tool optimized for build-time generation. It natively supports formats like SPDX and integrates efficiently into enterprise pipelines to catalog source code and compiled application artifacts (NuGet, npm, pip, Go, Cargo).[](https://www.wiz.io/academy/application-security/top-open-source-sbom-tools)
(Best general-purpose starting point)
Generates SBOMs from container images, local directories, and archives. Supports CycloneDX and SPDX formats and is easy to add to build jobs.
CI/CD: GitHub Actions, GitLab CI, Jenkins, and other runners via CLI or scripts.
Docs:
2. Trivy
(Best for SBOM + security scanning)
Generates SBOMs from container images, filesystems, and root filesystems. Supports both SPDX and CycloneDX and can combine inventory generation with vulnerability scanning.
CI/CD: Particularly useful when you want SBOM generation and security gates in the same pipeline.
Docs:
3. cdxgen
Best for application and build dependency analysis
Supports many languages and package managers, source trees, container images, and binary artifacts. It can also submit generated SBOMs to Dependency-Track.
CI/CD: Strong fit for multi-language repositories and CycloneDX-centric workflows.
Docs:
4. Microsoft SBOM Tool
Best for build-output and SPDX workflows
Generates SPDX SBOMs from build directories and integrates into software build processes. Worth evaluating if your organization standardizes on SPDX and Microsoft-oriented tooling.
These commands and supported use cases are documented by the respective projects.
3. Example: automate SBOM generation in GitHub Actions
For a simple starting point, Anchore provides an official GitHub Action that uses Syft to generate an SBOM and upload it as a workflow artifact. It can also target a container image.
yaml
name: Generate SBOM
on:
push:
branches: [main]
release:
types: [published]
permissions:
contents: read
jobs:
sbom:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Generate source SBOM
uses: anchore/sbom-action@v0
with:
path: .
format: cyclonedx-json
artifact-name: source-sbom.cdx.json
# Optional: add a second SBOM step for a
# built container image using its image reference.
For other CI/CD platforms, run Syft or Trivy in a normal pipeline script, then archive the generated files as build artifacts. GitLab also documents workflows for generating and publishing SBOMs to its package registry.
4. A practical production architecture
Source commit and build
Compile, resolve dependencies, build image
Application
Syft / cdxgen
Image / filesystem
Syft / Trivy
Validate and publish SBOMs
CycloneDX or SPDX · versioned artifacts · build provenance
Generate after the build: produce an SBOM for the exact artifact or immutable container digest you will release, not just the source repository.
Keep separate SBOMs per deliverable: applications, platform variants, and container images may have different dependencies.
Standardize the format: use CycloneDX or SPDX according to your downstream consumers.
Automate validation and retention: fail builds when required SBOMs are missing or invalid, and retain them alongside release artifacts.
Add signing and provenance: where supported, attest that the SBOM corresponds to the artifact being shipped.
5. Which setup should you choose?
My default recommendation is Syft for broad SBOM generation plus Trivy for vulnerability scanning, with cdxgen added if your application dependency analysis needs more language-specific coverage.
To tailor this into a working pipeline, which CI/CD platform are you using?
![[Infographie] Dependency Track](https://images.openai.com/static-rsc-4/Ifnhy_S6CzA2bsLoDadiTTJM1qfblvlarr4ixoEeXBzgFgpNli9eDAP1mt6Ysu5Yuz7ZF9PwNVlT_TnEBWSkEz9LEsrWg2VKUJHlBLFaecP2fbUmAzPjmk5fWzIzkGIbSC-Kd6afyp_FjUEtUYicKVL6HV1I73YT_BRB2S5P-9E61kHhVAaOVb9UU0ei2hH6?purpose=fullsize)
