Remediação de vulnerabilidades com IA: o que os pull requests de correção com IA conseguem fazer

O que é a remediação com IA

A remediação de vulnerabilidades com IA usa um modelo de linguagem para produzir a correção de uma vulnerabilidade conhecida. Apresenta-se de três formas:

• Sugestões de correção de código. Um modelo propõe um patch junto a um alerta de análise estática. O GitHub Copilot Autofix, por exemplo, "gera automaticamente sugestões de alteração de código para alertas do CodeQL encontrados em pull requests e no branch predefinido."
• Atualizações de dependências que adaptam o código. Subir uma versão é fácil. O difícil é a função renomeada ou o valor predefinido alterado que a nova versão traz. Um modelo pode fazer essas alterações decorrentes no mesmo pull request.
• Remediação agêntica. Um agente leva a correção por vários passos de forma autónoma: altera o código, executa o build e os testes, lê as falhas, tenta de novo e só abre um pull request quando as verificações passam.

Onde as correções com IA compensam

Os bots de atualização baseados em regras já abrem pull requests que sobem um pacote vulnerável para uma versão corrigida. Ficam parados quando a atualização parte alguma coisa, porque adaptar o código que faz as chamadas não é uma regra. É aí que o backlog se acumula: a atualização de segurança que fica aberta durante meses porque ninguém tem tempo para tratar da mudança de versão principal.

Ler um changelog, encontrar os pontos de chamada e reescrevê-los é o tipo de trabalho que os modelos de linguagem fazem bem. Uma correção com IA que chega com a atualização e as alterações de código, compilada e testada, transforma uma semana de atenção de alguém numa revisão.

Onde as correções com IA falham

As descrições mais claras dos limites vêm dos próprios fornecedores. Sobre o Copilot Autofix, o GitHub escreve:

• "Usa um modelo generativo que é não determinístico. Mesmo com o mesmo alerta e o mesmo código, pode não conseguir produzir uma sugestão viável, ou a sugestão pode variar entre tentativas."
• "O sistema não sabe que versões de dependências são suportadas ou seguras e pode sugerir dependências fabricadas, publicadas com nomes estatisticamente prováveis."

O segundo ponto não é hipotético. A investigação sobre modelos que geram código mediu a frequência com que recomendam pacotes que não existem, nomes que um atacante pode registar e encher de malware. Uma correção que instala um pacote inventado pelo modelo substitui uma vulnerabilidade por outra pior.

Três salvaguardas cobrem a maior parte do risco:

1. Compilar e testar cada correção antes de uma pessoa a rever, para que o tempo de revisão vá para correções que funcionam.
2. Verificar cada pacote adicionado ou alterado face ao registo e à versão que espera.
3. Manter uma pessoa a decidir o merge. Uma correção com IA é o pull request de um contribuidor, não uma decisão.

Lixo à entrada, pull requests à saída

Uma ferramenta de remediação com IA corrige as vulnerabilidades que lhe são indicadas. Se essa lista for reconstruída a partir de lockfiles ou de uma imagem analisada, herda todas as lacunas dessa reconstrução: ferramentas que o build descarrega e que nenhum manifesto declara, versões diferentes das que o build resolveu, pacotes restaurados de caches. A ferramenta abre então pull requests confiantes para algumas vulnerabilidades e nunca chega a saber das outras.

Algumas equipas vão mais longe e pedem a um modelo que deduza ele próprio as dependências. Isso torna também o inventário não determinístico, e esta é precisamente a parte do processo que deve dar sempre o mesmo resultado. SBOM geradas por IA explica porque é que um inventário adivinhado não é uma evidência.

O padrão que funciona é ter dados determinísticos por baixo e o discernimento da IA por cima: uma lista registada do que cada build realmente contém, cruzada com os avisos por consulta, e a IA a escrever a correção.

Onde o CRACI encaixa

O CRACI é a camada determinística. Executa os seus jobs de GitHub Actions em runners próprios e regista os pacotes que cada job efetivamente obteve, incluindo dependências transitivas e pacotes restaurados de caches, com um estado de completude para cada job. Reavalia continuamente as SBOM monitorizadas, para que um novo aviso apareça associado aos builds que afeta, e as equipas de segurança fazem a triagem de cada conclusão e enviam-na à equipa responsável pela correção.

É dessa lista que uma correção com IA deve partir e, depois do merge da correção, a SBOM do build seguinte mostra se a versão corrigida é a que o build realmente usou. Consulte acompanhamento de vulnerabilidades para a capacidade completa e IA face a segurança determinística para saber onde cada abordagem se aplica.

Remediação de vulnerabilidades com IA: perguntas frequentes

O que é a remediação de vulnerabilidades com IA?

A remediação de vulnerabilidades com IA usa um modelo de linguagem para produzir a correção de uma vulnerabilidade: uma alteração de código para uma conclusão de análise estática, ou uma atualização de dependência acompanhada das alterações de código de que essa atualização precisa. O resultado é normalmente uma sugestão ou um pull request para uma pessoa rever.

O que é a remediação agêntica?

A remediação agêntica dá a um agente de IA as ferramentas para levar uma correção por vários passos de forma autónoma: ler a conclusão, alterar o código, executar o build e os testes e iterar até passarem, abrindo depois um pull request. A diferença face a uma sugestão única é que o agente verifica o próprio trabalho antes de uma pessoa o ver.

É seguro fazer merge de correções de segurança geradas por IA?

Trate-as como o pull request de qualquer outro contribuidor. O GitHub descreve o Copilot Autofix como não determinístico e avisa que pode sugerir dependências fabricadas, por isso reveja a alteração, execute os testes e confirme que cada pacote que adiciona existe e é o que espera.

A IA consegue encontrar vulnerabilidades em dependências?

Não é a ferramenta certa para essa parte. Saber se uma versão de um pacote é afetada por um aviso conhecido é uma consulta, e deve dar sempre o mesmo resultado. Deixe que ferramentas determinísticas produzam a lista de pacotes vulneráveis a partir de uma SBOM registada e use a IA onde o discernimento ajuda: escrever e adaptar a correção.

De que precisa uma ferramenta de remediação com IA para funcionar bem?

De uma lista exata do que é realmente vulnerável, de um build e de um conjunto de testes com os quais possa validar a correção, e de uma pessoa a decidir o merge. O primeiro é o que mais falta: um pull request de correção para um pacote que o produto não distribui é ruído, e um pacote vulnerável que o inventário não detetou nunca recebe um.