- A governança virou o gargalo 🛡️
- O problema está escondido na cauda longa 🔎
- Quando um pacote obscuro entra pela porta da frente 📦
- O caso Trivy mostrou o tamanho do estrago 🚨
- IA não criou o problema. Ela pisou no acelerador
- E os próprios modelos também entram na equação 🤖
- O próximo desafio é automatizar a própria segurança
- O código está correndo. Quem vai fiscalizar? 🏃
Principais destaques
- Código em velocidade inédita: assistentes de IA estão incorporando bibliotecas, pacotes e imagens de contêiner muito mais rápido do que as equipes conseguem revisar.
- A cauda longa virou alvo: projetos de código aberto pouco conhecidos e mantidos por poucas pessoas estão sendo explorados para introduzir malware em pipelines de desenvolvimento.
- A segurança precisa mudar de ritmo: pesquisadores e empresas já investem em novas formas de avaliar dependências e modelos de IA antes que eles entrem nos ambientes corporativos.
A inteligência artificial está mudando uma das regras mais básicas do desenvolvimento de software: quanto mais rápido o código pode ser produzido, mais rapidamente novas dependências entram na aplicação.
O problema é que a segurança não necessariamente acompanha essa velocidade.
Assistentes de programação baseados em IA conseguem gerar código, sugerir bibliotecas, instalar pacotes e montar componentes inteiros em questão de segundos. Para equipes corporativas, isso significa produtividade. Também significa uma quantidade crescente de código de terceiros que precisa ser compreendida e considerada segura.
E é aí que começa o problema.
A governança virou o gargalo 🛡️
Quincy Castro, CISO da Chainguard, resumiu o cenário em entrevista ao VentureBeat: “A velocidade superou a governança e os controles.”
Segundo ele, o modelo tradicional de desenvolvimento pressupunha algum tempo entre a solicitação de código, sua implementação, revisão e aprovação.
A IA encurta drasticamente esse intervalo.
⚡ O novo gargalo: quando um desenvolvedor consegue gerar código quase instantaneamente, processos de segurança baseados em revisão humana passam a funcionar como um freio em um fluxo que foi acelerado artificialmente.
Castro também questionou a capacidade das organizações de avaliar adequadamente todas as dependências utilizadas por seus desenvolvedores.
Em uma empresa de grande porte, uma equipe pequena de segurança dificilmente consegue ser especialista em todas as linguagens, frameworks, bibliotecas e componentes usados simultaneamente.
“A velocidade superou a governança e os controles.”
O resultado é uma equação complicada: mais código sendo produzido, mais componentes externos sendo incorporados e praticamente o mesmo número de pessoas responsáveis por verificar se tudo isso é seguro.
O problema está escondido na cauda longa 🔎
Um dos dados apresentados pela Chainguard ajuda a dimensionar o desafio.
O relatório State of Trusted Open Source, publicado em junho de 2026, aponta que 97% das vulnerabilidades e exposições comuns estavam fora das 20 principais imagens de contêiner analisadas.
Na edição de março, esse número era de 96%.
| Indicador | Março de 2026 | Junho de 2026 |
|---|---|---|
| CVEs fora das 20 principais imagens | 96% | 97% |
Isso cria uma espécie de paradoxo.
As empresas podem concentrar esforços de hardening nas imagens mais populares e conhecidas. Mas justamente a enorme quantidade de componentes menos conhecidos pode esconder uma parcela significativa das vulnerabilidades.
E ferramentas de IA podem tornar essa “cauda longa” ainda maior.
Quando um pacote obscuro entra pela porta da frente 📦
Para um modelo de IA, uma biblioteca pouco conhecida pode parecer apenas uma solução adequada para determinada tarefa.
Para um atacante, ela pode representar uma oportunidade.
Castro citou uma operação na qual agentes de ameaça produziram grandes quantidades de forks de projetos legítimos, adicionaram malware e os distribuíram para aumentar as chances de desenvolvedores incorporarem o código comprometido em seus pipelines de CI/CD.
A lógica é simples: em vez de atacar diretamente uma grande empresa, o invasor tenta entrar por um componente aparentemente inofensivo.
🧩 A dependência é o novo caminho: quanto maior o número de componentes externos utilizados por uma aplicação, maior também é o conjunto de elementos que precisa ser monitorado.
Isso não significa que uma biblioteca de código aberto seja insegura simplesmente por ser pequena ou pouco conhecida. O problema está na dificuldade de avaliar milhares de componentes em escala.
O caso Trivy mostrou o tamanho do estrago 🚨
Um episódio ocorrido em março tornou esse risco particularmente concreto.
Invasores comprometeram o GitHub Actions utilizado pelo Trivy, um conhecido scanner de vulnerabilidades. O ataque permitiu inserir commits maliciosos em 76 das 77 tags de versão.
O payload tinha como objetivo roubar credenciais e era executado silenciosamente antes da execução legítima da ferramenta.
O incidente foi registrado como CVE-2026-33634, com pontuação crítica de 9,4.
Mais de 10 mil fluxos de trabalho de CI/CD foram afetados.
É justamente esse tipo de incidente que preocupa equipes de segurança: uma ferramenta criada para ajudar a proteger software pode se transformar em um vetor de ataque quando sua própria cadeia de fornecimento é comprometida.
IA não criou o problema. Ela pisou no acelerador
Há uma diferença importante aqui.
O risco de dependências maliciosas, pacotes comprometidos e ataques à cadeia de fornecimento de software existe há anos. A inteligência artificial não inventou essa categoria de ameaça.
O que mudou foi a velocidade.
Imagine uma equipe que antes adicionava algumas dependências por semana e agora consegue gerar aplicações inteiras com auxílio de agentes de programação. Mesmo que a proporção de componentes problemáticos permaneça pequena, o volume absoluto de elementos que precisam ser avaliados pode crescer rapidamente.
📈 Mais produção também significa mais superfície: a questão deixa de ser apenas “este código é seguro?” e passa a ser “como verificar milhões de decisões automatizadas sem transformar a revisão em um gargalo?”
É uma mudança de escala.
E os próprios modelos também entram na equação 🤖
A preocupação não termina nas bibliotecas.
Pesquisadores da Universidade de Indiana estão trabalhando justamente sobre a segurança de modelos de IA de código aberto.
O projeto recebeu US$ 1,18 milhão da National Science Foundation e é liderado por Sagar Samtani, da Kelley School of Business da universidade.
A pesquisa pretende identificar quais modelos de IA de código aberto são mais utilizados por pesquisadores, avaliar suas vulnerabilidades e desenvolver ferramentas capazes de recomendar alternativas consideradas mais seguras.
A iniciativa será testada no Jetstream2, serviço nacional de computação em nuvem voltado à ciência e engenharia e administrado pela Universidade de Indiana.
O próximo desafio é automatizar a própria segurança
Existe uma ironia interessante nessa história.
A IA está ajudando a produzir software rápido demais para que processos tradicionais de segurança consigam acompanhar. Ao mesmo tempo, pesquisadores estão tentando usar ferramentas automatizadas para tornar a própria segurança mais escalável.
Isso pode levar a uma nova camada de ferramentas capazes de verificar automaticamente:
• dependências adicionadas por agentes de IA;
• bibliotecas e imagens de contêiner utilizadas pelo projeto;
• modelos de código aberto empregados no desenvolvimento;
• vulnerabilidades conhecidas e sinais de comprometimento;
• alternativas potencialmente mais seguras.
O objetivo não é necessariamente colocar um humano no meio de cada decisão.
É fazer com que os controles também consigam operar na velocidade das máquinas.
O código está correndo. Quem vai fiscalizar? 🏃
Durante décadas, o desenvolvimento de software foi limitado em boa medida pela capacidade humana de escrever, revisar e aprovar código.
A programação assistida por IA está alterando essa relação.
Agora, uma equipe pode produzir muito mais código em menos tempo. Mas produtividade adicional só representa ganho real se a organização conseguir acompanhar também o crescimento das dependências, dos componentes e dos riscos associados.
O cenário descrito pela Chainguard aponta para uma mudança de paradigma: a segurança da cadeia de fornecimento não pode mais depender apenas de equipes humanas tentando acompanhar manualmente tudo o que os desenvolvedores e agentes de IA colocam em produção.
A corrida, portanto, não é apenas para escrever software mais rápido.
É para descobrir se a segurança consegue correr junto.
