A Cadeia de Suprimentos de Software Está Sob Ataque dos Dois Lados

Thomas Ptacek publicou um post na semana passada que merece ser lido devagar. A tese: pesquisa de vulnerabilidades, como disciplina, está prestes a mudar de natureza. Não porque surgiu uma ferramenta nova. Porque o custo de encontrar falhas em código caiu a quase zero.

No mesmo dia, a The New Stack publicou dados sobre o outro lado do problema. Projetos open source estão sendo inundados por contribuições geradas por IA, tão plausíveis na superfície quanto frágeis por dentro. O projeto Jazzband encerrou atividades. Mantenedores voluntários estão abandonando repositórios.

Duas crises. A mesma cadeia de suprimentos. E a mesma causa raiz: agentes de IA operam sem governança.

O Custo Zero de Encontrar Falhas

Ptacek descreve um pipeline que deveria preocupar qualquer organização que depende de software. Nicholas Carlini, pesquisador de segurança do Google, construiu um script bash que aponta um agente para código-fonte e pede: “encontre zero-days.” A taxa de sucesso reportada é “quase 100%” para vulnerabilidades exploráveis verificadas. Carlini encontrou SQL injection explorável no Ghost CMS usando essa abordagem.

O Anthropic Frontier Red Team reportou 500 vulnerabilidades de alta severidade validadas usando o Claude Opus 4.6. Quinhentas. De um único modelo, apontado para código aberto.

Ptacek enquadra o argumento com a “Bitter Lesson” de Richard Sutton: expertise do domínio não importa, apenas dados e computação. Pesquisadores de segurança passam 80% do tempo montando quebra-cabeças gigantes, tentando combinações até encontrar a peça certa. Agentes de IA são máquinas universais de resolver quebra-cabeças.

A implicação prática: código-fonte fechado deixou de ser defesa. Por décadas, empresas confiaram na obscuridade como barreira. O custo de auditar um codebase proprietário era proibitivo para a maioria dos atacantes. Esse custo agora tende a zero. Ptacek não usa meias palavras: “Nenhuma defesa parece mais frágil agora do que código-fonte fechado.”

Como analisamos em A Camada de Governança, a detecção de vulnerabilidades está no caminho de se tornar commodity. Os dados de Ptacek confirmam que essa compressão está acontecendo mais rápido do que o previsto.

A Inundação Pelo Outro Lado

Enquanto agentes encontram falhas a custo quase zero, outros agentes criam falhas a custo quase zero.

A The New Stack reporta um dado que deveria ser lido como alarme: 96% dos codebases comerciais contêm código open source. Essa dependência é conhecida. O que mudou é a pressão sobre quem mantém esse código. 60% dos mantenedores são voluntários não remunerados. E agora precisam lidar com um volume crescente de pull requests gerados por IA.

A assimetria de custo é brutal. Revisar um PR gerado por IA leva 12 vezes mais tempo do que gerá-lo. Doze vezes. Um desenvolvedor com acesso ao Copilot pode produzir dez PRs por hora. O mantenedor voluntário que precisa avaliar cada um tem o mesmo número de horas no dia que tinha antes.

Mitchell Hashimoto, fundador da HashiCorp, descreveu o fenômeno com precisão: ferramentas de IA tornam trivial “criar contribuições que parecem plausíveis mas são de qualidade extremamente baixa.” O problema não é que o código esteja obviamente errado. É que ele parece certo o suficiente para exigir investigação profunda antes de ser rejeitado.

Já documentamos como esse vetor opera na prática. Em Do Título da Issue ao Malware, mostramos como um atacante usou prompt injection para comprometer a cadeia de suprimentos via agente de codificação. O ataque funcionou porque o agente processou dados não confiáveis sem validação. A mesma ausência de governança que permite spam de PRs permite injeção de código malicioso.

A Economia Que Ninguém Quer Enfrentar

Esses dois problemas parecem distintos. Um é sobre segurança ofensiva. O outro é sobre qualidade de contribuições. Mas a economia subjacente é idêntica.

Agentes de IA reduziram o custo de produzir artefatos de código (sejam exploits ou pull requests) a quase zero. O custo de avaliar esses artefatos permaneceu inalterado. Em alguns casos, aumentou, porque a aparência de qualidade mascara defeitos que exigem análise mais profunda.

Soormally, da Wundergraph, capturou a assimetria em uma frase: “IA pode escalar geração de código, mas não pode escalar responsabilidade.”

Essa frase merece um parágrafo próprio porque contém toda a tese. Responsabilidade não escala com computação. Ela exige julgamento humano, contexto organizacional e consequências reais para decisões erradas. Nenhum agente fornece isso.

O resultado é uma cadeia de suprimentos sob pressão dos dois lados. Por cima, agentes encontram vulnerabilidades que estavam precificadas como risco aceitável. Ptacek observa que fraquezas conhecidas em software proprietário eram parte do cálculo de custo de cada departamento de TI na América do Norte. Esse cálculo não se sustenta mais. Por baixo, agentes inundam os repositórios que alimentam 96% dos codebases comerciais com contribuições que consomem recursos de revisão sem adicionar valor proporcional.

A Resposta Fragmentada

A comunidade open source está tentando reagir. A Red Monk catalogou 63 políticas formais de IA em fundações e projetos. Catorze projetos proíbem contribuições de IA. Doze ainda estão indecisos. Os demais permitem com restrições variadas.

Holterhoff, da Red Monk, fez uma observação que merece atenção: “Quanto mais perto da base da pilha você vai, menos permissivo com IA você precisa ser.” Bibliotecas de infraestrutura, kernels, compiladores. São componentes onde um defeito sutil se propaga para milhões de aplicações dependentes. A tolerância a risco deveria ser inversamente proporcional à profundidade na pilha.

Mas políticas de contribuição resolvem apenas metade do problema. Mesmo que todo projeto open source proíba PRs gerados por IA (o que não vai acontecer), o problema de descoberta de vulnerabilidades permanece. Agentes vão continuar encontrando falhas em código existente, independentemente de como contribuições futuras sejam filtradas.

O Que Muda Para Organizações

Para quem consome software (e todos consomem), três realidades precisam ser internalizadas.

Código fechado não é defesa. Se sua estratégia de segurança depende de que ninguém consiga auditar seu código, essa estratégia tem data de validade. Agentes de IA estão tornando a auditoria automatizada acessível para atacantes com recursos modestos. A pergunta deixou de ser “alguém vai encontrar essa falha?” e passou a ser “quando.”

Suas dependências open source são tão confiáveis quanto seus mantenedores são sustentáveis. Se 60% dos mantenedores são voluntários não remunerados e agora enfrentam 12x mais trabalho de revisão, a matemática não fecha. Organizações que dependem de componentes open source sem contribuir para sua sustentabilidade estão acumulando risco que nenhum scanner vai detectar.

Governança precisa cobrir ambos os lados. O agente que você usa para gerar código e o agente que um atacante usa para encontrar falhas no seu código operam com a mesma tecnologia. A diferença está em quem controla, audita e limita o que cada agente pode fazer. Como argumentamos em Governança de IA É Cybersecurity, separar segurança de governança é um erro que se torna mais caro a cada mês.

A Pergunta Certa

A tentação é tratar isso como dois problemas separados. Um time cuida de segurança, outro de qualidade de dependências. Um orçamento para scanners, outro para gestão de fornecedores.

Essa separação é o problema. A cadeia de suprimentos de software é uma única superfície, pressionada por agentes dos dois lados. As organizações que vão enfrentar isso com competência são as que entendem que governança de agentes não é uma disciplina especializada. É a disciplina que conecta segurança, qualidade e operações numa única estrutura de controle.

Ptacek termina seu ensaio com uma frase que vale repetir: “Você não pode projetar um problema melhor para um agente de LLM do que pesquisa de exploits.” Ele está certo. E o complemento é igualmente verdadeiro: você não pode projetar uma defesa pior do que operar sem governança numa era de agentes autônomos.

Fontes

Ptacek, Thomas. “Vulnerability Research Is Cooked.” March 2026.
Doerrfeld, Bill. “96% of Codebases Rely on Open Source, and AI Slop Is Putting Them at Risk.” March 2026.

Victorino Group ajuda empresas a construir infraestrutura de governança antes que a próxima vulnerabilidade chegue: contato@victorino.com.br | www.victorino.com.br