A cadeia de build virou alvo primário.

Convem começar pelo desconforto: na maioria das organizações que conhecemos na região, o servidor de integração contínua tem mais credenciais privilegiadas que qualquer servidor de aplicação. Chave de nuvem, token de registry, segredo de banco, credencial de deploy. Tudo isso mora lá porque precisa morar lá. E, ao mesmo tempo, esse servidor raramente aparece no escopo do pentest anual, quase nunca está no inventário de ativos críticos e frequentemente responde na rede interna sem segmentação real.

O que a semana mostrou

Camada	Ocorrência	Por que importa
Servidor de CI	Falha crítica no TeamCity permite executar comandos de sistema operacional sem autenticação.	Acesso pré-autenticação ao orquestrador de build alcança todos os segredos da esteira de uma vez.
Repositório	Execução remota de código no Gitea permite que quem tem permissão de escrita plante um git hook e rode comandos.	Permissão de escrita costuma ser distribuída com generosidade. Ela deixa de ser permissão de código e vira permissão de shell.
Automação	Escape de sandbox no n8n permite que editores de workflow executem comandos como o processo da aplicação.	Ferramentas de automação concentram integrações e tokens de múltiplos sistemas de negócio.
Dependências	Dois pacotes npm comprometidos executam um RAT quando importados em Node.js.	O gatilho é a importação, não a execução do código da aplicação. Um npm install em estação de desenvolvedor já basta.
Agente de revisão	Falha no MCP do Azure DevOps permite que comentários ocultos em pull request sequestrem agentes de revisão com IA.	Injeção de prompt deixa de ser curiosidade acadêmica quando o agente tem permissão de escrita no repositório.
Runner	Atacantes usam runners do GitHub Actions para atingir servidores cPanel e WHM.	O runner é computação confiável com saída de rede. Serve tanto para construir software quanto para atacar a partir de dentro.

O padrão por trás dos casos

Trocando os nomes dos produtos, sobra sempre a mesma estrutura. Existe um componente que precisa de privilégio alto para funcionar, recebe permissões amplas por conveniência operacional e é tratado como ferramenta interna em vez de ativo crítico. O atacante não precisa de zero-day sofisticado quando encontra um servidor de CI com interface exposta e um modelo de permissão herdado de quando a equipe tinha oito pessoas.

A novidade real da semana é a última linha da tabela acima. Agentes de revisão de código introduzem um vetor que não existia: conteúdo controlado pelo atacante entra no contexto de um processo que tem permissão de escrita. Um comentário de pull request é dado não confiável por definição. Quando esse dado alimenta um agente autorizado a alterar o repositório, a fronteira entre entrada e instrução desaparece.

É o mesmo padrão descrito no OWASP Top 10 para aplicações de LLM, só que aplicado ao lugar onde o código nasce. Vale a comparação com um problema antigo: injecção de SQL também começou como curiosidade e virou década de prejuízo porque a indústria demorou a aceitar que entrada de usuário nunca é instrução.

Um contraponto honesto

Nem tudo na semana foi deterioração. O GitHub passou a aplicar um período de espera de três dias no Dependabot antes de propor a adoção de novas versões de pacote. É uma medida modesta e de baixa tecnologia que ataca uma janela real: a maior parte dos pacotes comprometidos é detectada e removida em poucas horas ou dias. Quem atualiza automaticamente no mesmo instante da publicação assume o risco integral dessa janela. Quem espera três dias transfere boa parte dele para o ecossistema.

Não resolve ataque paciente, obviamente. Um invasor que mantenha o pacote limpo por semanas passa pelo período de espera sem esforço. Ainda assim, é um bom exemplo de controle que troca um pouco de velocidade por bastante redução de exposição, e que não exige comprar nada.

Roteiro de trinta dias

Como isso conversa com NIST CSF 2.0 e LGPD

Do ponto de vista de governança, a esteira de build cai em Identificar e Proteger no NIST CSF 2.0, e quase sempre com nota baixa em ambas por um motivo simples: não está no inventário. Se o ativo não existe no registro, o controle não tem onde ser aplicado e a evidência não tem onde ser coletada.

Há também um ângulo de LGPD que costuma passar despercebido. Ambiente de desenvolvimento com dado real de produção é comum, e uma esteira comprometida vira incidente com dado pessoal, com todas as obrigações de comunicação que isso implica. Vale checar, antes que a checagem seja feita por outro motivo, se há dado real em base de teste e quem autorizou.

Para quem responde a conselho, a formulação que costuma funcionar é direta: o controle de mudança da empresa cobre o que entra em produção, mas não cobre quem pode alterar o processo que constrói o que entra em produção. Fechar essa lacuna é barato agora e caro depois.