GitHub Actions SBOM upload
Upload SBOMs from GitHub Actions. No Git integration required.
Generate CycloneDX files in your CI pipeline, upload them with a project-scoped API key, and let boring.tools turn every build into searchable inventory and vulnerability context.
name: SBOM
on:
push:
branches: [main]
workflow_dispatch:
jobs:
sbom:
runs-on: ubuntu-latest
permissions:
contents: read
steps:
- uses: actions/checkout@v4
- name: Install Syft
uses: anchore/sbom-action/download-syft@v0
- name: Generate CycloneDX SBOM
run: syft dir:. -o cyclonedx-json=sbom.cdx.json
- name: Upload SBOM to boring.tools
uses: boring-tools/upload-sbom-action@v1
with:
api-key: ${{ secrets.BORING_TOOLS_API_KEY }}
project-id: ${{ vars.BORING_TOOLS_PROJECT_ID }}
sbom-file: sbom.cdx.jsonWhy teams use it
Keep repository access in CI while centralizing SBOM visibility.
No Git provider connection required
Works with private repositories and self-hosted build systems
Project-scoped API keys reduce CI secret blast radius
Raw upload path keeps generated SBOM files unchanged
Source metadata links uploads back to commits and workflow runs
CycloneDX JSON today, with the same project inventory model as Git scans
The workflow
Three steps from CI artifact to project inventory.
The action is intentionally small: it does not scan your repository or generate a new SBOM. It moves the SBOM you already trust into boring.tools with the project context needed for monitoring.
Generate a CycloneDX SBOM
Keep your existing generator. Syft, Trivy, cdxgen, CycloneDX CLI, or any custom build step can produce the file.
Upload from GitHub Actions
Use boring-tools/upload-sbom-action@v1 with a project-scoped API key and the project ID stored as repository configuration.
Track inventory and CVEs
boring.tools stores the SBOM, parses components, keeps source metadata, and ties vulnerability monitoring back to the selected project.
Raw API fallback
Not on GitHub Actions? Use the same upload contract.
GitLab CI, Forgejo Actions, Jenkins, Buildkite, or a shell script can upload the same CycloneDX JSON file with one authenticated request.
curl --fail-with-body \
-X POST "https://api.boring.tools/v1/sboms?projectId=$BORING_TOOLS_PROJECT_ID" \
-H "Content-Type: application/json" \
-H "x-api-key: $BORING_TOOLS_API_KEY" \
--data-binary @sbom.cdx.jsonFAQ
Questions before wiring CI?
Does the GitHub Action generate the SBOM?
No. It uploads an existing CycloneDX JSON file. That keeps generation under your control and lets you use Syft, Trivy, cdxgen, CycloneDX CLI, or an internal generator.
Do I need to connect my GitHub organization to boring.tools?
No. CI/CD upload is designed for teams that want to keep repository access inside their own build system. The action only needs an API key and a project ID.
What permissions should the API key have?
Use a project-scoped API key with SBOM upload access whenever possible. If that secret leaks from CI, it can only upload SBOMs to the selected project.
Should I pin the action to @v1 or a full version?
Use @v1 for the stable major version when you want updates. Use @v1.0.0 or a commit SHA when your workflow policy requires immutable references.
Start with one workflow
Turn every GitHub build into SBOM inventory.
Connect your first repository by uploading the SBOM you already generate. boring.tools keeps the project view current without needing repository access.