GitHub Security Advisories: Bridging the Gap with Modern Software Project Tools

When Security Merges Clash with Your Workflow

GitHub's security advisory workflow is a critical software project tool for managing vulnerabilities privately. However, a recent community discussion highlighted a significant friction point: the merge behavior of security advisories often bypasses repository settings and standard release automation practices. This can lead to unexpected merge commits, generic commit messages, and a disruption in how teams track changes and measure project progress.

The Problem: Bypassed Settings and Generic Commits

The core issue, as raised by BigLep in the GitHub Community, is twofold:

1. Ignored Merge Strategy: Even when a repository is configured to disallow merge commits (e.g., `allow_merge_commit: false`) and only permits squash or rebase merges, the security advisory UI's "Merge pull request(s)" button will always create a merge commit. This forces maintainers to use workarounds, like temporarily bypassing rulesets, to land critical fixes.
2. Fixed Commit Messages: The resulting merge commit message is a generic string like `"Merge pull request #N from owner/repo-ghsa-...:branch"`. This fixed format strips away valuable context, such as conventional commit messages (`feat:`, `fix:`, `docs:`) from the underlying commits in the private fork.

Furthermore, this merge flow also bypasses branch protection rulesets, requiring additional permissions to complete the merge.

Why This Matters for Software Project Tools and Release Automation

Modern development teams increasingly rely on a clean, linear Git history for various aspects of software project measurement and automation. Tools like `release-please`, `semantic-release`, and similar automation pipelines often parse commit messages using `git log --first-parent` to automatically generate CHANGELOGs, determine version bumps, and trigger releases. When a security advisory merge introduces a generic merge commit as the first parent, these tools lose visibility into the actual changes.

BigLep's experience with `filecoin-project/filecoin-pin` perfectly illustrates this: a `docs:` change merged via the advisory flow was silently omitted from their `release-please` generated CHANGELOG, only discovered post-publish. This not only impacts release accuracy but also adds manual overhead, hindering developer productivity.

Proposed Solutions and Workarounds

The community discussion put forth two clear asks for GitHub:

1. Honor Repository Merge Settings: The advisory merge flow should respect `allow_merge_commit`, `allow_squash_merge`, and `allow_rebase_merge` settings, behaving consistently with the normal PR merge UI.
2. Allow Commit Message Customization: Provide an option to customize the merge commit message, or at least automatically include the conventional commit messages from the source PR, making them visible to `git log --first-parent` tools.

In the interim, teams are employing several workarounds:

• Opening a normal public PR for the fix before publishing the advisory.
• Adding a follow-up empty conventional commit on the default branch to re-surface the change for release tooling.
• For `release-please` users, manually injecting CHANGELOG entries using a `BEGIN_COMMIT_OVERRIDE` block in a follow-up PR body.

The example merge commit that triggered this discussion was:

8db22b4

This discussion highlights a crucial area where the specialized security workflow needs to better integrate with the broader ecosystem of software project tools and established development practices to maintain a seamless and predictable release process.