The OVHcloud CLI attacker replaced both the binaries and the checksums.txt on existing releases, so anyone checking hashes against that file still passed. What caught it was a downstream CI job that had pinned the SHA-256 it expected.

If you publish releases: enable immutable releases (repository or organization setting). Once a release is published, its assets and tag can't be changed or swapped. Publish from CI with a dedicated bot identity rather than from personal accounts, and attach build provenance or attestations so users can verify where a binary came from (for example gh attestation verify). Review who has write or maintain access, since any of those accounts can upload release assets through the API. Enable private vulnerability reporting so users don't have to file security issues in public.

If you consume releases: in CI, pin the exact version and its SHA-256 (or verify the attestation), and fail the build on a mismatch. Don't pipe curl | sh installers that fetch "latest" without a hash check onto build hosts or admin laptops. Prefer package managers or registries that pin hashes, such as a Homebrew cask, the Go module proxy or a lockfile. Alert when an existing release's asset updated_at changes, which you can check through the GitHub Releases API.