Release assets are signed, or listed by hash in a signed manifest
A signed tag covers the commit, not the files attached to the release, and those files are uploaded by whatever held the token. A downloader who cannot verify an asset cannot tell a legitimate release from one replaced after the fact, and reads the tag signature as though it covered both.
Observable check
each built asset on the newest release either carries a detached signature or appears with its cryptographic hash in a manifest that is itself signed, and the verifying key or attestation identity is discoverable from the repository rather than only from the release itself. A forge attestation covering the exact asset satisfies this. A release carrying only the source archives the forge generates falls outside this rule rather than failing it.
Where this comes from
- https://baseline.openssf.org/versions/2026-02-19
- https://docs.github.com/en/actions/concepts/security/artifact-attestations
Last read against these sources on 2026-07-28.
OSPS-BR-06.01, Maturity 2-3: 'When an official release is created, that release MUST be signed or accounted for in a signed manifest including each asset's cryptographic hashes.' That sentence is where this rule's two accepted forms come from. Distinct from R-SEC-05, which verifies the tag object with git tag -v and covers the commit, not the files attached to the release. GitHub artifact attestations are the keyless path.