GitHub passa a registrar quem dispensa e reabre alertas de qualidade de código

Dois novos eventos no audit log do GitHub Code Quality mostram quem dispensou ou reabriu um finding, quando e em qual regra. A peça que faltava para justificar, numa auditoria, por que uma vulnerabilidade continuou no código.

Nota da redação: o changelog oficial do GitHub descreve os dois novos eventos de audit log referindo-se explicitamente a findings do "backlog" do repositório. Este artigo afirma que um finding dispensado dentro de um pull request gera o mesmo tipo de evento que um dispensado no backlog, mas essa equivalência não está confirmada de forma explícita na documentação oficial consultada. Da mesma forma, a afirmação de que ferramentas de terceiros integradas via GitHub Actions (como SonarQube ou CodeClimate) não geram esse rastro automaticamente é uma inferência do autor, não uma informação presente no changelog. Fica o alerta para o leitor avaliar essas duas passagens com essa ressalva em mente.

Dois novos eventos no audit log do GitHub Code Quality mostram quem dispensou ou reabriu um finding, quando e em qual regra. A peça que faltava para justificar, numa auditoria, por que uma vulnerabilidade continuou no código.

O GitHub anunciou em 13 de outubro de 2026, no changelog oficial, dois novos eventos de audit log para o recurso Code Quality: repo.code_quality_findings_dismissed e repo.code_quality_findings_reopened. Eles registram, respectivamente, quando alguém dispensa ou reabre um ou mais findings do backlog de um repositório.

Até agora, dispensar um finding de qualidade (ou de segurança, dependendo da regra) era uma ação que ficava só na interface do repositório, sem rastro central. Quem quisesse responder "por que esse alerta foi ignorado e quem tomou essa decisão" precisava caçar manualmente no histórico do repositório ou confiar na memória do time. Agora essa pergunta tem resposta automática no audit log da organização ou da enterprise.

O que cada evento registra

Segundo o changelog do GitHub, cada entrada dos dois novos eventos inclui:

• quem fez a requisição (o autor da ação);
• quando aconteceu;
• o repositório e a regra (rule) associada ao finding;
• os identificadores e a contagem dos findings afetados (porque uma única ação pode dispensar ou reabrir vários findings de uma vez).

Isso cobre os dois lugares onde um Code Quality finding pode aparecer: o backlog do branch default do repositório e os pull requests. Um finding que nasce num PR e é dispensado ali gera o mesmo tipo de evento de um finding dispensado direto no backlog.

Onde ver isso na prática

Se o repositório já tem o Code Quality habilitado, não é preciso nenhuma configuração extra: os eventos passam a aparecer automaticamente. Quem tem acesso ao audit log da organização ou da enterprise filtra pelos nomes de ação (code_quality_findings_dismissed, code_quality_findings_reopened) para ver a atividade.

No GitHub Enterprise Cloud, dá para puxar os mesmos eventos pela audit log API, o que abre a porta para integrar esse rastro em um SIEM, num pipeline de compliance ou num relatório automatizado de postura de segurança. É a diferença entre "olhar a tela de audit log manualmente de vez em quando" e "ter um alerta automático quando alguém dispensa um finding de severidade alta sem justificativa registrada em outro lugar".

A disponibilidade, porém, tem limite claro: o recurso é geral (GA) em GitHub Team e GitHub Enterprise Cloud, incluindo enterprises com data residency, mas não está disponível no GitHub Enterprise Server. Quem roda instância self-hosted do GitHub continua sem esse rastro automático, pelo menos por enquanto.

Por que isso importa pra quem constrói e revisa código

O ângulo de produto parece pequeno ("mais dois eventos no audit log"), mas o problema que ele resolve é recorrente em qualquer time que trabalha sob alguma exigência de compliance, seja SOC 2, ISO 27001, PCI-DSS ou simplesmente uma política interna de segurança. A pergunta que aparece em toda auditoria é sempre parecida: por que essa vulnerabilidade continuou em produção se a ferramenta de análise estática já tinha sinalizado o problema?

Antes, a resposta dependia de reconstruir manualmente o histórico: olhar comentários no PR, perguntar no time quem lembra, torcer para que a decisão tivesse sido documentada em algum lugar. Agora, o audit log tem a resposta objetiva: quem dispensou, quando, em qual regra e quantos findings.

Isso muda o fluxo de trabalho de quem revisa segurança de três formas concretas:

1. Dismissals deixam de ser invisíveis. Um security engineer pode auditar periodicamente todos os code_quality_findings_dismissed de severidade alta sem depender de o autor ter deixado um comentário explicando o porquê.
2. Reaberturas também viram evidência. Se alguém reabre um finding que havia sido dispensado, isso também fica registrado, o que é útil para mostrar que o processo de correção estava ativo, não abandonado.
3. A contagem por evento ajuda a medir volume. Um único evento que dispensa 40 findings de uma vez é um sinal diferente de 40 eventos individuais, e agora dá para distinguir os dois cenários olhando o campo de contagem.

Onde o recurso esbarra

O que o audit log entrega é o quem e o quando, não o por quê. Os dois novos eventos não carregam um campo de justificativa obrigatória: se a organização quer que todo dismissal venha acompanhado de uma razão documentada, isso ainda precisa ser imposto por um processo próprio (um campo obrigatório no fluxo interno, uma regra de branch protection, um bot que exige comentário). O GitHub está registrando a ação, não validando a motivação por trás dela.

Também vale notar que o recurso depende do Code Quality estar habilitado no repositório. Times que usam outra ferramenta de análise estática via GitHub Actions, como SonarQube ou CodeClimate integrados por workflow próprio, não ganham esse rastro automaticamente: a trilha de auditoria nativa é específica do GitHub Code Quality, e ferramentas de terceiros têm seus próprios mecanismos de audit trail, que variam de produto para produto.

Para quem já está dentro do ecossistema GitHub com Code Quality ativo, a conta é simples: o recurso chega sem custo de implementação, aproveita a infraestrutura de audit log que a organização provavelmente já usa para outras ações (merges, mudanças de permissão, criação de deploy keys) e fecha uma lacuna real de rastreabilidade. Para quem está no Enterprise Server ou usa outra stack de análise estática, o ganho é zero por ora, e vale ficar de olho em se o recurso chega ao Server em alguma release futura.

Quem administra a organização e quer aproveitar isso hoje deve, antes de mais nada, checar quem tem acesso ao audit log da org e da enterprise (geralmente owners), porque é o pré-requisito para filtrar pelos dois novos nomes de ação e começar a cruzar essa informação com o restante do processo de segurança.

Fonte: GitHub Changelog