GitHub AI Scan agora liga a varredura de repositórios via REST API

O GitHub anunciou em 13/11/2026 que o AI Scan for repositories, do code scanning, agora pode ser ligado ou desligado pela REST API, tanto na organização quanto em cada repositório. A mudança está em public preview e adiciona a configuração repository_scan aos endpoints de habilitação do AI Scan que já existiam, segundo o changelog oficial do GitHub.

Com isso, o rollout pode ser feito por script e infraestrutura como código, sem alterar as configurações uma organização ou um repositório por vez. Para times de segurança, isso exige atenção a três pontos: herança de configuração, erro 422 e consumo de AI credits.

O que é o AI Scan for repositories e como ele difere do pr_scan

O AI Scan for repositories procura vulnerabilidades no repositório inteiro, e não só nas mudanças de um pull request. Ele entrou em public preview em 28/10/2026, conforme o anúncio do lançamento.

Segundo o changelog de 28/10/2026, cada varredura analisa o commit mais recente do branch padrão, cobrindo linguagens e frameworks que o CodeQL não suporta, além de encontrar problemas que a análise baseada em regras pode deixar passar em linguagens que o CodeQL já cobre. Os achados entram no backlog de code scanning junto com os alertas do CodeQL.

Nesse backlog, cada achado pode ser atribuído, vinculado a issues, incluído em security campaigns ou corrigido com agentic autofix. Ou seja, o resultado cai no mesmo fluxo que o time de segurança já usa.

Já o AI Scan for pull requests, controlado pela configuração pr_scan, é outra capacidade. As APIs dele entraram em public preview em 10/09/2026 e o recurso chegou à disponibilidade geral em 15/10/2026.

A boa notícia é que repository_scan funciona do mesmo jeito que pr_scan. Se você já automatizou o AI Scan de pull requests, a lógica é a mesma.

Como a REST API controla o repository_scan

A propriedade repository_scan aceita os valores enabled e disabled. Ela vive nos endpoints de habilitação do AI Scan:

• GET e PATCH /orgs/{org}/code-scanning/ai-scan
• GET e PATCH /repos/{owner}/{repo}/code-scanning/ai-scan

A herança segue uma regra simples. Se a organização desabilita o AI Scan for repositories, os repositórios dela não conseguem habilitá-lo.

Se a organização habilita, os repositórios herdam a configuração e podem sair individualmente com opt-out. Na prática, a organização define o teto e cada repositório só pode recuar.

O formato exato do corpo da requisição e da resposta não aparece no changelog. Antes de escrever o script, consulte a referência dos endpoints de code scanning, que o próprio changelog indica como ponto de partida.

Quando a requisição retorna erro 422

O erro 422 aparece em dois cenários confirmados. O primeiro é quando a política da enterprise não permite o AI Scan: qualquer requisição para habilitá-lo falha.

O segundo envolve alterações conjuntas. Você pode mudar pr_scan e repository_scan na mesma requisição, mas se qualquer uma das mudanças for bloqueada, a requisição retorna 422 e nenhuma das duas configurações muda.

Esse comportamento atômico ajuda bastante em automação. Seu script ou pipeline de IaC deve tratar o 422 como falha da requisição inteira, sem supor que metade foi aplicada.

Tome cuidado com um detalhe: se a causa do 422 for a política da enterprise, nem retry cego nem separar as duas configurações resolve, é preciso ajustar a política primeiro, já que ela bloqueia o AI Scan independentemente de como a requisição é feita.

Quem pode gerenciar e em quais repositórios o recurso funciona

Owners e security managers da organização gerenciam a configuração no nível da organização. Administradores de repositório podem tirar repositórios individuais com opt-out.

Antes de tudo, os owners da enterprise precisam permitir o AI Scan na política da enterprise. Sem isso, o resto da cadeia não funciona.

O AI Scan for repositories está disponível em repositórios públicos de organizações e em repositórios privados ou internos que tenham GitHub Code Security ou GitHub Advanced Security.

Segundo o anúncio de 28/10/2026, ele roda no github.com e no GitHub Enterprise Cloud com data residency, e não exige licença do GitHub Copilot. O GitHub Enterprise Server (GHES) não é suportado.

Habilitar não inicia varredura: o que isso significa para o custo

Ligar o repository_scan não dispara nenhuma varredura. Quem tem acesso de escrita (write) continua rodando os scans sob demanda.

Cada varredura consome AI credits do GitHub Code Security. Então habilitar em massa não gera custo imediato, mas amplia o número de repositórios em que alguém pode gastar créditos.

Na prática, o controle de custo depende de duas coisas: quem tem acesso de escrita em cada repositório e quais repositórios fizeram opt-out. A habilitação em si funciona mais como uma liberação do que como um gatilho.

Isso muda o jeito de planejar o rollout. Em vez de pensar "quantos scans vamos rodar", o time precisa pensar "em quais repositórios faz sentido permitir que alguém rode".

Próximo passo para o rollout

Comece confirmando com os owners da enterprise se a política permite o AI Scan. Sem essa liberação, qualquer PATCH de habilitação volta com 422.

Depois, liste os repositórios que devem fazer opt-out por causa do consumo de AI credits e só então aplique a habilitação. Como o recurso está em public preview, vale acompanhar o changelog, que também aponta para a referência dos endpoints.

Acompanhe os tutoriais do Hora de Codar no YouTube.