A release page should give security minded users the artifacts, a checksum list and signature, an SBOM, release notes that call out security changes, and a link to how to verify it all. Each item answers a question a careful user would otherwise have to guess at.
The checklist
| Item | Question it answers |
|---|---|
| Tag name and exact version | What exactly is this release |
| Release notes with a security section | Do I need to upgrade urgently |
| Built artifacts per platform | What do I download |
| Checksum file | Did my download arrive intact |
| Signature or bundle | Who vouches for these files |
| SBOM | What is inside, what does it depend on |
| Link to verification steps | How do I check all this |
| Link to the advisory, if any | Where are the details of the fix |
| Supported versions note | Is the line I am on still maintained |
Notes that help
GitHub can generate notes from merged pull requests: its documentation says they include merged pull requests, contributors and a changelog link, and that you can organise them with labels into categories. Use that as a base. Then add the hand written security block, as described in how to make security fixes stand out in release notes.
Files and checks
Build the files in CI, produce the checksum list, and sign it. See how to publish and verify a SHA256SUMS file. For the SBOM, see publish an SBOM with a GitHub release.
Lock it down after publishing
Releases that can be edited later undermine all of the above. GitHub has a feature called immutable releases, covered in what immutable releases lock and what they do not. Read it to see what it does and does not protect before relying on it.
What not to put on the page
- Exploit detail for a fix users have not had time to apply.
- Claims you cannot support, such as saying a release is secure.
- Unreleased or draft artifacts mixed with final ones.
- Internal paths or build host names that leak in file listings.
A routine to keep it honest
Before publishing, open the draft release and read it as a stranger would. Download one artifact, run the checksum, run the signature check. If a step is unclear, fix the page, not just your memory.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the monitoring view and notice how new findings can appear after a release is published, which is why the page should link to where advisories will appear.
Quick check
Do I need every item for a small project?
No. Checksums, release notes and verification steps are a sound minimum. Add signatures and an SBOM as you can.
Is more detail always better?
No. Complete and accurate beats long. Do not describe security properties you have not checked.
Sources
Last reviewed: 19 October 2026.
