GitHub Agentic Autofix já está disponível: transforme um alerta de segurança em uma correção revisada

Um alerta de segurança avisa que algo precisa de atenção. Mas não necessariamente explica como mudar o aplicativo sem quebrá-lo. Para quem está começando a manter um aplicativo pequeno, essa lacuna pode impedir uma correção antes mesmo de ela começar; para um desenvolvedor, pode deixar uma fila crescente de avisos conhecidos.

Em 15 de outubro de 2026, o GitHub anunciou a disponibilidade geral do Agentic Autofix para alertas de varredura de código. Atribua um alerta ao Copilot e um agente investigará o código, proporá alterações, tentará validá-las e abrirá um pull request em rascunho. A mudança útil está no ponto de partida: uma correção proposta que você pode inspecionar, em vez de um editor vazio. Anúncio de disponibilidade geral do GitHub, 15 de outubro de 2026

Este guia leva você de um repositório elegível à primeira correção revisada e, depois, mostra como lidar com alertas relacionados, scanners personalizados, custos e tentativas malsucedidas. Nossa recomendação: trate o agente como autor de um patch, não como aprovador de uma versão. Você ainda precisa entender a alteração antes que ela passe a fazer parte do seu aplicativo.

O diagrama de abertura separa a correção proposta pelo agente da decisão humana de fazer o merge.

Comece com um alerta, não com toda a fila

Seu primeiro sucesso deve ser uma mudança pequena que você consiga explicar, testar e revisar. Um pull request propõe combinar alterações no código principal do projeto; o status de rascunho indica que a proposta ainda não está pronta. CodeQL é o mecanismo de análise de código do GitHub, que gera alertas sobre código potencialmente vulnerável.

Siga esta sequência antes de tentar uma grande limpeza:

1. Escolha um repositório que você administra. Confirme a elegibilidade abaixo, a aprovação de acesso e quem responde pela cobrança antes de iniciar uma sessão do agente.
2. Confirme primeiro a análise do CodeQL. Se o repositório já tiver uma análise funcional, mantenha essa configuração e confira a execução bem-sucedida mais recente. Para uma nova configuração, em Settings > Advanced Security > Code Security, encontre CodeQL analysis, escolha Set up > Default, revise a configuração e selecione Enable CodeQL. Aguarde a análise ser concluída com sucesso. Instruções de configuração do GitHub, consultadas em 18 de outubro de 2026
3. Habilite o Agentic Autofix por meio das políticas aplicáveis. Uma opção no repositório não pode contornar uma proibição da organização ou da empresa.
4. Escolha um alerta existente na branch padrão. Abra Security and quality > Code scanning, abra o alerta e selecione Assign to Copilot em Assignees. Procedimento para alertas do GitHub, consultado em 18 de outubro de 2026
5. Inspecione o pull request em rascunho e o registro da sessão. Leia o diff, execute os testes pertinentes e faça uma nova varredura com a configuração que identificou o problema.
6. Só faça o merge depois da revisão humana e das verificações exigidas. Em seguida, confira o estado do alerta após a análise da branch padrão atualizada.

Para conhecer a interface, veja a demonstração oficial da interface no anúncio de disponibilidade geral do GitHub. Use essa referência junto com seu repositório, sem presumir que um diagrama ilustrativo reproduza todas as telas atuais.

Seu repositório público ou privado pode usar o recurso?

O anúncio do lançamento enfatiza clientes empresariais. A documentação atual de acesso do GitHub é mais abrangente: inclui repositórios públicos no GitHub.com e repositórios pertencentes a organizações com GitHub Code Security ou GitHub Advanced Security. Não é necessária uma licença do Copilot. Documentação de acesso do GitHub, consultada em 18 de outubro de 2026

O acesso público não significa que as sessões do agente sejam gratuitas. Separe a elegibilidade do repositório das cobranças de uso antes de convidar colaboradores para testar o recurso.

Habilite o acesso começando pela política de nível mais alto aplicável

Para uma organização pertencente a uma empresa, um proprietário da empresa ou gerente de segurança deve primeiro permitir o recurso em Policies > Advanced Security > Agentic Autofix. Essa permissão, por si só, não o habilita. Em seguida, um proprietário da organização ou gerente de segurança o habilita em Settings > Advanced Security > Global settings; os repositórios elegíveis herdam a habilitação. Administradores de repositório podem optar por sair ou reativá-lo somente quando as políticas superiores permitirem. Organizações independentes não precisam da etapa empresarial; repositórios públicos pessoais elegíveis usam diretamente a configuração do próprio repositório. Quem usava a prévia precisa habilitá-lo novamente. Procedimento de política do GitHub, consultado em 18 de outubro de 2026

Diagrama de acesso: permissão, habilitação e escolha do repositório são decisões separadas. Fonte: documentação de acesso do GitHub, consultada em 18 de outubro de 2026.

Antes de implementar o recurso em toda a organização, identifique os repositórios que devem continuar desativados e defina quem revisará os patches gerados. Um piloto sensato combina um responsável pelo repositório com um revisor de segurança. Registre o alerta, o comportamento esperado, o revisor e a pessoa responsável pelo orçamento para que um rascunho sem acompanhamento não vire uma responsabilidade inexplicada de outra pessoa.

Confirme que o CodeQL realmente analisou o código

A configuração padrão requer GitHub Actions e visibilidade pública ou Code Security. Revise as linguagens e o conjunto de consultas selecionados, não apenas a opção habilitada. Se uma configuração avançada existente estiver funcionando, não troque por impulso: a configuração padrão substitui as configurações existentes, desativa o fluxo de trabalho atual e bloqueia uploads pela API de análise CodeQL. Documentação de configuração padrão do GitHub, consultada em 18 de outubro de 2026

Confira o resultado da análise mais recente antes de selecionar um alerta. Pergunte se o serviço afetado foi incluído e se a compilação ou as dependências causaram uma falha de análise. Uma configuração marcada como habilitada não prova que os arquivos relevantes foram analisados com sucesso. Corrija o problema de configuração antes de pedir a um agente para reparar descobertas de uma referência pouco confiável.

Na primeira tentativa, escolha um problema localizado e com comportamento esperado claro, como uma consulta ao banco de dados ou um caminho específico de renderização de saída. Evite começar com uma reformulação abrangente da autorização. Se não houver um alerta pertinente, não introduza deliberadamente uma vulnerabilidade em um repositório ativo para criar uma demonstração.

O que acontece entre a atribuição e o pull request em rascunho?

O GitHub descreve um agente que explora arquivos relevantes, gera uma correção, executa novamente o CodeQL e itera antes de abrir um pull request em rascunho. A proposta inclui um resumo da correção e detalhes de validação. Esse é o fluxo do Agentic Autofix, não um merge automático na branch padrão. Fluxo de trabalho do anúncio de disponibilidade geral do GitHub, 15 de outubro de 2026

Depois de atribuir o alerta, siga esta sequência de revisão:

1. Leia novamente a descoberta original. Identifique a entrada não confiável, a operação sensível e a proteção esperada. Anote o identificador do alerta e a configuração que o relatou.
2. Leia todos os arquivos alterados. Procure mudanças sem relação com a correção, verificações removidas, testes desativados, novas dependências e alterações no comportamento de erros.
3. Inspecione as evidências da sessão. Diferencie uma varredura concluída de um comando que falhou ou de uma mensagem dizendo que a validação não estava disponível. Você pode solicitar outra iteração pela sessão ou mencionar o Copilot em um comentário no pull request. Orientações de sessão do GitHub, consultadas em 18 de outubro de 2026
4. Execute os testes do aplicativo e o scanner pertinente. Use os comandos de teste documentados pelo projeto em um ambiente de desenvolvimento apropriado. Inspecione scripts de configuração e mudanças no fluxo de trabalho antes de executar código desconhecido.
5. Solicite aprovação humana. Mantenha o rascunho bloqueado enquanto houver dúvidas sobre comportamento, cobertura da varredura ou responsabilidade. Marque-o como pronto somente quando as evidências puderem ser revisadas.

Ciclo de revisão: um rascunho produzido pelo agente é um artefato intermediário, não prova de que o aplicativo é seguro. Fontes: anúncio e documentação de resolução de alertas do GitHub.

Os pull requests do GitHub mostram o diff em Files changed e os resultados automatizados em Checks. Use ambos: um resumo verde não explica se uma verificação de permissão alterada ainda aplica as regras do seu aplicativo. Conceitos de pull request do GitHub, consultados em 18 de outubro de 2026

Fluxo 1: corrija uma consulta simples sem mudar seu significado

Considere um serviço Python fictício que encontra um item de estoque pelo rótulo. A implementação existente insere o rótulo fornecido no SQL usando formatação de string, e um alerta de varredura de código identifica a construção da consulta. Uma correção útil separa a instrução SQL do valor, em vez de tentar remover caracteres de pontuação um por um.

Uma implementação ilustrativa mais segura com a interface sqlite3 do Python é:

def find_item(connection, label):
    return connection.execute(
        "SELECT id, label FROM inventory WHERE label = ?",
        (label,),
    ).fetchone()

O placeholder vincula o valor separadamente do texto SQL, seguindo as orientações oficiais de vinculação de parâmetros do Python, consultadas em 18 de outubro de 2026. Este é um padrão de correção fictício, não um resultado do Agentic Autofix nem um teste relatado. A consulta, o esquema e as regras de autorização exatos de um serviço real precisam de revisão própria.

Neste exemplo, peça testes que cubram um rótulo comum, um rótulo com apóstrofo, como Maker's Kit, e um item inexistente. Confira se a função preserva o comportamento esperado de retornar uma linha ou None. Depois, teste as regras de acesso existentes do endpoint que a chama; uma consulta parametrizada não determina quem tem permissão para ler o estoque.

Um comentário de revisão útil seria: “Mantenha o comportamento da consulta, vincule o rótulo como dado e acrescente cobertura de regressão para apóstrofos e itens inexistentes.” Ele descreve o contrato, em vez de apenas mandar o agente fazer o aviso desaparecer. Execute novamente a varredura sobre o patch real antes de aceitá-lo.

Fluxo 2: agrupe alertas relacionados, não avisos arbitrários

Suponha que um serviço web fictício tenha três alertas associados ao mesmo helper de renderização de respostas. Analise-os juntos para decidir se uma única correção compartilhada é apropriada. O GitHub permite selecionar até 25 alertas pendentes da lista ou de uma campanha de segurança; uma atribuição cria uma sessão e um pull request. Instruções de atribuição em massa do GitHub, consultadas em 18 de outubro de 2026

Esse limite é um teto de capacidade, não um tamanho de lote recomendado. Três descobertas relacionadas e com um responsável podem ser mais fáceis de revisar do que vinte descobertas sem relação, que abrangem autenticação, tratamento de arquivos e acesso ao banco de dados. Antes de atribuir, liste cada endpoint afetado e o comportamento normal que precisa ser preservado.

Neste fluxo ilustrativo, revise o helper compartilhado e teste todos os pontos de chamada. Se a correção proposta alterar o escape da saída, verifique os contextos de saída pretendidos, em vez de aprová-la porque um exemplo passou a parecer correto. Divida o trabalho quando descobertas diferentes exigirem revisores ou cronogramas de lançamento distintos. Não deixe um alerta sem resolução obscurecer quais correções realmente têm evidências.

Fluxo 3: um scanner personalizado requer confirmação própria

O Agentic Autofix atende somente alertas pendentes na branch padrão. Alertas que aparecem apenas em um pull request ou em outra branch não fazem parte desse fluxo de atribuição. Se um novo pull request introduzir uma descoberta, corrija-a ali em vez de fazer merge de código vulnerável apenas para que ela possa ser atribuída. Declaração de escopo do GitHub, 15 de outubro de 2026

Há outro limite: o GitHub informa que a validação do agente não pode confirmar correções de consultas CodeQL personalizadas, do conjunto de consultas CodeQL security-extended ou de alertas de scanners de código de terceiros. A validação integrada executa novamente o conjunto de consultas da varredura de código como melhor esforço. Limites de validação do GitHub, consultados em 18 de outubro de 2026

Imagine uma organização fictícia com uma consulta personalizada que aplica uma regra interna de tratamento de dados. Mesmo que um agente proponha um patch plausível, o revisor precisa executar essa análise personalizada e inspecionar o resultado. Registre a versão da consulta, a configuração, a revisão analisada e o resultado. Uma execução bem-sucedida do conjunto padrão não substitui a consulta que identificou o problema.

Mantenha o scanner mais rigoroso habilitado. Reduzir a cobertura para obter um status verde muda a medição, não a segurança do aplicativo. Se não conseguir reproduzir a análise necessária, deixe a proposta aguardando validação e identifique quem pode executá-la.

Não precisar de licença do Copilot não significa não pagar

O Agentic Autofix consome créditos de IA do Code Security e minutos do GitHub Actions. A documentação de cobrança do GitHub afirma explicitamente que créditos de IA são consumidos até em repositórios públicos que não exigem licenças de colaboradores ativos. Créditos de IA incluídos, quando a conta faturada tem um benefício aplicável, são usados primeiro; o uso adicional é cobrado por consumo, e contas sem créditos incluídos têm cobrança por consumo desde o início. Cobrança de créditos de IA do GitHub, consultada em 18 de outubro de 2026

Em repositórios de uma organização, as cobranças pertencem à conta pagadora da organização ou da empresa. Confira o saldo e o orçamento de créditos de IA do Code Security dessa conta antes de habilitar o recurso amplamente. O anúncio também exige um método de cobrança do Copilot configurado; isso é diferente de exigir que cada usuário tenha uma licença do Copilot. Requisitos de cobrança do anúncio de lançamento do GitHub, 15 de outubro de 2026

Em um piloto, registre o uso da sessão, o uso do Actions, o tempo dos revisores e se o patch foi aceito. Não prometa um preço fixo por alerta corrigido: um lote, uma iteração ou uma proposta malsucedida também precisa ser avaliado em termos de custo. Compare o custo das correções aceitas com o fluxo de trabalho existente, em vez de contar pull requests gerados como remediações concluídas.

O Copilot Autofix clássico é diferente: ele oferece uma alteração sugerida em uma etapa, em vez do fluxo de investigação e rascunho do agente, e suas sugestões não consomem créditos de IA. Onde houver suporte, continua sendo uma opção quando o Agentic Autofix não está habilitado. Comparação do GitHub, consultada em 18 de outubro de 2026

Antes do merge, responda a estas sete perguntas

Nossa lista de revisão se concentra tanto em preservar o comportamento quanto em eliminar a fraqueza relatada:

• Causa raiz: o patch corrige a operação insegura em vez de suprimir o aviso?
• Escopo: refatorações sem relação, novas dependências e mudanças de configuração estão justificadas?
• Comportamento: entradas válidas e inválidas, erros e permissões continuam funcionando corretamente?
• Testes: existe um teste de regressão que detectaria o problema original?
• Análise: o scanner que relatou o problema analisou a revisão proposta com a configuração necessária?
• Aprovação: uma pessoa responsável revisou o diff e as observações não resolvidas do agente?
• Depois do merge: a análise da branch padrão confirmou o estado esperado do alerta sem novas descobertas?

Trate “validação indisponível” como trabalho inacabado, não como aprovação. O GitHub informa que um agente pode declarar que não conseguiu validar ou que suspeita de um falso positivo no pull request. Nenhuma das afirmações substitui a avaliação de um mantenedor. Comportamento de melhor esforço do GitHub, consultado em 18 de outubro de 2026

E se o botão não aparecer ou o resultado estiver errado?

Por que vejo um alerta, mas não posso atribuí-lo? Confira se ele está pendente na branch padrão, a elegibilidade do repositório, a habilitação do recurso e suas permissões. A atribuição exige acesso de gravação. Se uma configuração estiver bloqueada, consulte o administrador apropriado em vez de alternar repetidamente o controle no repositório. Pré-requisitos de atribuição do GitHub, consultados em 18 de outubro de 2026

Uma varredura limpa prova que o aplicativo é seguro? Não. Ela responde às perguntas cobertas por aquela análise e configuração. Regras de negócio, autorização, comportamento em execução e descobertas não contempladas ainda exigem testes e revisão apropriados.

Devo continuar tentando uma sessão que falhou? Primeiro examine o registro e o diff proposto. Identifique se falta configuração da análise, execução de testes, contexto do projeto ou a própria correção proposta. Forneça uma instrução precisa ou corrija a configuração subjacente antes de tentar novamente; atribuições repetidas sem informações novas não são uma estratégia de remediação.

Posso aceitar um falso positivo suspeito? Investigue a descoberta de forma independente e documente o raciocínio. Não confunda descartar um alerta com corrigir código vulnerável, nem deixe a confiança do agente decidir uma exceção de risco.

Em resumo: uma correção proposta é o começo da revisão

O Agentic Autofix antecipa trabalho útil: investigação, um patch candidato e a validação disponível chegam juntos. O ganho prático é diminuir a distância entre identificar uma vulnerabilidade e revisar uma correção concreta. Mantenha a primeira tentativa restrita, preserve seus scanners e condicione a aceitação às evidências, não à autoria.

Fontes

Referências primárias consultadas em 18 de outubro de 2026.

Os links deste guia apontam para o anúncio de disponibilidade geral de 15 de outubro, as políticas de acesso atuais, os conceitos e limites do Autofix, os procedimentos para resolver alertas, a configuração do CodeQL e a documentação de cobrança do GitHub. A documentação é um retrato datado do acesso, não uma garantia para a configuração de cada conta. Os três fluxos são ilustrativos, não resultados de testes práticos.

Um lugar para suas notas de revisão: mantenha links de origem, referências a alertas, resultados de testes e decisões juntos no Telli.sh. Ele pode organizar suas notas; não faz varredura em repositórios nem aprova correções. Crie uma conta no Telli.sh.