How do I tell if a release fixes a security issue from its notes?

Check whether the release is a pre-release, scan the notes for words like security, CVE and vulnerability, follow every linked pull request and issue, compare the diff range to your version, and confirm with an advisory. Release notes alone often under-describe a fix, so treat them as a lead.

What GitHub release notes contain

GitHub's documentation says a release can include notes, @mentions of contributors and links to binary files. Maintainers can write the notes by hand or click a button to generate them automatically. Generated notes list merged changes, which means a security fix may appear only as a pull request title.

Releases also carry a flag. The maintainer can mark a release as a pre-release, and the latest release label is set by semantic versioning unless the maintainer chooses otherwise. That detail matters when you decide whether to adopt a version, as covered below.

Five steps

1. Check the flag. If it is marked pre-release, it is not the version most projects recommend for production. A security fix may land first in a pre-release and later in a stable one. Read the stable notes before deciding.
2. Scan the text. Search for security, vulnerability, CVE, GHSA, advisory, injection, overflow, bypass, traversal, deserialization and denial of service. A quiet title can hide a loud change.
3. Follow the links. Open each pull request. Read the description and the files changed. Look for tests added that mention a malicious input.
4. Compare ranges. Note the version you run and every release between it and the candidate. A fix may be in a release you skip over.
5. Confirm. Search the advisory database and the project's security page for the same package. An advisory gives you affected and patched versions in a precise form.

What a thin note might hide

Some fixes ship without fanfare. Maintainers sometimes prepare the fix privately and publish the advisory afterwards, so the release note may say little at first. Others write a short line and expect advisories to carry the detail.

This is why release notes are a weak single source. Combine them with advisory feeds. Our guide to where maintainers announce security fixes lists the channels.

What to record

For each upgrade, jot down: version from and to, whether security entries were present, the advisory link if any, and anything you could not confirm. A one line note in the pull request is enough.

If you cannot tell whether a release is security related, say so in the note. "Notes do not mention security, no advisory found as of 19 October" is a fair statement. Claiming "no security fix" is not.

Avoid these shortcuts

• Do not assume a patch version number means a security fix, or that a minor version does not contain one.
• Do not skip intermediate releases without reading them.
• Do not treat an auto-generated list as complete.

Where Safeguard fits

Safeguard's dependency scanning matches your versions to advisories directly, and autonomous remediation can open fix pull requests when you choose to enable it. It is off by default, with every category on Manual. You can try a free scan at gold.safeguard.sh/scan.

Try it yourself

Click through it at your own pace, or open it full screen.

Look at how a finding links to the version that fixes it.

Quick check

Sources

• GitHub Docs: managing releases in a repository

Last reviewed: 19 October 2026.