GitHub now logs who dismisses and reopens code quality alerts

Two new events in the GitHub Code Quality audit log show who dismissed or reopened a finding, when, and under which rule. The missing piece to justify, in an audit, why a vulnerability remained in the code.

Editor's note: GitHub's official changelog describes the two new audit log events referring explicitly to findings in the repository's "backlog." This article states that a finding dismissed within a pull request generates the same type of event as one dismissed in the backlog, but this equivalence is not explicitly confirmed in the official documentation consulted. Likewise, the claim that third-party tools integrated via GitHub Actions (such as SonarQube or CodeClimate) do not automatically generate this trail is an inference by the author, not information present in the changelog. Readers should keep this caveat in mind when evaluating these two passages.

Two new events in the GitHub Code Quality audit log show who dismissed or reopened a finding, when, and under which rule. The missing piece to justify, in an audit, why a vulnerability remained in the code.

GitHub announced on October 13, 2026, in the official changelog, two new audit log events for the Code Quality feature: repo.code_quality_findings_dismissed and repo.code_quality_findings_reopened. They record, respectively, when someone dismisses or reopens one or more findings from a repository's backlog.

Until now, dismissing a quality finding (or a security one, depending on the rule) was an action that stayed only in the repository's interface, with no central trail. Anyone who wanted to answer "why was this alert ignored and who made that decision" had to manually dig through the repository's history or rely on the team's memory. Now that question has an automatic answer in the organization's or enterprise's audit log.

What each event records

According to GitHub's changelog, each entry for the two new events includes:

• who made the request (the author of the action);
• when it happened;
• the repository and the rule (rule) associated with the finding;
• the identifiers and count of the findings affected (because a single action can dismiss or reopen several findings at once).

This covers the two places where a Code Quality finding can appear: the repository's default branch backlog and pull requests. A finding that originates in a PR and is dismissed there generates the same type of event as a finding dismissed directly in the backlog.

Where to see this in practice

If the repository already has Code Quality enabled, no extra configuration is needed: the events start appearing automatically. Anyone with access to the organization's or enterprise's audit log can filter by the action names (code_quality_findings_dismissed, code_quality_findings_reopened) to see the activity.

On GitHub Enterprise Cloud, you can pull the same events through the audit log API, which opens the door to integrating this trail into a SIEM, a compliance pipeline, or an automated security posture report. It's the difference between "manually checking the audit log screen every so often" and "having an automatic alert when someone dismisses a high-severity finding without a justification recorded anywhere else."

Availability, however, has a clear limit: the feature is generally available (GA) on GitHub Team and GitHub Enterprise Cloud, including enterprises with data residency, but it is not available on GitHub Enterprise Server. Anyone running a self-hosted instance of GitHub still has no automatic trail, at least for now.

Why this matters to those who build and review code

The product angle seems small ("two more events in the audit log"), but the problem it solves is recurring in any team working under some compliance requirement, be it SOC 2, ISO 27001, PCI-DSS, or simply an internal security policy. The question that comes up in every audit is always similar: why did this vulnerability remain in production if the static analysis tool had already flagged the problem?

Before, the answer depended on manually reconstructing the history: looking at PR comments, asking around the team to see who remembers, hoping the decision had been documented somewhere. Now, the audit log has the objective answer: who dismissed it, when, under which rule, and how many findings.

This changes the workflow of whoever reviews security in three concrete ways:

1. Dismissals stop being invisible. A security engineer can periodically audit every high-severity code_quality_findings_dismissed event without depending on the author having left a comment explaining why.
2. Reopenings also become evidence. If someone reopens a finding that had been dismissed, that also gets recorded, which is useful for showing that the remediation process was active, not abandoned.
3. The per-event count helps measure volume. A single event that dismisses 40 findings at once is a different signal from 40 individual events, and now it's possible to tell the two scenarios apart by looking at the count field.

Where the feature falls short

What the audit log delivers is the who and the when, not the why. The two new events don't carry a mandatory justification field: if the organization wants every dismissal to come with a documented reason, that still needs to be enforced by its own process (a required field in the internal workflow, a branch protection rule, a bot that requires a comment). GitHub is logging the action, not validating the motivation behind it.

It's also worth noting that the feature depends on Code Quality being enabled in the repository. Teams that use another static analysis tool via GitHub Actions, such as SonarQube or CodeClimate integrated through their own workflow, don't automatically get this trail: the native audit trail is specific to GitHub Code Quality, and third-party tools have their own audit trail mechanisms, which vary from product to product.

For those already inside the GitHub ecosystem with Code Quality enabled, the math is simple: the feature arrives with no implementation cost, leverages the audit log infrastructure the organization probably already uses for other actions (merges, permission changes, deploy key creation), and closes a real traceability gap. For those on Enterprise Server or using another static analysis stack, the gain is zero for now, and it's worth watching whether the feature reaches Server in some future release.

Whoever administers the organization and wants to take advantage of this today should, first of all, check who has access to the org's and enterprise's audit log (usually owners), since that's the prerequisite for filtering by the two new action names and starting to cross-reference this information with the rest of the security process.