sbom-tools-action

Composite action that installs Trivy and the CycloneDX CLI with caching, ready for SBOM generation workflows.

Why

The previous setup pinned TRIVY_VERSION and CYCLONEDX_CLI_VERSION in every consuming workflow. When the upstream trivy/contrib/install.sh started failing for older release-asset layouts, every repo needed a PR to bump. This action centralises the install logic and reads versions as inputs (typically wired to the gitea instance variables vars.TRIVY_VERSION / vars.CYCLONEDX_CLI_VERSION).

Usage

- uses: https://git.janhouse.lv/janhouse/sbom-tools-action@v1
  with:
    trivy-version: ${{ vars.TRIVY_VERSION }}
    cyclonedx-version: ${{ vars.CYCLONEDX_CLI_VERSION }}

After this step, trivy and cyclonedx-cli are on PATH. Cache is keyed on the runner OS + both versions, so a bump invalidates and reinstalls automatically.

Inputs

Name	Description	Required
trivy-version	Trivy release tag, e.g. v0.70.0.	yes
cyclonedx-version	CycloneDX CLI release tag, e.g. v0.27.1.	yes

Both inputs are required so the consumer is explicit about source. Wire them to gitea instance vars to avoid hardcoding.

Versioning

The repo follows lightweight tags: v1, v1.0.0, etc. Consumers pin to @v1 for in-major updates, or @<sha> for full pinning.

scan — SBOM, osv-scanner and the triage report (v2)

uses: https://git.janhouse.lv/janhouse/sbom-tools-action/scan@v2 uploads the repo's source SBOM to Dependency-Track, runs osv-scanner over the repo, and reports to dtrack-panel which images the repo builds and its osv-scanner.toml [[IgnoredVulns]]. The panel's auto-triage then marks those NOT_AFFECTED in Dependency-Track — for the CI project and for the app's own dependency tree in the running images — and closes CI-project findings for dependencies that never reach the image (dev/build-time). Inputs and an example are in scan/action.yml. Authenticates with the same DEPENDENCY_TRACK_API_KEY the upload uses; no extra secret.