Improve SBOM generation

[vpetersson]

• Update SBOM generation flow
• Moves sbomify work to OIDC instead of token

[sergey-borovkov]

Overview

Replaces .github/workflows/sbom.yml with a wizard-generated .github/workflows/sboms.yml:

• sbomify/github-action@master → sbomify/sbomify-action@<sha> (v26.7.0)
• Auth via GitHub OIDC trusted publishing instead of the long-lived SBOMIFY_TOKEN secret
• All actions pinned to commit SHAs (previously floating @v4, @v1, @master)
• Adds a matrix (one entry), a license/syft cache, workflow_dispatch, PRODUCT_RELEASE, and an explicit version-derivation step

Net direction is a clear improvement. I verified all four SHA pins resolve to the tags in their comments (checkout v6.0.2, cache v5.0.5, attest-build-provenance v4.1.0, sbomify-action v26.7.0) — all correct.

Blocking prerequisite

Trusted publishing must be registered before this merges. Per the action's README, OIDC only works once a binding exists for component UUzAdk8ixV under Component → Settings → Trusted Publishing in the sbomify UI; TOKEN takes precedence and OIDC is only the fallback. Without that binding, the first v* tag push fails at upload. It's a separate workflow from release.yml, so it won't block the actual binary release — but SBOM publishing silently stops working. Worth confirming the binding exists, then deleting the now-unused SBOMIFY_TOKEN repo secret.

Issues

1. SHA pinning doesn't actually pin the executed code (sboms.yml:39)

sbomify/sbomify-action is a Docker action, and at the pinned SHA its action.yml is:

runs: {using: 'docker', image: 'docker://ghcr.io/sbomify/sbomify-action:latest'}

The pin fixes action.yml, not the container that runs with id-token: write. :latest is mutable, so the supply-chain guarantee the SHA pins suggest isn't there for the one third-party action that matters most. Nothing to fix in this PR — upstream would need to pin the image digest — but worth knowing the pin is cosmetic here.

2. Cache key never rotates (sboms.yml:31)

key: sbomify-${{ runner.os }}

GitHub cache entries are immutable: on an exact key hit the cache isn't re-saved at job end. This key has no version/hash/date component and no restore-keys, so the license DB and syft cache are frozen at whatever the first run produced and will never refresh. Suggest a rotating primary key with a prefix fallback:

key: sbomify-${{ runner.os }}-${{ github.run_id }}restore-keys: sbomify-${{ runner.os }}-

3. workflow_dispatch runs create sbomify releases keyed on a short SHA (sboms.yml:53)

On manual dispatch, steps.ver.outputs.v is git rev-parse --short HEAD, which flows into PRODUCT_RELEASE: '["44WZdk8ixV:<shortsha>"]'. Every manual run mints a product release named after a commit hash. If dispatch is meant for testing, gate it:

PRODUCT_RELEASE: ${{ startsWith(github.ref, 'refs/tags/') && format('["44WZdk8ixV:{0}"]', steps.ver.outputs.v) || '' }}

Same reasoning applies to the attestation step — dispatch runs will attest a non-release artifact into the public Rekor log.

Minor

• [0-9]* tag pattern is dead config (sboms.yml:6) — every tag in this repo is v-prefixed (v1.0.2 … v1.2.1), and release.yml triggers on v* only. Harmless, just wizard boilerplate.
• Single-entry matrix — pure overhead for one component, though it does make adding a second component trivial. Fine to leave as generated.
• OVERRIDE_NAME: true → COMPONENT_NAME: CLI and SBOM_VERSION → COMPONENT_VERSION both match the current documented env vars. Good.
• OUTPUT_FILE: cli.cdx.json is relative, the Docker action's workdir is /github/workspace, so the attestation's ${{ github.workspace }}/cli.cdx.json subject path resolves correctly — unchanged from the old workflow.

Not applicable

No Rust code touched, so no test-coverage or runtime-performance implications. permissions remain correctly minimal (contents: read plus the two writes OIDC and attestation require).

[sergey-borovkov]

Approving — the OIDC + SHA-pinning direction is a solid improvement, and the failure mode if anything is off is contained to SBOM upload rather than the release build.

Leaving my detailed comment open for the two follow-ups (cache key rotation, PRODUCT_RELEASE on manual dispatch) and the one question worth confirming before the next tag: that trusted publishing is registered for component UUzAdk8ixV in the sbomify UI. None of it needs to block this.