Em 2026, os mecanismos de confiança que construímos para proteger a cadeia de software — SLSA provenance, code signing, CI/CD — se tornaram os vetores de ataque. Na Tech86, acompanhamos essa inversão em tempo real: cada novo padrão de segurança que a indústria adotou foi absorvido como superfície pelos atacantes. O resultado foi uma cadeia de comprometimentos que em semanas atingiu OpenAI, Mistral AI, Grafana Labs, Microsoft e o próprio GitHub.
O ano em que a proveniência enganou todo mundo
Em 11 de maio de 2026, o Mini Shai-Hulud publicou 84 versões maliciosas em 42 pacotes @tanstack/* em 6 minutos. Todas com assinatura digital válida. Todas com proveniência SLSA Build Level 3. O CVE-2026-45321 recebeu CVSS 9.6 — e o mais alarmante é que a infraestrutura de confiança funcionou exatamente como projetada.
O atacante encadeou três vulnerabilidades conhecidas: um pull_request_target que executava código de fork externo com acesso ao CI do repositório base, cache poisoning cross-boundary que envenenou o pnpm store sob a chave exata do release workflow, e extração do token OIDC da memória do runner via dump de /proc/PID/mem. O step oficial de publish nunca executou — a publicação maliciosa já tinha acontecido usando o token legítimo.
O Sigstore, Fulcio CA e Rekor log confirmaram tudo. A atestação SLSA registra corretamente que o pacote foi publicado por release.yml@refs/heads/main em TanStack/router. O que ela não codifica é qual step do workflow rodou npm publish. Proveniência não é segurança. É procedência. O pacote veio de onde diz que veio, mas o que estava dentro era malware.
A cadeia que ninguém viu se formando
O TanStack não foi um incidente isolado. Foi o ponto zero. Em horas, o worm se auto-propagou para 170+ pacotes em 19 namespaces incluindo Mistral AI SDK, UiPath, OpenSearch e Guardrails AI. Com as credenciais roubadas de um mantenedor do Nx Console, o TeamPCP publicou a versão 18.95.0 da extensão Nx Console no VS Code Marketplace. Janela de exposição: 18 minutos. Downloads oficiais: 28.
Um dos devs com atualização automática ativada trabalhava no GitHub. Com os tokens roubados, o atacante enumerou e clonou 3.800 repositórios internos. Código proprietário. Scripts de deploy. Configs de infra. Schemas de API interna. GitHub confirmou: "As alegações atuais do atacante sobre ~3.800 repositórios são direcionalmente consistentes com nossa investigação." O atacante listou os dados no Breached forum por US$ 50 mil, depois US$ 95 mil com suposto partnership com Lapsus$.
A mesma cadeia derrubou a Grafana. Rotacionaram tokens em massa, mas esqueceram um. O CISO confirmou: "Um token esquecido permitiu que os atacantes obtivessem acesso aos nossos repositórios GitHub." Codebase privada roubada. Resgate exigido. Grafana recusou, citando FBI. A Microsoft foi atingida no mesmo dia — durabletask, SDK oficial, com 417 mil downloads/mês. Nove dias, cinco empresas de ponta, uma cadeia.
Quando as ferramentas que leem código se tornam o ataque
A superfície de ataque mudou de forma fundamental. Não é mais só o código. São as ferramentas que leem o código. O malware dos ataques de 2026 grava persistência em dois lugares: .claude/settings.json via hook SessionStart do Claude Code, e .vscode/tasks.json via diretiva folderOpen. Toda vez que um desenvolvedor abre o repositório, o malware executa. Sem prompt. Sem aprovação.
Os commits são autorizados como [email protected] com mensagem "chore: update dependencies" — indistinguível de atividade normal de IA. Desinstalar o módulo não remove o malware. Ele persiste nas configurações da IDE e do agente de IA. Quem clona o repositório herda a infecção. No caso do Nx Console, o atacante instalou gh-token-monitor via systemd/launchctl que monitora o token a cada 60 segundos. Se detecta revogação, dispara recursive file deletion. A ordem de remediação importa: remover persistência ANTES de revogar tokens. Inverter é catastrófico.
O worm se auto-propaga entre ecossistemas. Token npm com permissão de publish? O malware enumera pacotes da vítima, injeta o payload, republica com versão incrementada. Credenciais PyPI no ambiente? Pula para Python. É o primeiro worm documentado que cruza de NPM para PyPI. Em CI runners, lê /proc//mem do GitHub Actions para extrair secrets da memória do runner, bypassando toda máscara de logs.
O ataque que não toca no código-fonte
Em 22 de maio, o Laravel Lang — pacote de localização com 7.800 estrelas — teve todas as suas 502 tags reescritas para apontar a commits em forks controlados pelo atacante. ~700 versões envenenadas. O código executava em todo request PHP sem ninguém perceber. A causa raiz: um PAT de membro da organização, provavelmente do leak do GitHub — o mesmo incidente dos 3.800 repos via Nx Console.
A técnica é elegante e difícil de detectar. O atacante não modificou o código-fonte oficial. Nenhum commit no repositório legítimo. Explorou uma feature do GitHub: tags podem apontar para commits em forks, e o Packagist resolve essas tags como releases legítimas. composer install baixava código do fork. Parecia legítimo. Não era.
O payload usa autoload.files do Composer — todo arquivo nessa lista roda em cada request PHP. Commands, workers, queues, cron — tudo executa o helpers.php. O C2 domain é construído em runtime via array_map('chr', [...]) para evadir static scanners. O stealer tem ~5.900 linhas de PHP, 15 módulos, é cross-platform. Rouba cloud keys via metadata 169.254.169.254, Kubernetes kubeconfig, Vault tokens, SSH keys, .env, docker-compose.yml, secrets.yaml, browser data, password managers, crypto wallets. No Windows, DebugChromium.exe rouba App-Bound Encryption keys do Chrome/Brave/Edge. Tudo criptografado com AES-256 e exfiltrado. Auto-deleta depois.
Pipelines: o novo alvo de escala
Em 18 de maio, o Megalodon comprometeu 5.561 repositórios GitHub com 5.718 commits maliciosos em 6 horas. Nenhum código de aplicação foi modificado. O alvo era exclusivamente a camada de CI/CD — os workflows que rodam dentro de cada repo.
Credenciais comprometidas — 33% dos usernames encontrados em logs de infostealers segundo análise de threat intelligence — para pushar commits diretos via PAT. Identidades forjadas: build-bot, ci-bot, auto-ci com emails como [email protected]. Commit message: "ci: add build optimization step". Conteúdo: YAML em .github/workflows/. Nenhum PR. Push direto para master.
Duas variantes. SysDiag: execução em massa com trigger em push + pull_request_target, que roda com secrets do repo base mesmo quando o PR vem de fork externo. Optimize-Build: backdoor dormente que substitui workflows por versões com workflow_dispatch, ativável via GitHub API. Zero builds falhando. Zero logs suspeitos. Ambos pedem id-token: write — a permissão que permite solicitar OIDC tokens para impersonar identidades em AWS, GCP e Azure sem credenciais persistentes.
O caso Tiledesk ilustra o problema: o mantenedor publicou versões 2.18.6–2.18.12 no npm sem saber que o repo estava comprometido. O backdoor estava na camada de CI/CD — invisível para code review e scanners que analisam apenas código-fonte. O atacante nunca tocou a conta npm. Comprometeu o repositório. O mantenedor publicou da fonte envenenada.
O que muda a partir de agora
Na Tech86, a lição que tiramos de 2026 é clara: a defesa perimetral tradicional não alcança a cadeia de supply chain. WAF bloqueia tráfego malicioso na borda, mas não intercepta um npm install que executa código com permissões de CI. É por isso que combinamos Blindagem Perímetro WAF com monitoramento de integridade de pipelines — porque o ataque de hoje entra pelo pipeline, não pela porta da frente.
SLSA provenance precisa evoluir para codificar qual step executou qual ação, não apenas qual workflow. Cache de CI/CD precisa segregação obrigatória entre jobs de PR e jobs de release. Permissões de OIDC e id-token precisam de restrição explícita por job e por ambiente. E a indústria precisa aceitar que proveniência e segurança são problemas diferentes. Enquanto tratamos atestação de origem como garantia de segurança, atacantes continuarão usando nossa própria infraestrutura de confiança contra nós.