How do you make security fixes stand out in GitHub release notes?

Label security pull requests consistently, then add a category for that label in a .github/release.yml file. GitHub's generated release notes will group those pull requests under their own heading. Add the advisory link and upgrade guidance by hand, because labels alone do not say how serious a fix is.

What GitHub generates

GitHub's documentation says automatically generated release notes include a list of merged pull requests, a list of contributors to the release, and a link to a full changelog. You can customise them with labels to create custom categories, and exclude certain labels and users from the output. To do that you create a file called .github/release.yml in the repository, listing the labels and authors to exclude and the categories to create.

Setting it up

1. Agree on one label for security changes, for example security. Consistent labelling is the whole trick.
2. Create the configuration file.

changelog:
  exclude:
    labels:
      - ignore-for-release
  categories:
    - title: Security fixes
      labels:
        - security
    - title: Other changes
      labels:
        - "*"

3. Check the current GitHub documentation for the exact options before you rely on this sample.
4. When you draft a release, use the generate notes option and review the result.

What the tool cannot do

Generated notes list pull request titles. They do not tell a reader:

• which versions are affected
• how severe the issue is
• whether there is an advisory or identifier to look up
• what to do if they cannot upgrade immediately

So write a short block by hand above the generated list for any security release.

A template for the hand written block

Keep it consistent with the advisory and the changelog. See changelog security disclosure practices and publish a GitHub security advisory checklist.

Common mistakes

• Titles that reveal too much before users can upgrade. Review pull request titles of security fixes first.
• Inconsistent labels. A fix labelled "bug" will not appear in the security group.
• Mixing security notes into a long list so nobody finds them.
• Skipping the hand written block because the tool produced something.

Keeping labels honest

The category only works if people label correctly, so make labelling part of the pull request checklist and have a maintainer confirm it at merge time. Review the labels again when you draft the release: look at the list of merged pull requests for any dependency bump that fixed an advisory but was labelled as maintenance. Those are easy to miss, and they are often exactly what a cautious user wants to find. If a pull request was security related but must not be described yet, hold the release notes until the advisory is ready, then publish both together.

Quick check

Sources

• Automatically generated release notes, GitHub Docs

Last reviewed: 19 October 2026.