Existe um número que deveria estar em toda reunião de diretoria que fala sobre segurança em 2026: 46%. Quase metade das organizações já perdeu receita ou clientes por causa de um incidente envolvendo containers ou Kubernetes, segundo levantamento da Red Hat. Não é um susto teórico sobre o que poderia acontecer — é dinheiro que já saiu do caixa, contrato que já foi cancelado, cliente que já foi embora. E o detalhe mais incômodo é onde o ataque entrou: não pela porta da frente que todo mundo blindou, mas por uma porta dos fundos que a maioria nem sabe que deixou aberta.
Durante anos, segurança de aplicação foi sinônimo de proteger a borda: firewall, WAF, certificado, proteção contra ataques no site público. Esse trabalho continua necessário — mas deixou de ser suficiente. A superfície de ataque migrou para dentro: para o cluster Kubernetes onde a aplicação roda e para o pipeline de CI/CD que a coloca no ar. Misconfigurações de GitHub Actions estão por trás de alguns dos maiores ataques de supply chain de software de 2025 e 2026, e vulnerabilidades críticas em ferramentas do ecossistema — como o CVE-2026-33634 no Trivy, com pontuação CVSS de 9.4 — reforçam que o pipeline virou alvo. Este artigo mostra por que a borda não basta mais, quais são as três portas mais comumente deixadas abertas, e o que auditar para fechar a brecha que você talvez nem saiba que tem.
O dado que assusta: 46% perderam receita por incidente de container
O valor da Red Hat merece ser lido com atenção porque ele muda a natureza da conversa. Segurança de container e Kubernetes costumava ser tratada como assunto técnico, de interesse exclusivo do time de infraestrutura — uma preocupação de engenheiro, não de negócio. O dado de 46% destrói essa separação. Quando quase metade das empresas relata impacto direto em receita ou na base de clientes, isso deixou de ser risco operacional abstrato e virou risco de negócio concreto, com linha no balanço.
O motivo de o impacto ser tão material é a posição que o Kubernetes ocupa na arquitetura moderna. Ele não é uma ferramenta periférica — é a camada onde a aplicação inteira vive, onde os dados transitam, onde as credenciais de acesso a banco, APIs e serviços externos estão guardadas. Comprometer o cluster não é comprometer um pedaço do sistema; é, muitas vezes, comprometer tudo de uma vez. Um invasor que ganha acesso ao cluster pode acessar dados de clientes, alterar a aplicação em produção, ou usar a infraestrutura para outros fins — e o estrago se converte rapidamente em perda de receita e de confiança.
Por que a borda não basta mais (cluster + pipeline)
Imagine uma empresa que investiu pesado em segurança de perímetro. WAF de última geração, firewall robusto, proteção contra os ataques clássicos ao site público. Pela ótica tradicional, ela está protegida. Mas o ataque moderno não bate de frente nessa parede — ele entra por onde a parede não cobre. E há duas zonas que a borda simplesmente não enxerga.
A primeira é o cluster Kubernetes. Dentro dele, o tráfego entre serviços muitas vezes flui sem a mesma vigilância aplicada à borda. Permissões generosas, comunicação interna sem restrição, segredos acessíveis a quem não deveria. Um invasor que consegue um ponto de apoio — através de uma dependência comprometida, por exemplo — encontra um ambiente onde mover-se lateralmente é fácil, justamente porque o controle estava todo voltado para fora.
A segunda é o pipeline de CI/CD. Aqui está talvez a mudança mais importante e menos compreendida dos últimos anos. O pipeline tem acesso privilegiado a tudo: ao código-fonte, aos segredos de produção, à capacidade de fazer deploy. Comprometer o pipeline é comprometer a própria fábrica de software. Os ataques de supply chain que dominaram as manchetes recentes exploraram exatamente isso — misconfigurações em GitHub Actions, fluxos de automação com permissões largas demais, dependências que ninguém auditou. O atacante não invade a aplicação pronta; ele envenena a esteira que produz a aplicação, e o código malicioso entra pela porta da frente, devidamente assinado e aprovado.
As 3 portas mais abertas: RBAC largo, secrets expostos, imagens sem scan
Na prática, a maioria dos incidentes de cluster e pipeline explora um de três descuidos recorrentes — e os três são corrigíveis.
RBAC largo demais. O controle de acesso baseado em papéis (RBAC) do Kubernetes existe para garantir que cada componente tenha apenas as permissões de que precisa. Na prática, sob a pressão de "fazer funcionar", muitos clusters acabam com papéis amplos demais — contas de serviço com permissões de administrador, acessos que ninguém revisou desde a configuração inicial. Cada permissão excessiva é um caminho a mais para um invasor escalar privilégios. O princípio do menor privilégio existe há décadas; o que muda é que no cluster ele costuma ser ignorado.
Segredos expostos. Senhas, tokens de API, chaves de criptografia — os segredos que dão acesso a tudo. Quando ficam em texto puro em arquivos de configuração, em variáveis de ambiente sem proteção, ou versionados acidentalmente no repositório, transformam um pequeno vazamento em comprometimento total. Gestão adequada de segredos, com cofre dedicado e criptografia, é básica — e frequentemente ausente.
Imagens sem scan. Toda aplicação em container é construída sobre imagens-base e dezenas de dependências. Se essas imagens não passam por verificação automática de vulnerabilidades, você está rodando em produção código de terceiros que ninguém auditou — incluindo, possivelmente, vulnerabilidades conhecidas com correção já disponível. O scan automático de imagens no pipeline é a malha que pega esse risco antes que ele chegue ao cluster.
Supply chain: o caso GitHub Actions e o CVE do Trivy
Vale aprofundar a ameaça de supply chain, porque é a que mais cresceu e a menos compreendida. Em um ataque tradicional, o alvo é a sua aplicação. Em um ataque de supply chain, o alvo é algo de que a sua aplicação depende — uma biblioteca, uma ação de automação, uma imagem-base. Comprometendo esse elo, o atacante alcança todos que dependem dele, de uma vez. É um multiplicador de força, e por isso virou a tática preferida dos ataques de maior impacto.
As misconfigurações de GitHub Actions são o exemplo perfeito. Fluxos de automação que executam código de fontes não confiáveis, que têm permissões de escrita amplas, ou que expõem segredos em logs, viram a porta de entrada. O atacante não precisa invadir o seu servidor — ele contribui com um código aparentemente legítimo que o seu próprio pipeline executa com privilégios. E a ironia do CVE-2026-33634 no Trivy, uma ferramenta de scan de segurança com CVSS 9.4, é didática: até as ferramentas que usamos para nos proteger são software, e software tem vulnerabilidades. Segurança de supply chain não é configurar uma ferramenta uma vez — é um processo contínuo de verificar dependências, restringir permissões e manter tudo atualizado.
Checklist de hardening: cluster, CI/CD e observabilidade de segurança
O que auditar nesta semana, sem precisar de um projeto de seis meses para começar. No cluster: revise o RBAC e elimine permissões amplas que ninguém usa; tire todo segredo de texto puro e mova para um cofre com criptografia; ative scan automático de imagens e bloqueie deploy de imagens com vulnerabilidade crítica conhecida; aplique segmentação de rede para que serviços só conversem com quem precisam. No pipeline: restrinja as permissões de cada fluxo de automação ao mínimo; audite as dependências de terceiros e fixe versões; garanta que segredos nunca apareçam em logs; exija revisão para mudanças nos próprios arquivos de pipeline.
E acima de tudo: instrumente segurança com observabilidade. Você não consegue responder a um incidente que não consegue ver. Logs de acesso ao cluster, alertas para mudanças de permissão, monitoramento de comportamento anômalo — sem isso, um comprometimento pode durar semanas até ser notado, e é justamente essa demora que converte um incidente contornável em perda de receita.
Como a CCX ajuda
A maioria das empresas não perde dados por falta de WAF — perde porque o cluster e o pipeline ficaram para depois. É exatamente esse ponto cego que a CCX cobre com Security Engineering & Cybersecurity: pentest, hardening de Kubernetes, gestão de identidade e segredos com cofre (Vault), WAF, e proteção em cada camada com security by design — incluindo o scan de supply chain e a auditoria do pipeline de CI/CD que os ataques recentes exploraram.
Isso se combina com as práticas de DevOps & CI/CD e Arquitetura Cloud da CCX — pipelines seguros, infraestrutura como código (Terraform) e cluster endurecido — fechando a brecha de ponta a ponta, da esteira de build ao ambiente de produção, com observabilidade de segurança (OpenTelemetry, SIEM) para detectar o anômalo antes que ele vire incidente. Não dá para proteger só a borda quando o ataque mora no cluster.
Seu WAF protege a borda — mas e o cluster? A CCX faz hardening de Kubernetes, scan de supply chain e pentest de pipeline. Consultoria tech →