Google Cloud mostra como rodar o agente CodeMender nos pull requests, com correção automática de falhas

A arquitetura de referência liga o CodeMender, agente autônomo de segurança de código do Google, ao fluxo de pull request no Git, com a execução em Cloud Run. O scan publica um comentário com tabela de achados, cada um com ID. O desenvolvedor responde com /verify para ver o exploit simulado ou /fix para receber o patch em diff, com um pull request em rascunho aberto. O /approve faz o agente commitar e dar push, e marca o status security/codemender-gate como verde. Sem branch protection, esse gate é só consultivo.

O Google justifica o desenho com números do Mandiant M-Trends 2026: o tempo médio de correção de falhas subiu de cerca de 59 dias, há uma década, para mais de 170 dias em 2025. Para achados com confiança abaixo de 100%, o cm verify monta e simula um exploit em sandbox. Como o sandbox é efêmero, os artefatos vão para o Google Cloud Storage como trilha de auditoria. Um cuidado de engenharia: o parser precisa separar resultado negativo real de crash de teste (servidor mock caído, timeout). Falha sem conclusão deve virar "inconclusivo", nunca "seguro".

Na autenticação, o GitHub Actions emite um token OIDC de curta duração aceito pelo Google, sem chave de longa duração no pipeline. A segurança está na condição do provedor: o issuer é comum a todos os workflows, então não basta validá-lo. O Google recomenda mapear repository_id e repository_owner_id, que são imutáveis, em vez do nome do repositório, que pode ser renomeado ou reivindicado por terceiros. A verificação roda como Cloud Run job, um por achado, na segunda geração do ambiente de execução (microVM). O job usa service account própria e sem permissões extras, evita a conta padrão do Compute Engine e usa Direct VPC egress em subnet sem rota de saída. Os sandboxes de agente do Cloud Run isolam variáveis de ambiente, segredos e o servidor de metadados.

Em 27 de maio de 2026, o CEVIU noticiou "Google Expande Testes Externos para o CodeMender, seu Agente de IA para Segurança de Software", quando o agente ainda estava em ampliação de testes externos. Em 11 de agosto de 2026, em "Google revoluciona correção de bugs com IA para segurança de memória", veio a integração com o OSS-Fuzz. Agora o foco sai da detecção e do código aberto e chega ao fluxo diário do time: pull request, comandos de barra e gate de merge. Em 4 de novembro de 2026, o CEVIU também cobriu a abordagem do Google para defender sistemas em velocidade de máquina na era agentic, contexto no qual esta referência se encaixa.

Para quem opera pipelines, a leitura é que o agente de correção passa a ser mais um componente com privilégios de escrita no código, e deve ser tratado assim. O ganho em tempo de correção só vale se o gate estiver ligado à branch protection, o OIDC estiver restrito por IDs imutáveis e o sandbox de exploit não tiver credencial nem rota de rede. Quem já usa Cloud Run e GitHub Actions tem um modelo concreto para copiar.