Esta semana em cloud (21–27/set): o pipeline virou o perímetro

TL;DR — A Mandiant descreveu como atacantes miram scanners, IDEs e o próprio pipeline — cache envenenado, token OIDC extraído, tag de action redirecionada — e propôs cooldown de sete dias para dependências. O Google levou o Code Owners do Secure Source Manager a GA. Duas GitHub Actions comprometidas em maio voltaram a executar malware em setembro sem novo ataque. O recado da semana: quem tem permissão de publicar é o seu perímetro.

A semana passada foi sobre o caminho até a GPU. Esta foi sobre o caminho até a produção — e sobre quem mais está andando por ele.

Não houve um incidente único que parasse o mercado. Houve uma sequência de textos, de organizações diferentes, descrevendo o mesmo deslocamento: o ataque saiu da aplicação publicada e foi para a esteira que a publica. A Mandiant, braço de threat intelligence do Google, publicou um blueprint de endurecimento de pipelines de código e infraestrutura de CI/CD. O Google levou a disponibilidade geral duas capacidades do Secure Source Manager voltadas justamente para quem aprova e quem acessa o pipeline. A Aviatrix documentou duas GitHub Actions comprometidas em maio que voltaram a executar malware em setembro sem nenhum ataque novo. E a CNCF, com a OpenSSF, abriu o Security Slam de outono com uma métrica voltada para a Cyber Resilience Act europeia.

Quem opera infraestrutura conhece o desconforto: o pipeline é o sistema com mais permissão da empresa e o que menos passa por revisão de acesso.

Por que o pipeline virou o alvo preferido?

Porque ele concentra, num lugar só, o que o atacante quer: credencial de nuvem, chave de assinatura e o direito de publicar em nome de alguém confiável.

O texto da Mandiant organiza as campanhas recentes em três táticas. A primeira mira ferramentas que o time já considera seguras — scanners de segurança, bibliotecas utilitárias e ferramentas de IA para desenvolvedores —, exatamente porque recebem permissão elevada dentro do build. A segunda ataca a estação do desenvolvedor, com engenharia social personalizada, extensão maliciosa de IDE ou dependência com typosquatting, para levar chave privada, token de API e sessão ativa. A terceira é a mais sofisticada: manipulação do próprio pipeline, com envenenamento de cache do GitHub Actions, extração de tokens OIDC e redirecionamento de tags mutáveis de actions para publicar pacotes comprometidos que ainda carregam proveniência criptográfica legítima.

Esse último ponto é o que mais incomoda. Assinatura e proveniência provam de onde o artefato saiu, não o que estava no build. Se o atacante controla o que roda dentro do workflow legítimo, a assinatura sai perfeita.

O Google trouxe o número que dá escala ao problema: citando o relatório Cloud Threat Highlights da Wiz, os ataques notáveis à supply chain mais que dobraram no primeiro semestre de 2026 em relação ao segundo semestre de 2025. E o texto da Mandiant registra um vetor que não existia há dois anos: pacotes abertos do Model Context Protocol carregando código malicioso para enganar agentes de codificação. O agente que escreve código com as suas credenciais virou mais uma identidade privilegiada dentro da esteira.

O que a volta das actions comprometidas ensina?

Que remover o atacante não é o mesmo que remover o que ele deixou.

Segundo a Aviatrix, as actions actions-cool/issues-helper e actions-cool/maintain-one-comment foram comprometidas em 18 de maio, com código de coleta de credenciais injetado a partir da tag v2.2.1. Os repositórios foram reativados em 16 de setembro e, de acordo com a análise publicada em 25/09, os workflows que referenciavam essas tags voltaram a baixar e executar o payload automaticamente, enviando chaves de API e tokens para servidores do atacante. Nenhuma invasão nova foi necessária: bastou o pipeline de alguém rodar de novo.

É o caso de manual para duas recomendações do blueprint da Mandiant:

Referência por SHA, não por tag. Tag de imagem e tag de action são nomes que alguém pode reapontar. Um hash de commit completo ou um digest de imagem é conteúdo: se o conteúdo muda, a referência quebra em vez de entregar outra coisa. E isso vale para toda imagem que o build toca — base, sidecar, init container —, não só para a imagem principal.
Cooldown de dependências. A proposta é exigir sete dias de idade mínima antes de uma versão nova de pacote público ficar instalável, porque a comunidade costuma detectar e retirar releases envenenados nesse intervalo. No npm, o parâmetro minimumReleaseAge resolve; em Python, o índice interno faz o papel.

Quem fixou as duas actions no hash de um commit anterior à tag comprometida não executou o payload em maio nem em setembro. Quem seguia a tag executou — e, na segunda vez, sem que ninguém tivesse feito nada.

Quem pode aprovar o que muda o pipeline?

Esta é a pergunta que o Secure Source Manager tentou responder, e ela vale para qualquer forja.

As duas capacidades que chegaram a GA atacam problemas distintos. A primeira é o bloqueio de acesso não autorizado ao CI/CD mesmo com a rede corporativa comprometida: o repositório, os pools de build e os artefatos ficam em rede privada, ligados por Private Service Connect e pela integração com o Developer Connect, com o VPC Service Controls como camada extra. A segunda é o Code Owners, que troca o papel genérico de "aprovador" por aprovação obrigatória por caminho de arquivo, com regras diferentes por branch, arquivos CODEOWNERS aninhados em que a regra mais local prevalece e seções independentes — um pull request pode exigir, por exemplo, duas aprovações do time de segurança além da revisão do par.

O detalhe que importa para quem não usa o produto do Google: o arquivo que define o pipeline é código de produção. Um .gitlab-ci.yml ou um workflow do GitHub alterado pode exfiltrar tudo o que o job enxerga. Colocar os diretórios de CI, os módulos de IaC e os manifests de deploy sob dono obrigatório é um controle que o GitHub e o Forgejo já oferecem sem custo extra — no GitLab, a aprovação obrigatória por Code Owners fica nos planos pagos, e a alternativa é regra de aprovação por branch protegida. O que falta, em geral, é alguém decidir usar.

A mesma lógica aparece na lista de menor privilégio da Mandiant, que resumimos na tabela abaixo por camada.

Camada	Vetor descrito nesta semana	Controle	Custa licença?
Estação do desenvolvedor	Extensão maliciosa, typosquatting, roubo de PAT e chave SSH	Allowlist de extensões, ambiente de desenvolvimento em container ou VM, chave SSH em hardware FIDO2	Não
Repositório	Push direto, force-push, aprovação genérica	Branch protegida sem bypass, `CODEOWNERS` nos diretórios de CI e IaC	Não (no GitLab, Code Owners obrigatório exige plano pago)
Dependências e artefatos	Tag reapontada, pacote envenenado recém-publicado	Pin por SHA/digest, cooldown de 7 dias, proxy interno com quarentena	Não
Runner e pipeline	Cache envenenado, token OIDC extraído, segredo persistente	Runner efêmero, cache isolado por branch, OIDC com token curto, permissão nula por padrão, `ignore-scripts=true`	Não
Produção	Imagem sem assinatura, credencial administrativa permanente	Admission que recusa imagem não assinada, acesso just-in-time	Não

A última coluna não é retórica. Com a exceção indicada, os controles da tabela existem nas forjas e nos registries de comunidade; a diferença entre quem está protegido e quem não está é configuração e disciplina.

Seu pipeline tem mais permissão do que o seu time de produção? A Nuvem Online revisa a esteira de CI/CD camada por camada e fecha os vetores sem trocar de ferramenta.

O que isso significa para quem opera infra no Brasil?

Três consequências práticas, em ordem de urgência.

1. Faça o inventário de referências mutáveis esta semana. Um grep por uses: sem hash de 40 caracteres nos workflows e por image: sem @sha256: nos manifests e pipelines mostra o tamanho da exposição em minutos. Troque pelas referências fixas e deixe um bot de dependências abrir os pull requests de atualização, respeitando o cooldown. É o controle com a melhor relação entre esforço e risco evitado de toda a lista — e é o que teria neutralizado o caso das actions reativadas.

2. O segredo mais perigoso da empresa provavelmente mora numa variável de CI. Token de registry de longa duração, chave de nuvem com escopo amplo, chave de assinatura de release: a Mandiant aponta o token de publicação estático como causa raiz recorrente de incidentes de supply chain. A troca é por federação OIDC com token curto, emitido para o workflow específico no momento do release, e por permissão somente leitura por padrão nos jobs. E a chave de assinatura que não puder virar keyless precisa de dono, de rotação documentada e de um runbook de revogação escrito antes do incidente — não durante. A identidade de quem opera o pipeline também entra aqui: a Oracle liberou no OCI IAM as discoverable credentials FIDO2, login com passkey sem digitar usuário, e a própria Mandiant recomenda chave de hardware no lugar de PAT. O desenho de um IdP de comunidade com passkeys obrigatórias para contas privilegiadas é o mesmo que detalhamos no guia de IAM unificado sem lock-in com Keycloak.

3. A CRA chega ao Brasil pelo contrato, não pelo Diário Oficial. A Cyber Resilience Act vale para quem coloca produto com componente digital no mercado europeu, onde quer que esteja sediado — e os requisitos de SBOM, gestão de vulnerabilidades e atualização segura tendem a descer pela cadeia como cláusula de fornecedor. O Security Slam, organizado pela OpenSSF e pelo TAG Security da CNCF, roda de 5 de outubro a 6 de novembro, aceita pela primeira vez qualquer projeto open source e estreia uma métrica voltada para a CRA. Se a sua empresa mantém um projeto aberto, é um ensaio gratuito. Se só consome, é um bom momento para gerar o SBOM do seu build em CycloneDX ou SPDX e descobrir o que realmente está dentro dele.

Um aviso honesto sobre a lista: a própria Oracle publicou, na mesma semana, um texto sobre medir cobertura de detecção que separa aplicabilidade (o controle faz sentido para aquele serviço) de cobertura demonstrada (o controle foi implementado e testado). Vale para pipeline também. Branch protegida que tem administrador com bypass, ou pin por SHA que só existe no repositório principal, é cobertura declarada — não demonstrada.

O que mais aconteceu na semana

Fora do fio da supply chain, quatro movimentos merecem nota:

O Kubernetes aprendeu a desligar sem operador extra. O GKE 1.37 passou a escalar workloads a zero réplicas de forma nativa, com minReplicas: 0 no HPA e capacity buffers para a retomada, dispensando o KEDA em muitos cenários de batch, event-driven e ambiente de desenvolvimento. Na mesma leva, o HPA ganhou suporte a métricas Prometheus via PromQL sem adapter — em preview e ainda sem cobrir Prometheus self-hosted. E o GKE Pod Snapshots salva o estado de um pod, incluindo memória de CPU e GPU, para restaurar réplicas sem refazer o carregamento: até 89% menos tempo de startup em inferência, com modelo de 70B parâmetros subindo em 37 segundos e de 8B em 15. Para quem não está no GKE, o caminho de comunidade continua válido — comparamos as opções no guia de autoscaling com KEDA e HPA.
Capacidade ociosa virou opção para Spark. O Dataproc passou a provisionar nós em VMs flexíveis (Spot), com desconto que pode passar de 60% sobre o preço sob demanda e failover de tarefas para nós padrão quando há interrupção. A arquitetura sensata é híbrida: nós padrão para o que é crítico, flexíveis para o processamento que pode ser refeito — com checkpointing, senão a economia vira reprocessamento.
Observabilidade organizada por aplicação. A AWS lançou o CloudWatch Omni, que agrupa telemetria por aplicação em vez de por recurso, integra SSO corporativo e traz o Amazon DevOps Agent para investigação colaborativa, com uma trilha específica para workloads de IA generativa e agentes. E o EventBridge ganhou barramentos customizados aprimorados, compartilhados entre contas via AWS RAM, com garantia de ordenação e cobrança por throughput.
Cache e banco correram atrás da concorrência. O Memorystore for Valkey 9.1 anunciou até 3x mais QPS com latência de microssegundo, graças a filas lock-free e escalonamento dinâmico de threads de I/O. A Oracle contou como escalou o OCI Cache, também sobre Valkey, para terabytes de dados — com a lição de monitorar por shard e não pelo cluster. E o AlloyDB colocou em preview o PostgreSQL para agentes, com instâncias serverless isoladas lendo dado de produção em tempo real sem disputar recurso com o sistema transacional.

Perguntas Frequentes

Fixar GitHub Actions e imagens por SHA não vai travar as atualizações do meu time?
Vai deixar as atualizações explícitas, que é justamente o objetivo. Com a referência por hash de commit ou digest, nenhuma mudança upstream entra no seu build sem um commit seu. O custo operacional se resolve com um bot de dependências que abre pull requests atualizando os hashes, de preferência respeitando um período de cooldown. Você troca atualização silenciosa por atualização revisada — e é exatamente a atualização silenciosa que as campanhas recentes exploraram.

O cooldown de sete dias para dependências não atrasa correções de segurança urgentes?
Atrasa, e por isso ele precisa de uma válvula de exceção documentada. A lógica do cooldown é estatística: a maior parte dos pacotes maliciosos publicados em registries abertos é detectada e retirada pela comunidade em poucos dias, então esperar uma semana filtra boa parte deles sem esforço. Para um CVE crítico com exploração ativa, o processo deve permitir liberar a versão corrigida antes do prazo, com aprovação registrada de alguém de segurança. Regra sem exceção vira regra contornada.

Preciso me preocupar com a Cyber Resilience Act sendo uma empresa brasileira?
Se você vende software ou produto com componente digital para o mercado europeu, sim — a CRA recai sobre quem coloca o produto nesse mercado, independentemente de onde a empresa está sediada. Mesmo sem exportar, vale acompanhar: os requisitos de inventário de componentes, tratamento de vulnerabilidades e atualização segura tendem a virar exigência contratual de clientes grandes e referência para reguladores. O Security Slam, que começa em 5 de outubro com uma métrica voltada para a CRA, é um jeito barato de testar a maturidade de um projeto open source que você mantém.

Por onde começar a endurecer o CI/CD se o time é pequeno?
Pelos controles que custam configuração, não licença. Em ordem: trocar segredos estáticos do pipeline por federação OIDC com tokens de curta duração; fixar actions e imagens por SHA; dar permissão somente leitura por padrão aos jobs e liberar escrita só onde há publicação; separar o cache de build por branch e não aceitar escrita vinda de forks; e proteger a branch principal contra push direto e force-push. Esses cinco itens fecham os vetores que apareceram nas campanhas descritas nesta semana e não exigem comprar nenhuma ferramenta.

Fontes: