Scanners de segurança com IA acham mais problemas. O GitHub agora mostra se os desenvolvedores os corrigem

Existe um jeito fácil de fazer um scanner de segurança com IA parecer um sucesso: contar o que ele encontra. Mais achados por pull request, mais repositórios cobertos, mais vulnerabilidades “pegas”. Nenhum desses números diz se o código ficou mais seguro. Um achado que ninguém corrige é uma notificação, e uma enxurrada delas ensina os desenvolvedores a parar de ler.

A atualização do GitHub de 13 de outubro aproxima a medição do que importa. Administradores de organização e de empresa agora têm métricas de AI Scan em pull requests dentro do security overview: achados gerados e resolvidos, taxa de remediação, quais repositórios geram achados, tendências no período e com que frequência os desenvolvedores aplicam as sugestões de autofix. A página antes chamada “CodeQL pull requests” vira “Code scanning on pull requests”, com abas separadas para CodeQL e AI Scan. A aba do AI Scan mostra o total de achados e quantos vieram com ou sem sugestão de autofix.

O recurso está em preview público, no github.com, incluindo o GitHub Enterprise Cloud, para clientes com GitHub Code Security ou GitHub Advanced Security. O GitHub Enterprise Server não é suportado nesta versão.

Por que separar o AI Scan do CodeQL importa

O CodeQL é um motor de análise baseado em regras; os achados são reproduzíveis e os padrões de falso positivo são bem conhecidos. O AI Scan usa um modelo para procurar problemas num pull request. Misturar os dois num só dashboard borraria exatamente a comparação de que uma empresa precisa: o scanner com IA acrescenta achados que os desenvolvedores tratam, ou ruído que eles descartam? Com abas separadas, o time de segurança consegue fazer essa pergunta repositório por repositório.

É o jeito certo de avaliar qualquer sistema de IA no pipeline de entrega: como um componente próprio, com métricas próprias, a abordagem que defendemos quando escrevemos que a busca precisa ser medida como um sistema à parte.

O que os números podem dizer

Usadas com cuidado, as novas métricas apoiam três decisões:

• Rollout. A taxa de remediação por repositório mostra onde o AI Scan ganha atenção e onde é ignorado. Repositórios com remediação baixa precisam de ajuste ou de uma conversa com o time.
• Confiança no autofix. A frequência com que os desenvolvedores aplicam as correções sugeridas é um sinal direto de se elas são boas o bastante para usar. Uma taxa baixa significa custo de revisão sem benefício.
• Lacunas de cobertura. Repositórios que não geram nenhum achado merecem uma olhada: podem estar limpos, ou o scan pode não estar rodando onde deveria.

O que eles não podem dizer

Uma taxa de remediação mais alta não prova menos risco, por motivos que vale escrever em qualquer relatório que cite esses números:

• Uma correção fecha um achado, não uma vulnerabilidade. Aplicar um autofix resolve o alerta. Se a correção está certa, completa e sem efeitos colaterais é outra pergunta, que exige revisão ou teste, sobretudo para código sugerido por IA.
• Resolvido precisa de definição. O changelog não diz se um achado descartado conta como resolvido. Confira as definições das métricas antes de levar o número para cima.
• A severidade não aparece no número principal. Um problema crítico corrigido vale mais do que cinquenta avisos de estilo corrigidos. Reporte a remediação por severidade, não no agregado.
• O que não foi achado é invisível. O dashboard mede o que o scanner encontrou. Não diz nada sobre o que ele deixou passar, e isso só testes independentes conseguem estimar.

É a mesma armadilha que descrevemos em hora economizada não é valor: uma métrica de atividade apresentada como resultado. Achados corrigidos é melhor do que achados encontrados. Risco reduzido é melhor ainda, e precisa ser medido com algo que não seja o próprio scanner.

O recado prático

Se você usa o AI Scan, aproveite o preview para estabelecer uma linha de base agora: taxa de remediação e aceitação do autofix por repositório, separadas por severidade. Junte a isso uma amostra periódica de autofixes aplicados, revisada por um engenheiro de segurança, para saber se as correções aceitas estão certas. A experiência do Google com agentes na revisão de código mostrou que ferramentas de segurança com IA conquistam espaço quando o que produzem chega aonde os desenvolvedores já decidem. As métricas do GitHub agora permitem verificar se isso está acontecendo.