feat(release): add CycloneDX SBOMs and npm provenance attestations#66
Open
kingchenc wants to merge 1 commit into
Open
feat(release): add CycloneDX SBOMs and npm provenance attestations#66kingchenc wants to merge 1 commit into
kingchenc wants to merge 1 commit into
Conversation
Two modern supply-chain-trust additions to the release pipeline, neither of which changes what gets published — only adds verifiable signals attached to existing releases. 1. **CycloneDX SBOMs.** `cargo-cyclonedx` is installed in the cargo-publish job after the .crate files are built, and runs once per published crate (`wickra-core`, `wickra-data`, `wickra`). The resulting `*.cdx.json` files are uploaded as the `sboms` artifact, then attached to the GitHub Release alongside the existing wheels, tarballs, .node binaries and .crate files. Future security advisories can answer "is my version of crate X transitive in wickra Y.Z?" by reading the SBOM directly instead of resolving the lockfile. 2. **npm `--provenance` flag** on every npm publish call: - main `wickra` package (node-publish, first + retry) - per-platform `wickra-<triple>` subpackages (node-publish loop) - `wickra-wasm` (wasm-publish) Provenance attestations are generated server-side by npm from the GitHub Actions OIDC token. The publishing jobs gain `permissions: id-token: write` so the runner can exchange that token. The npm page for each published version will then carry the "Verified provenance" badge, which proves the tarball was built by *this* workflow run and not by an arbitrary local laptop with the NPM_TOKEN. Skipped deliberately (to keep this PR focused, possibly follow-ups): - Sigstore cosign signing of artefacts (different audit story; can be layered on after npm-provenance lands). - SLSA build-provenance attestations via `actions/attest-build-provenance` (would target every artefact uniformly; the npm-provenance flag is the more pragmatic first cut). YAML structure validated (8 jobs intact). No production code touched. This PR conflicts with PR #59 only in line-by-line URL substitutions on release.yml — rebase after #59 should be clean.
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Two modern supply-chain-trust additions to the release pipeline. Neither changes what gets published — they only add verifiable signals attached to existing releases.
1. CycloneDX SBOMs per crate
`cargo-cyclonedx` runs in the `cargo-publish` job after the `.crate` files are built, generating one `*.cdx.json` per published crate (wickra-core, wickra-data, wickra). The files are uploaded as the `sboms` artifact and attached to the GitHub Release alongside the existing wheels / tarballs / `.node` binaries / `.crate` files.
Why: future security advisories can answer is crate X transitively in wickra Y.Z? by reading the SBOM directly, without re-resolving Cargo.lock or rebuilding the workspace. Future-proof for EU Cyber Resilience Act 2027 SBOM requirements.
2. npm `--provenance` on every npm publish call
Added to:
Publishing jobs gain `permissions: id-token: write` so the runner can exchange the GitHub Actions OIDC token for the npm registry. The npm page for each published version will carry the Verified provenance badge, proving the tarball was built by this workflow run and not by an arbitrary local laptop with the NPM_TOKEN.
Skipped deliberately (potential follow-ups)
Merge order
This PR touches the same file (`release.yml`) as PR #59 (org-email migration). #59 modifies specific URL strings in lines ~390 of the workflow; this PR adds new steps in completely different sections. Rebase order: merge #59 first, then rebase + merge this PR. The 3-way merge should be clean — no textual overlap.
Verification
CI expectation
29 standard checks. `release.yml` itself runs only on `v*` tags so it does not execute on this PR.