What's wrong
release.yml contains only checkout/toolchain/cache/test/publish steps — no SBOM/provenance/build-manifest step and no gh-release-asset-upload-style action anywhere in the repo (grep for softprops/action-gh-release, "gh release", upload-release-asset all return empty).
The rsfusa release --dir . step that does produce these safety-evidence artifacts only exists in ci.yml's main-branch "rust-FuSa full lifecycle" job, and its outputs are uploaded only to the fusa-safety-evidence workflow artifact (a CI build artifact, expires per retention policy) — never attached to an actual tagged GitHub Release where a downstream consumer or auditor would expect to find them.
Note: the real v1.0.0 tag's release run (run 30452456416) also failed outright at the "Publish to crates.io" step because CARGO_REGISTRY_TOKEN was unset — that specific failure is already tracked in #12, so this issue is scoped to the separate, still-open gap: release.yml has no mechanism at all to attach SBOM/provenance/build-manifest to a GitHub Release, independent of whether crates.io publishing succeeds.
Why it matters
For a safety-critical (ASIL-B) crate, SBOM and provenance/build-manifest evidence tied to a specific tagged release is exactly the kind of artifact an auditor or downstream integrator needs to be able to fetch alongside that release — not buried in an expiring CI workflow-artifact from an unrelated main-branch job run.
Suggested fix
Add a step to release.yml (or a workflow_run-triggered follow-up) that runs rsfusa release --dir . (or reuses its output) and uploads the resulting SBOM/provenance/build-manifest as assets on the GitHub Release object itself, e.g. via softprops/action-gh-release or gh release upload.
Filed from the RELAY ecosystem audit (2026-07-29), category: relay-spec-conformance, severity: high.
What's wrong
release.ymlcontains only checkout/toolchain/cache/test/publish steps — no SBOM/provenance/build-manifest step and nogh-release-asset-upload-style action anywhere in the repo (grepforsoftprops/action-gh-release,"gh release",upload-release-assetall return empty).The
rsfusa release --dir .step that does produce these safety-evidence artifacts only exists inci.yml's main-branch "rust-FuSa full lifecycle" job, and its outputs are uploaded only to thefusa-safety-evidenceworkflow artifact (a CI build artifact, expires per retention policy) — never attached to an actual tagged GitHub Release where a downstream consumer or auditor would expect to find them.Note: the real v1.0.0 tag's release run (run 30452456416) also failed outright at the "Publish to crates.io" step because
CARGO_REGISTRY_TOKENwas unset — that specific failure is already tracked in #12, so this issue is scoped to the separate, still-open gap: release.yml has no mechanism at all to attach SBOM/provenance/build-manifest to a GitHub Release, independent of whether crates.io publishing succeeds.Why it matters
For a safety-critical (ASIL-B) crate, SBOM and provenance/build-manifest evidence tied to a specific tagged release is exactly the kind of artifact an auditor or downstream integrator needs to be able to fetch alongside that release — not buried in an expiring CI workflow-artifact from an unrelated main-branch job run.
Suggested fix
Add a step to
release.yml(or aworkflow_run-triggered follow-up) that runsrsfusa release --dir .(or reuses its output) and uploads the resulting SBOM/provenance/build-manifest as assets on the GitHub Release object itself, e.g. viasoftprops/action-gh-releaseorgh release upload.Filed from the RELAY ecosystem audit (2026-07-29), category: relay-spec-conformance, severity: high.