ci: attach SBOM from a least-privilege upload job (LAB-983)

[27Bslash6]

Closes LAB-983 — draft: needs a policy decision before this can merge. See "The wall" below.

What was broken

The sbom job in security.yml had no permissions: block, so it inherited the repository's read-only default token. Every release: published run died at the asset upload with Resource not accessible by integration, and cachekit-core-v0.4.0 shipped with zero release assets.

Adding contents: write to that job would have been the wrong fix. It runs cargo sbom, which compiles and executes third-party build scripts and proc-macros; a release-write token must not share a runner with untrusted code. cachekit-py already rejected exactly this shape.

What this does

• Splits the job across a permissions boundary. sbom generates at permissions: contents: read with persist-credentials: false; the SBOM crosses as a workflow artifact; sbom-upload holds the only contents: write token and runs nothing but first-party actions.
• Drops the archived action. upload-release-asset was archived by GitHub on 2021-03-03. Replaced with actions/github-script — gh is not an option, the cachekit ARC runner has no gh CLI (LAB-899).
• Deletes three redundant steps. The runner image bakes Rust stable and cargo-sbom, and this job compiles nothing, so cargo install / rust-toolchain / actions/cache all went. Generation now takes 19s.
• Fails closed on an empty SBOM. An empty-but-valid CycloneDX document looks like a verified supply chain and isn't. The guard also fails closed on an unparseable file, which the obvious form does not — a failed command substitution leaves count empty, [ "" -lt 1 ] errors rather than compares, and the step exits 0. Unit-tested against 8 malformed inputs.
• Switches to cyclone_dx_json_1_6, matching the format release.yml attests.
• Adds a release_tag dispatch input so the path is testable without cutting a release, and excludes Kani from a backfill dispatch so it does not drag the ARC pool along.

The wall

Live verification found the real blocker behind the permissions bug. Immutable releases are enabled on this repository, and GitHub applies immutability at publish. release: published therefore only ever fires against an already-sealed release:

HttpError: Cannot upload assets to an immutable release.

Run 30359945625 — Generate SBOM green in 19s, Attach SBOM to Release red on that error. Every release in this repo reports immutable: true and none has ever carried an asset. cachekit-rs is the same; cachekit-py and cachekit-ts have immutability off.

So no amount of fixing security.yml can attach an SBOM asset, and v0.4.0 cannot be backfilled — a sealed release refuses assets permanently. This needs a decision, not a retry:

1. Disable immutable releases for this repo (Settings → Code and automation → Releases). This PR then works as-is and v0.4.0 can be backfilled — but it trades a real tamper-resistance guarantee for an unsigned convenience copy of an SBOM that is already attested.
2. Keep immutability, attach assets pre-publish — create the release as a draft, upload, then publish. That lives in release.yml, which LAB-983 puts out of scope. The two jobs here are reusable unchanged.
3. Keep immutability, drop the asset ambition — delete these two jobs. The SBOM is already generated and attested via actions/attest-sbom in release.yml, which is the cryptographically verifiable artifact. ← my recommendation

Pending that call, the workflow now checks immutability before generating and fails with the choice spelled out, rather than burning a generation run and dying in 48KB of octokit output:

Release cachekit-core-v0.4.0 is immutable, so assets cannot be attached after publish. Publishing an SBOM asset requires either disabling immutable releases for this repository, or attaching assets while the release is still a draft.

Review

Expert panel (bug-hunter-supreme, security-specialist, code-craftsman, catchphrase-agent) at high stakes. Three findings applied:

• Concurrency group could destroy an asset. Backfill dispatches shared a group with cancel-in-progress: true; since upload deletes a pre-existing asset before re-uploading, a cancel in that window would leave a release with its SBOM deleted and never replaced — worse than the bug being fixed. release_tag is now part of the key.
• Tag validated too late. cargo sbom would execute third-party build scripts for any ref a dispatch named before anything checked the tag was a real release. Resolution moved ahead of the checkout, while the workspace is still empty. Also resolves the release id there and passes it downstream, closing the window where a repointed tag could put this SBOM on a different release.
• A comment cited a stale claim in release.yml (its persistent-CARGO_HOME rationale predates that job's move to ubuntu-latest). Reworded. release.yml is out of scope so its own stale comment is left alone.

Rejected: extending the backfill exclusion to deep-fuzz. run_deep_fuzz is already an explicit opt-in, and silently ignoring an input the operator ticked is worse than honouring it.

Filed separately: the credential-less job and token-holding jobs share a persistent cargo volume on the ARC pool, so build-script code could poison it for a later privileged job. Pre-existing across the estate and not made worse here, but the job-level permissions: split alone does not isolate a shared filesystem.

Docs

SECURITY.md gains a Software Bill of Materials section documenting the attested SBOM, which is real and verifiable today, plus an explicit statement that releases carry no SBOM asset and why. An earlier revision of this branch promised the asset; the panel flagged it as unverifiable and this run proved it impossible.

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 81ff0dec-525e-4efe-9dfa-085e08279027

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch lab-983-least-privilege-sbom-upload

---

_{Comment @coderabbitai help to get the list of available commands.}