The sbomify Action generates a Software Bill of Materials as part of your build, from what your build actually resolved. It runs as a GitHub Action, a Docker image, or a Python package, and it is open source on GitHub.
- uses: sbomify/sbomify-action@v26.8.0
env:
COMPONENT_ID: your-component-id
LOCK_FILE: poetry.lockThat is the whole integration. The SBOM is generated, enriched, and published to your trust center.
Native tooling, not a generic scanner
Point the action at a lock file and it uses that ecosystem’s own tooling, because a native resolver knows things a generic scanner has to infer. Maven resolves a Maven project. Cargo resolves a Rust one. The result describes the dependency graph your build produced, not a best guess at it.
| Ecosystem | Lock files |
|---|---|
| Python | requirements.txt, poetry.lock, Pipfile.lock, uv.lock, pyproject.toml |
| JavaScript | package-lock.json, yarn.lock, pnpm-lock.yaml, bun.lock, package.json |
| Java | pom.xml, build.gradle, build.gradle.kts, gradle.lockfile |
| Go | go.mod, go.sum |
| Rust | Cargo.lock |
| Ruby | Gemfile.lock |
| PHP | composer.json, composer.lock |
| .NET | packages.lock.json |
| Swift | Package.swift, Package.resolved |
| Dart | pubspec.lock |
| Elixir | mix.lock |
| Scala | build.sbt |
| C++ | conan.lock |
| Terraform | .terraform.lock.hcl |
Container images and source directories are supported too, so you can describe a built artifact as well as the source it came from. Output is CycloneDX or SPDX, whichever your customers ask for.
Enriched before it leaves your pipeline
A list of names and versions is not much use to the person who receives it. The action fills in licence, supplier and lifecycle metadata from package registries, and adds your own organisational metadata, so what arrives is a document someone can act on.
Dependencies that no lock file mentions can be declared explicitly. Vendored code, system libraries and runtime dependencies get listed alongside everything else rather than quietly going missing.
No long lived tokens in CI
Publishing uses OIDC trusted publishing, so your pipeline authenticates with a short lived token minted for that run. There is no API key to store as a secret, rotate, or leak in a log.
Build provenance is attested with GitHub Artifact Attestations, so the SBOM you publish can be traced back to the workflow run that produced it.
Where the SBOM goes
Publish to your sbomify trust center, send it to Dependency-Track, or write it to a file and handle it yourself. Most teams do the first, so that every release carries its own SBOM and customers can find it without asking.
Beyond GitHub
The same tool runs anywhere. It is a CLI shipped as a container image, and
GitHub Actions is just one way to invoke it. Use the image in GitLab CI,
Bitbucket Pipelines, Jenkins, CircleCI, Azure DevOps or any other container
runner, or run it locally with uvx.
See the runtime guides for setup on each platform, and the Yocto and Raspberry Pi guides for embedded builds.
Get started
The quick start gets you a first SBOM in minutes, and the zero to hero guide walks through the wider workflow end to end.
For everything else, see the full documentation:
- Why SBOM quality matters - scanners versus pipelines, and why generating and signing in CI is what makes an SBOM verifiable
- Configuration reference - every input, environment variable and CLI flag
- Runtimes - setup for your CI platform
- Enrichment and augmentation - how components get their metadata