Skip to content

ci(release): add advisory scanning, SBOM, and signed release artifacts - #48

Merged
rrrodzilla merged 1 commit into
mainfrom
worktree-supply-chain-controls
Aug 30, 2026
Merged

rrrodzilla merged 1 commit into
mainfrom
worktree-supply-chain-controls

Conversation

@rrrodzilla

Copy link
Copy Markdown
Contributor

Closes #43.

What

  • cargo deny check (deny.toml) gates every push, every PR (ci.yml
    job advisories), and every tagged release (release.yml job
    supply-chain, before build). A crate landing on RUSTSEC with no
    matching deny.toml entry fails both.
  • Seven advisories already inherited through acton-ai's exact pin (via
    libsql) are recorded in deny.toml with reasons, tracked in Bump acton-ai past 0.35.0 to clear inherited RUSTSEC advisories #47.
  • Every release archive gets an sbom/ directory: one CycloneDX 1.5 SBOM
    per binary it ships, generated per target with cargo-cyclonedx.
  • The publish job signs SHA256SUMS keylessly with cosign
    (id-token: write, no stored key), and ships SHA256SUMS.sig /
    SHA256SUMS.pem with the release. The verification command is in the
    release notes and packaging/README.md.
  • docs/supply-chain-policy.md is the written policy: the pin rationale,
    the dependency-review process, what the scan enforces vs. currently
    ignores and why, and how a new advisory gets triaged.

Verification

  • cargo deny --locked check passes clean locally (advisories, bans,
    licenses, sources all ok).
  • Confirmed the negative case: removing an ignore entry from deny.toml
    makes cargo deny check advisories fail (exit 1) — the mechanism behind
    the "known-vulnerable crate fails CI" acceptance criterion.
  • Both workflow files parse as valid YAML; no Rust source touched, so no
    clippy/test delta.
  • CI on this PR will exercise the new advisories job for real.

`cargo deny check` now gates every push, every pull request (ci.yml), and
every tagged release (release.yml, before build) against deny.toml's
advisory, license, and source policy. Seven RUSTSEC advisories already
inherited through acton-ai's exact pin (via libsql) are recorded there with
reasons and tracked in #47; anything else fails the check.

Each release archive now carries a sbom/ directory with a CycloneDX 1.5 SBOM
per binary it ships, generated per target so cross-platform-only
dependencies don't leak into a platform that never builds them.

The publish job signs SHA256SUMS keylessly with cosign, against the
workflow's own GitHub Actions OIDC identity rather than a stored key. The
verification command is in the release notes and in packaging/README.md.

docs/supply-chain-policy.md is the written policy #43 asked for: the
acton-ai pin rationale, the dependency-review process, what the advisory
scan enforces and what it currently ignores and why, and how a new advisory
gets triaged.

Closes #43
@rrrodzilla
rrrodzilla merged commit 207d545 into main Aug 30, 2026
3 checks passed
@rrrodzilla
rrrodzilla deleted the worktree-supply-chain-controls branch August 30, 2026 19:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Release engineering: dependency-advisory scanning, SBOM, signed artifacts, written supply-chain policy

1 participant