← Todos os insights

Análise de notíciaRecorte: Brasil4 min de leitura

A IA do GitHub encontra, corrige e retesta vulnerabilidades. Ainda não pode bloquear nem aprovar um merge

AI Scan e Agentic Autofix chegaram à disponibilidade geral em 15 de outubro. Um orienta, o outro abre pull requests em rascunho. Os limites são design: o pull request é a fronteira de controle.

Ouça este artigo · 5 min

Narração completa do artigo, gerada por IA.

Uma porta de madeira fechada sob um arco de pedra entalhado, no duotone La Madre, ao lado das palavras O pull request decide
Foto: Tony Grist (Wikimedia Commons, CC0)

Em 15 de outubro, o GitHub levou dois recursos de segurança com IA à disponibilidade geral no mesmo dia, e ambos chegam com um limite deliberado. O AI Scan encontra vulnerabilidades em pull requests, e seus achados não podem bloquear um merge. O Agentic Autofix investiga e corrige alertas, e só consegue abrir um pull request em rascunho. Os limites são a parte mais útil do lançamento, porque mostram onde o GitHub considera que termina o julgamento da IA e começa a imposição de regras.

Dois recursos, duas funções

AI Scan usa um modelo para procurar vulnerabilidades em mudanças de pull request, voltado a códigos que o CodeQL não cobre hoje: PHP, Shell e Bash, Terraform HCL, Dockerfiles, JSP e Blazor, entre outros. Os achados aparecem ao lado dos resultados do CodeQL, marcados com um indicador “IA”, e podem incluir uma explicação e uma correção sugerida. Ele roda automaticamente quando o code scanning e a configuração de AI Scan do repositório estão habilitados. Repositórios públicos têm acesso; repositórios privados e internos precisam de GitHub Code Security ou Advanced Security. Não é necessária licença do Copilot. Ele não roda em pull requests de forks nem do Dependabot.

Agentic Autofix trabalha em alertas que já existem. Atribua um alerta de code scanning no branch default ao Copilot, ou selecione até 25 alertas para corrigir em um único pull request, ou defina o responsável pela REST API. O Copilot explora os arquivos relevantes, propõe uma correção, roda o CodeQL de novo para confirmar que o alerta fecha, itera se for preciso e abre um pull request em rascunho com um resumo e os passos de validação que seguiu. Ele está disponível para clientes de Code Security e Advanced Security no GitHub Enterprise Cloud, incluindo residência de dados, depois que um administrador enterprise habilita a política e passa a existir um método de cobrança do Copilot. Alertas encontrados apenas em outros branches ou em pull requests não podem ser atribuídos.

Quem pode fazer o quê no momento do merge
Muda o código?Pode bloquear um merge?Verificado por
CodeQLNãoSim, por rulesetsRegras determinísticas
AI ScanSugere uma correçãoNão, apenas consultivoUma pessoa lendo o achado
Agentic AutofixSim, em um pull request em rascunhoNão, ele é o autorCodeQL roda de novo, depois revisão humana
O motor baseado em regras mantém a autoridade de bloquear. Os recursos de IA adicionam cobertura e trabalho, não autoridade.

Por que um achado de IA não deve bloquear um merge

Um gate de merge precisa ser previsível. Os desenvolvedores precisam saber por que uma verificação falhou, reproduzir e corrigir; os times de segurança precisam saber que o gate se comporta do mesmo jeito amanhã. Os achados de um modelo são probabilísticos, e mudam junto com o modelo. Deixá-los bloquear merges faria a entrega depender de uma variância que ninguém consegue auditar. A escolha do GitHub de manter o AI Scan como consultivo é a correta, e os times devem resistir à tentação de reconstruir um gate de bloqueio sobre ele com automação customizada.

Isso faz do AI Scan uma entrada de triagem. Seu valor se mede por os desenvolvedores agirem ou não sobre seus achados, e é por isso que as métricas de AI Scan do GitHub, anunciadas dois dias antes, importam mais agora que o recurso está em disponibilidade geral (GA): taxa de remediação e aceitação de autofix por repositório, divididas por severidade, são como você decide onde ele merece atenção.

Por que uma nova execução aprovada não é uma aprovação

A etapa de validação do Autofix é progresso de verdade: o agente confere a própria correção contra a mesma consulta do CodeQL que levantou o alerta. Mas ela prova uma coisa só, que este alerta não dispara mais. Não prova que a mudança preserva o comportamento, que não introduz outra fraqueza, nem que segue o jeito como o time responsável teria corrigido. Um lote de 25 alertas em um único pull request torna essa revisão mais difícil, não mais fácil.

Então o pull request em rascunho é a fronteira de controle, e quem revisa está fazendo um code review de uma mudança escrita por um agente. Trate como qualquer mudança de um novo contribuidor: os testes precisam passar, um owner que conhece o código aprova, e o autor e o aprovador são identidades diferentes. É o framework de gestão de mudanças que aplicamos a agentes autores, e aqui ele já vem embutido.

Orçar o trabalho dos dois lados

Os dois recursos consomem Code Security AI Credits, e o Autofix também consome minutos do GitHub Actions. O GitHub permite que empresas definam orçamentos por SKU para esses créditos; defina-os antes de habilitar a política, não depois da primeira fatura.

O custo menos visível é o tempo de quem revisa. Se o Autofix transforma um backlog de 2.000 alertas em 80 pull requests, alguém precisa revisar 80 pull requests. Um rollout sensato começa com uma classe de alerta que tem um padrão de correção bem entendido, mede com que frequência as correções em rascunho dão merge sem retrabalho e expande por classe a partir dali. A experiência do Google com agentes de segurança em code review aponta no mesmo sentido: essas ferramentas conquistam seu lugar dentro do workflow onde as pessoas já decidem, e esse lugar segue sendo o pull request.

Tem um caso de uso de IA parado entre o protótipo e a produção?

Conte o que você quer colocar no ar. Respondemos com próximos passos honestos.

Converse sobre um caso de uso