Open the changelog, look for a Security heading in the versions newer than yours, then read Deprecated and Removed sections and any yanked entries. Match each security note to your version and to the advisory, if one exists. That tells you what upgrading buys and what it may break.
The headings to expect
The Keep a Changelog convention, version 1.1.0, groups changes under standard headings: Added, Changed, Deprecated, Removed, Fixed and Security. Its guidance says Security is "in case of vulnerabilities". Projects that follow the convention give you one predictable place to look.
It also covers yanked releases. The convention describes them as versions pulled because of a serious bug or security issue, notes that often they do not even appear in changelogs, and says they should. A yanked entry is displayed with the word YANKED next to the version.
If a project does not follow the convention, use a text search for words such as security, vulnerability, CVE, advisory, GHSA and fix.
A five step read
- Find your current version in the changelog.
- Read everything above it, newest first.
- Collect every Security entry and any yanked versions you passed.
- Look at Deprecated and Removed entries, which are what may break on upgrade.
- For each security entry, follow any advisory or issue link and check the affected range.
Write the results as a short list: version, fix, link, risk to you.
Why the Security heading is not enough
A project may not use the heading. A security fix can sit under Fixed with a vague line such as "improve input handling". Some fixes appear only in an advisory, with the changelog silent. The reverse also happens: a changelog entry mentions security with no advisory.
So treat the changelog as one input. Cross check it with advisory sources and with your scanner. Our post on reading release notes for security fixes covers the case of projects that publish only GitHub release notes.
Yanked versions you already run
If you find a yanked version in your lockfile, treat it as a finding. The convention says yanked releases had to be pulled for a serious reason, so read why. Whether tools stop installing it depends on the registry, and existing pinned installs may keep working. See our write up on PyPI yanked releases and pinned installs.
A small team habit
Add one line to your upgrade pull request template: "Changelog reviewed for Security, Deprecated, Removed and yanked entries, with links." It takes a minute and leaves a record for reviewers.
For maintainers reading this, the other side of the coin is in our guide to marking a yanked release in your changelog.
Where Safeguard fits
Safeguard's dependency scanning checks the versions you run against advisories, so the changelog read is a second look, not your only line of defence. Try a free scan at gold.safeguard.sh/scan.
Quick check
Is a changelog a reliable source of security fixes?
Only partly. Some fixes are listed under other headings or not at all, so cross check with advisories.
What does YANKED next to a version mean?
Under the Keep a Changelog convention, the version was pulled because of a serious bug or security issue.
Sources
Last reviewed: 19 October 2026.
