The tool is a CLI shipped as a container image. Configuration is environment variables, and they are identical on every platform. What changes between runtimes is only how you invoke the container, how you authenticate, and how much the platform tells the action about your build.
If your platform can run a container, it is supported - even if it does not have a page here. Start with any container runner.
Pick your platform
- GitHub Actions - native action, OIDC trusted publishing, build provenance attestation
- GitLab CI - container image, automatic VCS detection, self-managed supported
- Bitbucket Pipelines - container image via a Docker pipe, automatic VCS detection
- Jenkins - declarative and scripted pipelines
- CircleCI - container executor
- Azure DevOps - container job or Docker task
- TeamCity - Docker Wrapper build feature or Kotlin DSL
- Any container runner - Drone, Woodpecker, Buildkite, Concourse, or a plain shell
- Local machine -
uvx,pipxor Docker on your laptop
What differs
| Runtime | Integration | Auth | VCS auto-detect | Wizard | Attestation |
|---|---|---|---|---|---|
| GitHub Actions | Native action | OIDC or token | Yes | Generates workflow | Yes |
| GitLab CI | Container image | Token | Yes | No | No |
| Bitbucket | Container image | Token | Yes | No | No |
| Jenkins | Container image | Token | Manual | No | No |
| CircleCI | Container image | Token | Manual | No | No |
| Azure DevOps | Container image | Token | Manual | No | No |
| Any container runner | Container image | Token | Manual | No | No |
| TeamCity | Container image | Token | Manual | No | No |
| Local machine | uvx or pipx | Token | Manual | Yes | No |
VCS auto-detect means the action reads repository URL, commit SHA and branch from the environment without configuration. Where it says Manual, the platform does not expose that information in a standard enough form, so you set vcs_url, vcs_commit_sha and vcs_ref in sbomify.json instead. It is a few lines, and everything else behaves the same.
OIDC trusted publishing and attestation are GitHub-only today because both depend on GitHub-issued identity tokens. Other runtimes authenticate with an API token, and can sign with cosign rather than GitHub’s provenance tooling. Support will expand as platforms expose equivalent primitives.
The universal pattern
Every non-GitHub runtime is a variation on this:
docker run --rm \
-v "$(pwd):/github/workspace" \
-w /github/workspace \
-e LOCK_FILE=requirements.txt \
-e OUTPUT_FILE=sbom.cdx.json \
-e ENRICH=true \
-e UPLOAD=false \
ghcr.io/sbomify/sbomify-actionMount your repository, set the working directory, pass configuration as environment variables. The image entrypoint is sbomify-action, so no command is needed unless you want a subcommand such as wizard or yocto.
Whatever your platform’s syntax for “run this container with these variables” is, that is your integration.
Where the code lives
| Channel | Location |
|---|---|
| Source and GitHub Action | sbomify/sbomify-action |
| Container image | ghcr.io/sbomify/sbomify-action |
| Python package | sbomify-action |
One repository, one image. There is no per-platform integration to install or keep in sync.