Em 20 de outubro de 2026, o GitHub anunciou uma alteração no formato de eventos de auditoria ligados ao Secret Scanning. A partir de 12 de novembro de 2026, determinados registros passarão a apresentar o slug da empresa no campo business, no lugar do nome de exibição, o que pode afetar filtros e integrações.
Equipes de segurança que alimentam SIEMs, painéis e alertas automatizados com logs do GitHub devem testar os parsers antes do prazo, especialmente quando comparam nomes por igualdade.
Em resumo: Eventos selecionados do Secret Scanning mudarão o conteúdo textual de business em 12 de novembro. Integrações que dependem do nome de exibição podem falhar. Revise filtros, normalização e testes de ingestão e prefira identificadores estáveis quando disponíveis.
Qual campo muda e quais eventos foram citados?
O anúncio trata da propriedade business em certas entradas do log de auditoria corporativo. O valor antes refletia o nome exibido pela empresa e passa a refletir seu identificador textual, conhecido como slug. A alteração está relacionada a eventos da família secret_scanning_alert e a registros de exceção de proteção de envio, como secret_scanning_push_protection.bypass.
Um exemplo ilustrativo: uma integração que compara o valor com “Empresa de Exemplo S.A.” pode deixar de reconhecer a entidade quando o evento passar a trazer “empresa-de-exemplo”. A estrutura do evento continua parecida, mas uma única comparação textual pode prejudicar alertas e correlações. O comunicado informa que business_id não sofre essa troca de significado.
Quais sistemas podem parar de reconhecer os logs?
Pipelines que extraem eventos para SIEM, bancos de dados e ferramentas de conformidade são candidatos a impacto. Procure queries com filtros como business equals, rotinas que montam dashboards com o nome corporativo e regras que fazem junção com cadastros internos.
As falhas podem ser silenciosas: a ingestão continua acontecendo, mas determinada regra passa a ignorar eventos. Isso é mais perigoso do que um erro explícito, porque reduz visibilidade de vazamento de credenciais ou de exceções à proteção de push sem gerar aviso na interface.
Como adaptar consultas antes de novembro?
Primeiro, exporte uma amostra de logs atuais e identifique os consumidores do campo. Depois, levante o slug oficial da empresa no GitHub e implemente compatibilidade temporária com o nome antigo e o novo. Quando o sistema permitir, prefira o business_id, que é menos sujeito a variações de grafia.
Atualize testes automatizados com eventos simulando os dois formatos e valide se dashboards, alertas e relatórios continuam registrando ocorrências. Para equipes que usam transformações ETL, documente a data de transição e o campo adotado como chave canônica para reduzir ambiguidades.
Qual é o roteiro de validação para o dia 12?
Até 11 de novembro, faça inventário de consumidores, revise documentação de integração e agende uma verificação. No dia 12 ou assim que os logs comecem a usar a nova representação, confira eventos reais em cada sistema: ingestão, campos extraídos, enriquecimento, deduplicação e disparo de regras.
Em operações críticas, mantenha um alerta de integridade do pipeline para indicar ausência inesperada de eventos. Não desligue a proteção de segredos para contornar uma falha de observabilidade. A correção deve ocorrer no processamento do log, preservando detecção e registros de auditoria.
Dúvidas que estão aparecendo
Todos os logs de auditoria do GitHub mudam?
Não. A nota especifica determinados eventos de Secret Scanning e campos afetados.
O business_id também passará a trazer texto?
Segundo o anúncio, não. A mudança descrita incide sobre a representação de business.
A alteração afeta a detecção de segredos?
O risco direto anunciado está no consumo e na interpretação de logs por integrações, não em uma desativação do mecanismo de detecção.
Quais evidências guardar após a mudança
Documente um evento recebido com o novo valor, a consulta atualizada e o resultado dos testes. Isso facilita auditorias e acelera diagnóstico caso um painel mostre queda artificial nas ocorrências.
Acompanhe o changelog do GitHub até a data de implantação, pois comunicados complementares podem esclarecer detalhes de payload e escopo. Em qualquer integração sensível, valide comportamento real em vez de depender exclusivamente de exemplos antigos de documentação.
Fontes consultadas: changelog do GitHub | documentação do log corporativo.
Imagem destacada: foto ilustrativa de Jakub Zerdzicki / Pexels (página da fotografia).
