GitHub has introduced two new audit‑log actions—repo.code_quality_findings_dismissed and repo.code_quality_findings_reopened—that capture when a user manually dismisses or reopens one or more Code Quality findings. The events include the actor, timestamp, repository, rule, and the identifiers and count of the affected findings, and are available in organization and enterprise audit logs as well as via the Enterprise Cloud audit‑log API.
New Audit Events
Both events are emitted for findings that reside in a repository’s default‑branch backlog or appear in pull‑request reviews. The payload records who performed the action, when it occurred, the repository name, the specific rule that generated the finding, and a list of finding IDs together with a total count. No additional configuration is required for repositories that already have Code Quality enabled.
Operational Impact
- Teams can now filter audit logs by the new action names to surface all dismissals and reopenings, enabling post‑mortem analysis of code‑quality enforcement.
- Automation that consumes the audit‑log API can ingest these events to drive dashboards, alerting pipelines, or compliance reports.
- Because the events are part of the standard organization/enterprise audit stream, existing log‑aggregation and SIEM integrations will capture them without changes.
- The feature is generally available on GitHub Team and GitHub Enterprise Cloud, including data‑residency deployments, but is not present on GitHub Enterprise Server.
Security and Governance Considerations
- Visibility into manual dismissals helps detect potential attempts to hide low‑severity findings that could later be escalated.
- Reopening events signal that previously accepted findings have been reconsidered, which may trigger re‑validation of affected code paths.
- Auditing who performed the action supports accountability and can be tied to role‑based access reviews.
- Organizations that rely on Code Quality for security‑related rules should ensure that audit‑log access is granted to the appropriate compliance or security teams.
Related CloudNinjas coverage: DevOps.
What This Means For Practitioners
Review your audit‑log access policies and add filters for repo.code_quality_findings_dismissed and repo.code_quality_findings_reopened. Consider integrating these events into existing monitoring or compliance dashboards to surface unexpected dismissals. If you operate on GitHub Enterprise Server, plan for an alternative tracking method, as the events are not available there. Finally, align your incident‑response playbooks to include review of these audit entries when investigating code‑quality regressions.
