A semana de 25 a 31 de março de 2026 marcou um ponto de virada na segurança da cadeia de suprimentos cloud-native. Em nove dias, o grupo de ameaças TeamPCP (também rastreado como PCPcat, ShellForce e CipherForce) transformou quatro ferramentas confiáveis do ecossistema DevSecOps em máquinas de coleta de credenciais, visando chaves AWS IAM, service accounts GCP e segredos Kubernetes de milhares de pipelines corporativos. O ataque começou com código malicioso forçado em 76 das 77 tags de versão do scanner de containers Trivy da Aqua Security, explorando um workflow GitHub Actions não sanitizado para coletar credenciais. Usando essas credenciais roubadas, o TeamPCP comprometeu sequencialmente as extensões IDE Checkmarx KICS, o pacote proxy de IA LiteLLM (~480M downloads PyPI) e o SDK Python Telnyx. Uma carga de roubo de credenciais rastreada como CVE-2026-33634 (CVSS 9.4) foi construída propositalmente para exfiltrar chaves AWS IAM, credenciais de service accounts GCP, variáveis de ambiente Azure e segredos Kubernetes. Em 30 de março, o TeamPCP pausou novos comprometimentos da cadeia de suprimentos e anunciou uma parceria ransomware com a nova operação Vect RaaS.
Axios npm Hijack: Ataque de Cadeia de Suprimentos de Alto Impacto
Um atacante desconhecido comprometeu as contas GitHub e npm do desenvolvedor principal do Axios, uma biblioteca HTTP client amplamente utilizada, e publicou pacotes npm backdoorados com uma dependência maliciosa que acionava a instalação de droppers e remote access trojans. As versões maliciosas ([email protected] e [email protected]) ficaram ativas por aproximadamente três horas antes da remoção em 31 de março. Em 1º de abril de 2026, o Google Threat Intelligence Group atribuiu publicamente o comprometimento ao UNC1069, um ator de ameaças motivado financeiramente com conexão norte-coreana, com base em sobreposições de infraestrutura e uso do WAVESHAPER.V2 – um backdoor atualizado vinculado à atividade anterior do grupo. Embora as versões maliciosas tenham sido removidas em horas, a presença do Axios em aproximadamente 80% dos ambientes cloud e de código permitiu exposição rápida, com execução observada em 3% dos ambientes afetados de acordo com pesquisadores da Wiz.
Vulnerabilidade Vertex AI “Double Agent”: Permissões Perigosamente Amplas
A Palo Alto Networks Unit 42 divulgou uma “blind spot” estrutural na plataforma Vertex AI do Google Cloud: o Per-Project, Per-Product Service Agent (P4SA) associado a agentes de IA implantados via Agent Development Kit (ADK) carrega permissões perigosamente amplas por padrão. Um atacante pode criar um agente de IA malicioso como um arquivo Python pickle serializado, implantá-lo no Reasoning Engine do Vertex AI, consultar o serviço de metadados do Google para extrair credenciais P4SA, então escapar do ambiente isolado do agente e operar como uma service account altamente privilegiada, obtendo acesso de leitura irrestrito a todos os buckets GCS e repositórios Artifact Registry restritos no projeto. O Google abordou o problema revisando sua documentação e agora recomenda fortemente uma arquitetura Bring Your Own Service Account (BYOSA) para todas as implantações Vertex AI.
O Modelo AppSec Quebrado na Era da IA
Como observado por Joe Sullivan, ex-CSO da Cloudflare, Facebook e Uber, e Scott Gerlach, co-fundador e CSO da StackHawk, os programas AppSec construídos antes de 2026 estão estruturalmente insuficientes para a velocidade e escala em que o código está sendo produzido. O volume de código enviado para segurança está aumentando 10x, e infelizmente o volume de vulnerabilidades também está aumentando 10x. Se as equipes de segurança não tiverem cuidado, estarão devolvendo 10x o volume de problemas, e já estavam em apuros por devolver muito.
Scott Gerlach destaca que se uma equipe ainda está criando tickets, provavelmente não é madura o suficiente. Tickets são um canal de comunicação em lote e assíncrono, enquanto ataques de cadeia de suprimentos, zero-days explorados e vulnerabilidades geradas por IA operam em tempo real e contínuo. A incompatibilidade não é recuperável através de melhor priorização de tickets – requer uma arquitetura de teste fundamentalmente diferente.
DAST Legacy vs. Modern: A Arquitetura que Define o Raio de Impacto
A distinção entre DAST legacy e moderno é um dos frameworks mais praticamente acionáveis. DAST legacy testa aplicações de produção conhecidas e públicas de fora do perímetro da rede, através de WAFs e CDNs que geram sinais falsos. O resultado: taxas de 90% de falsos positivos, cobertura esparsa e descobertas que chegam tarde demais. DAST moderno executa 5-10 vezes por dia, testa cada microserviço e API conforme ele se move pelo pipeline CI/CD, executa dentro do ambiente de desenvolvimento e entrega descobertas diretamente ao desenvolvedor que introduziu a mudança no momento em que ele pode realmente corrigi-la.
Organizações com testes de segurança incorporados dentro de seus pipelines CI/CD têm oportunidades de detecção para ferramentas comprometidas que a varredura legacy de fora da produção simplesmente não pode fornecer.
Agentes de IA no Loop de Desenvolvimento: Identidade e Modelo de Segurança
Gerlach descreve o estado agêntico ideal: Claude Code ou Cursor, após escrever um novo recurso, aciona automaticamente uma varredura DAST contra a aplicação em execução, consome as descobertas e corrige todas elas dentro do mesmo loop do agente, antes mesmo que um humano revise o PR. Mas Sullivan imediatamente destaca o contrapeso que mapeia precisamente a vulnerabilidade Vertex AI “Double Agent”: empresas dirão que deixaram a IA rodar por um ano e queimaram centenas de milhares, senão milhões de dólares em tokens, questionando se podem voltar para uma solução de software determinística.
Gerlach captura o risco do modelo de identidade: ao implantar agentes de IA, é crucial pensar sobre o modelo de identidade e o modelo de segurança que ele herda, limitando o acesso e considerando a escala empresarial.
A Expansão do Mandato do CISO: Líder da Transformação de IA
Em 2026, o CEO está se voltando para TI e dizendo: “Quero que você lidere a transformação de IA para a empresa”. E essa pessoa também é o líder de segurança. Portanto, temos mais responsabilidade e mais interação com o CEO, e isso não vai retroceder. Para profissionais de segurança cloud, a implicação não é abstrata: se seu CEO está pedindo ao chefe de segurança para ser o líder de governança e transformação de IA, as habilidades que você investiu em proteger infraestrutura cloud-native precisam se estender para governar sistemas não determinísticos e agênticos que, como demonstra a pesquisa Vertex AI, podem se tornar ameaças internas quando mal configurados.
Takeaways Práticos para Líderes de Segurança Cloud
- Incorpore AppSec no loop de engenharia, não depois dele: Se sua equipe ainda está recebendo código e gerando tickets, você está operando AppSec legacy. Inicie conversas com engenharia sobre onde os testes de segurança podem ser executados dentro do pipeline CI/CD.
- Mude da tolerância a falsos positivos para precisão de verdadeiros positivos: Uma taxa de 90% de falsos positivos é um problema de arquitetura de teste, não de sinal. Teste dentro do ambiente de desenvolvimento para eliminar interferência de WAF e CDN.
- Trate agentes de IA como identidades de serviço, não aplicações: Aplique seu framework de governança IAM a cada carga de trabalho agêntica antes da implantação em produção. Permissões padrão são quase sempre muito amplas. BYOSA no Vertex AI; service accounts com escopo definido em todos os outros lugares.
- Audite suas suposições de cadeia de suprimentos CI/CD hoje: Fixe GitHub Actions para full commit SHAs, não tags flutuantes. Assuma que qualquer runner que executou Trivy, LiteLLM, Telnyx ou Axios entre 19-31 de março está comprometido até prova em contrário.
- Posicione segurança como um habilitador de negócios para transformação de IA: CISOs que abordam IA puramente como um exercício de gerenciamento de risco serão marginalizados. Aqueles que ajudam equipes de engenharia a enviar recursos de IA com segurança e velocidade possuirão um dos mandatos mais importantes em sua organização.
Análise baseada no Cloud Security Newsletter (01/04/2026). Pesquisa e adaptação: N00TROP1C — NULLTROPIC, 2026.
Deixe um comentário