Achados soltos
Os problemas de segurança apareciam por acaso, como efeito colateral de outros trabalhos: um token encontrado aqui, um banco desatualizado ali, uma ferramenta exposta acolá. Não havia uma visão única da superfície de ataque, e cada achado ficava sem dono, sem severidade e sem plano.
Propus uma varredura com método, e com uma regra que eu não quebraria: não tocar em nada.
Olhar sem mexer
Analisei os clusters Kubernetes de produção em sete frentes: versões frente às datas de fim de suporte, exposição de rede, permissões, segredos, configuração dos workloads, acesso aos bancos e painéis administrativos expostos.
Tudo foi feito em modo somente leitura. Nenhuma credencial encontrada foi usada, e nada foi alterado durante a análise. Para dizer que algo estava "aberto para a internet", testei a partir de uma conexão comum, sem VPN, para não confundir com "aberto para quem está na rede interna". Quando encontrei a mesma senha servindo a vários sistemas, provei o reuso comparando hashes, sem que o relatório contivesse um único segredo. E cada achado foi registrado com o comando e o valor observado.
Num segundo produto, ampliei a análise com uma revisão estática de 14 repositórios contra o OWASP Top 10 de 2025 e uma checagem externa passiva dos hosts públicos.
O que apareceu
A primeira varredura teve 13 achados: dois críticos, quatro altos, cinco médios e dois baixos. Havia credenciais em texto claro em ConfigMaps, com a mesma senha reaproveitada em vários bancos, de modo que um único vazamento abriria a produção e o backup ao mesmo tempo. Havia tokens de acesso ao Git em texto claro na configuração do GitOps, também presentes no histórico do repositório. Havia bancos e painéis alcançáveis pela internet sem restrição de origem, versões de Kubernetes e de sistema operacional fora de suporte, permissões amplas demais e uma CVE crítica, com CVSS 9,8, num componente de borda que o próprio projeto já tinha descontinuado. No CI, ações de terceiros eram referenciadas por branch e rodavam com credenciais de produção no ambiente.
No relatório do segundo produto, separei 16 ações para o time de DevOps e 12 sugestões para o time de desenvolvimento, para cada lado saber exatamente o que era seu.
A ordem importa
Cada achado crítico virou um card próprio, com ações em ordem de risco, critérios de aceite e plano de reversão. Muitas vezes, a ordem certa era a parte mais importante. Rotacionar uma credencial tem que vir antes de limpar o histórico do Git, porque reescrever o histórico sem revogar a chave não adianta: o valor já vazou. Na API do Kubernetes, primeiro entram na regra os IPs da VPN e da rede interna, e só depois sai a regra aberta, com aviso ao time que usa kubectl. E políticas de segurança de pods começam em modo de aviso e auditoria antes de bloquear qualquer coisa.
As primeiras correções
Removi o vínculo de administrador do cluster ligado a um usuário individual em dois clusters, depois de confirmar que a pessoa mantinha o acesso pelo grupo do IAM e de guardar uma cópia do objeto. Comecei a migrar as credenciais de ConfigMap para Secret, reduzindo as cópias da senha mestra, sem nenhum impacto em produção: nenhum container reiniciado e nenhum evento de erro. E desenhei a mitigação da CVE crítica do ingress, com um passo imediato e reversível e a migração para outro controlador, host por host.
O que mudou
A segurança da infraestrutura passou de achados soltos para um inventário único, com severidade, evidência e dono. Os itens críticos viraram cards com plano de execução e de reversão, e as primeiras correções entraram sem nenhum impacto em produção.
O que eu levo disso
Uma análise de segurança só serve se for segura e acionável. Segura: somente leitura, sem usar credenciais encontradas e sem segredo no relatório. Acionável: cada achado com evidência, severidade, dono e a ordem certa de correção. Em segurança, fazer a coisa certa na ordem errada causa o problema que se queria evitar.