ci: attach dependency SBOM to release assets

[christophercampbell]

Releases now publish an SPDX dependency SBOM as a release asset, generated from the repository's Dependency Graph and uploaded alongside the binaries.

The artifact supports outbound license review and vulnerability triage: it carries package name, version, and license fields for the full source dependency tree.

[osr21]

Shipping an SPDX SBOM with the release assets is a great addition, and the mechanics here are solid: the step is pinned to the same github-script SHA already used elsewhere in the workflow, the release job's contents: write covers the export call, and because the file lands in release-assets/ before the upload step, both the fresh-release and draft-replace (--clobber) paths pick it up.

Two things worth considering before merge, though:

1. The Dependency Graph export describes the default branch now, not the tag being released

GET /repos/{owner}/{repo}/dependency-graph/sbom has no ref parameter — it snapshots the repository's current dependency graph, which tracks the latest push to the default branch. This workflow deliberately builds from refs/tags/${{ inputs.tag }} and can be dispatched for older tags, so the SBOM can disagree with the binaries it ships next to whenever main has moved past the tag (dependency bumps, removals). For the stated use case — vulnerability triage against a specific released binary — that mismatch is the one thing an SBOM must not have.

The filename compounds it slightly: under workflow_dispatch, context.sha is the tip of the branch the run was dispatched from, not the tag's commit, so arc-node_v0.6.0_<sha>.spdx.json can embed a SHA that isn't the released code either.

Since the build job already checks out the exact tag and builds --locked, the tag's Cargo.lock is right there and authoritative. Generating from source — e.g. cargo sbom/cargo cyclonedx in the build job, or a pinned anchore/sbom-action run against the checkout — makes the SBOM match the artifacts by construction, and as a bonus removes a live API dependency from the release path (a transient Dependency Graph failure, or a fork with the graph disabled, currently fails the whole release for a nice-to-have asset; if you keep the API approach, continue-on-error: true on this step would be a cheap mitigation).

2. The SBOM misses the GPG signing pass

The sign job produces detached .asc signatures for release-assets/*.tar.gz, but the SBOM is generated one job later, so it ships unsigned — consumers doing license/vuln review can't authenticate the one asset that's specifically meant for compliance evidence, and there's no checksums file to cover it either. If generation moves into the build or sign job (which #1 suggests anyway), extending the signing loop's glob to include the .spdx.json is a one-line change.

Happy to sketch the cargo-based variant if useful — it slots into the existing Package release assets step fairly naturally.