Como agentes de codificação de IA podem prejudicar o software livre

Recentemente, tive a oportunidade de usar o Agente de IA Jules, do Google, para analisar todo o repositório de código de um dos meus projetos e adicionar uma nova funcionalidade. O processo levou cerca de 10 minutos. No total, utilizei a IA, revisei suas alterações e implementei a nova feature em menos de 30 minutos. Fiquei muito impressionado na hora. Porém, quanto mais tempo passa, mais preocupado estou.

É evidente que o potencial para ações maliciosas por parte de agentes adversários aumentou exponencialmente. Isso é realmente assustador. Neste artigo, vamos explorar esse assunto em três partes: o que pode acontecer, como isso pode ocorrer e maneiras de prevenir tais situações.

Vamos começar considerando a possibilidade de uma IA maliciosa treinada com capacidades de agente de codificação. Essa IA poderia ser utilizada por um ator hostil, que poderia ser uma nação afastada ou até mesmo um "amigo inimigo". Tanto a China quanto a Rússia, países com os quais os EUA possuem relações incertas, já foram responsáveis por ataques cibernéticos à infraestrutura crítica dos EUA.

Para o propósito desta reflexão, imagine que um ator malicioso desenvolve uma ferramenta de IA semelhante ao Jules, ao OpenAI Codex ou ao GitHub Copilot. Agora, envisionemos que uma ferramenta com essas capacidades de modificação de código fue disponibilizada ao público. À primeira vista, parece uma conversa amigável e útil.

Em seguida, imagine essa ferramenta maliciosa ganhando acesso (não vamos nos preocupar em como isso acontece — isso será discutido na próxima seção) a um grande repositório de código no GitHub, com a capacidade de fazer modificações. Para dar uma noção da escala desse repositório, o código que analisei com o Jules possui 12.000 linhas. Um produto que vendi no ano passado tinha 36.000 linhas. Projetos como o WordPress contêm cerca de 650.000 linhas, e distribuições do Linux têm milhões.

Agora, imagine se essa ferramenta maliciosa pudesse acessar qualquer um desses repositórios (ou os milhões de outros disponíveis, tanto de código aberto quanto proprietários) no GitHub. Seria possível inserir 5 ou 10 linhas de código sem que ninguém perceba? Estamos falando apenas de algumas linhas em meio a centenas de milhares ou milhões. Ninguém pode monitorar tudo isso.

Considere algumas estratégias furtivas, mas eficazes, que poderiam ser empregadas:

Inserção de "lógica bomba" com gatilhos que parecem inofensivos: algo ruim poderia ser ativado ao atingir uma determinada condição.
Adição de rotinas sutis de extração de dados: criar uma forma de vazar informações sensíveis para um servidor externo, como chaves de acesso de API, um pouco de cada vez.
Modificação de mecanismos de atualização para incluir cargas maliciosas: quando um atualizador automático é executado, pode incorporar dados de fontes não autorizadas ou até blocos inteiros de código malicioso.
Ocultação de portas de acesso por meio de pequenos flags de funcionalidade ou verificações de ambiente: habilitar pontos de entrada, mas apenas em certas condições, tornando essas portas muito difíceis de serem descobertas.
Introdução de vulnerabilidades de confusão de dependências: alterar nomes ou versões de módulos de código, fazendo com que gerenciadores de pacotes baixem versões maliciosas de repositórios públicos.
Criação de bugs de concorrência baseados em tempo ou vazamentos de memória: mudanças simples em cadeados de thread, alocação de memória ou tratamento de erros podem gerar uma instabilidade difícil de rastrear.
A redução da força funcional de métodos criptográficos ou da geração de números aleatórios: a IA poderia substituir chamadas de criptografia forte por rotinas que são significativamente menos seguras.
Ocultar funções maliciosas em códigos de teste ou depuração: a maior parte da auditoria de código ocorre em códigos de teste, então se o código malicioso estiver escondido ali, pode nunca ser encontrado.
Supressão de falsos positivos ou manipulação de logs: tudo o que a IA precisaria fazer é esconder dados de registros de erros. Se o log não mostrar um erro, pode nunca ser descoberto.
Criação de caminhos de escalonamento de privilégios na lógica de permissões: ao fraquejar a lógica de acesso, a IA pode facilitar o acesso a usuários maliciosos.

Esses são apenas dez exemplos de explorações furtivas que me vêm à mente. O mais alarmante é que a implementação de tais explorações pode ser feita com um código muito pequeno. O que a IA precisaria fazer é inserir algo como isto em um arquivo JSON:

"useful-lib": "1.2.3-old"

Ou como liberar um bloqueio cedo, com apenas essa linha:

pthread_mutex_unlock(&amp;lock);

O código poderia ser adicionado como comentários durante uma atualização e, em versões subsequentes, as características de comentário poderiam ser retiradas. É importante lembrar que, ao se falar de milhões de linhas de código, é possível perder uma linha aqui e ali. Os programadores precisam ser diligentes com cada linha. A IA só precisa passar uma. Essa é uma desvantagem assimétrica.

Agora que discutimos o que pode acontecer, vamos explorar como isso poderia ocorrer. Muitas vezes, presume-se que os codificadores e revisores de código notariam mudanças maliciosas durante as solicitações de pull. Contudo, há várias maneiras de essas invasões acontecerem.

As possibilidades incluem desde um revisor não notar uma alteração, ao roubo de credenciais de revisores ou até mesmo a aquisição de um repositório por um ator adverso. Vamos examinar algumas dessas falhas de segurança:

Roubo de credenciais de desenvolvedores ou revisores.
Engenharia social para criar confiança entre os contribuidores.
"Envenenamento" de solicitações de pull por meio da fadiga dos revisores.
Infiltração na cadeia de suprimentos via dependências comprometidas.
Ameaças internas de contribuidores comprometidos.
Manipulação da configuração de integração contínua.
Manipulação de ramificações para introduzir portas de acesso.
Tomada de controle de repositórios ou organizações.
Comprometimento de tokens de automação.
Políticas de revisão fracas ou passagens de revisões.

Essas vulnerabilidades demonstram que a proteção do código não é garantida. Algumas rotinas de revisão podem ser rigorosas, mas qualquer desvio de protocolar pode resultar em uma grande exposição.

Diante de tudo isso, inicialmente pensei em combater a IA com IA. Para isso, utilizei o recurso Deep Research da OpenAI em um grande repositório de código público. No entanto, as coisas não funcionaram tão bem. Em poucas horas, utilizei metade das minhas alocações de sessão mensais.

O modelo fez o que foi mais fácil: visitar websites e relatar vulnerabilidades já conhecidas, ao invés de se concentrar no código em si.

Portanto, simplesmente contar com agentes de IA para nos proteger de outros agentes de IA pode não ser a abordagem mais segura. Em vez disso, é importante adotar práticas centradas no ser humano que todos os repositórios deveriam seguir:

Controle rigoroso de acesso: aplicação de autenticação multifator e rotação de credenciais.
Políticas de revisão de código rigorosas: a proteção dos repositórios exige múltiplos revisores humanos e aprovações.
Controle ativo de dependências: travamento de versões, auditando pacotes diretamente e na hierarquia de herança.
Fortalecimento da implantação: restrição de escopo de tokens e chaves de API, auditoria por múltiplas pessoas.
Monitoramento comportamental: vigilância de comportamentos fora do comum de contribuidores.
Análise estática e dinâmica automatizada: uso de múltiplas IAs para escanear em cada pull request.
Regras de proteção de ramificações: proibição de envios diretos para a ramificação principal.
Registro e alerta de eventos: monitoramento de qualquer alteração ou ativação de solicitações.
Treinamento em segurança para mantenedores: formação sobre as técnicas usadas por agentes maliciosos.
Auditorias regulares: no futuro, podemos usar IA para realizar auditorias frequentes em busca de problemas.

Embora isso exija muito trabalho, o avanço das IAs também pode beneficiar os desenvolvedores, mas também aqueles que pretendem causar danos.

Este é um momento de grande cuidado. Você acredita que ferramentas de IA como agentes de codificação representam um risco real à segurança do código aberto? Você já pensou em como algumas linhas maliciosas podem passar despercebidas em um repositório massivo? Acredita que os processos de revisão atuais são fortes o suficiente ou precisam ser revisados?

Referência: [link da matéria]