Shift Left fracassou: a segurança deve mover-se para baixo na pilha para conseguir velocidade sem sacrificar controle

Durante anos, repetimos um mantra: "mover a segurança para a esquerda" e pedir aos desenvolvedores que assumam mais responsabilidades de segurança enquanto escrevem e testam código. A ideia era sedutora: corrigir problemas cedo sai mais barato, e se as equipes de desenvolvimento incorporam verificações desde o início tudo vai mais rápido e mais seguro. No entanto, a realidade demonstra que essa aposta pelo "shift left" não resolveu o problema central. Em muitos ambientes, a tensão entre velocidade e segurança intensificou-se e, sobretudo, os desenvolvedores acabaram suportando uma carga cognitiva insustentável.

O problema não é a preguiça dos desenvolvedores; é o modelo de incentivos e a pressão para entregar rápido. Quando o negócio exige funcionalidades, prazos curtos e resultados mensuráveis, o que prima é a entrega. Se uma verificação de segurança demora horas e bloqueia a build, a pressão para sortear aparece naturalmente. Nesse caldo de cultivo, soluções pragmáticas como tirar de imagens públicas desde registries facilitam avançar, mas também introduz riscos difíceis de controlar.

Um bom exemplo do que pode falhar vem da própria análise da indústria. A equipe de pesquisa de Qualys examinou dezenas de milhares de imagens de contêineres públicos e encontrou resultados alarmantes: de uma amostra muito ampla, milhares de imagens apresentavam comportamento malicioso ou conteúdo sensível incorporado. Entre esses achados havia criptografia integrada em uma grande parte das amostras maliciosas e segredos (chaves da AWS, tokens do GitHub, credenciais de bases de dados) preservados dentro das camadas de imagem. Você pode ler o relatório e os detalhes técnicos no blog Qualys sobre este estudo aqui.

O erro conceitual é tratar os repositórios públicos como bibliotecas curadas e confiáveis por defeito. Plataformas como Docker Hub, registries de fornecedores cloud e outros serviços públicos facilitam a distribuição, mas a mera presença de uma imagem nesses espaços não garante que seja segura. Baixar uma imagem aberta é, em essência, uma decisão de confiança; e essa confiança pode estar mal colocada.

Então, o que fazer? A resposta passa por mover a segurança em outra direção: não mais "shift left" exclusivamente sobre o ombro do desenvolvedor, mas uma estratégia que baixe responsabilidade e controles para a camada de infraestrutura e plataforma. Em vez de pedir a cada engenheiro que se lembre de digitalizar, endurecer e auditar manualmente, há que oferecer caminhos seguros que sejam simples e rápidos de seguir.

Uma peça chave é a criação de um repositório interno que actue como quarentena de artefatos externos. Todas as imagens externas devem passar por um proxy ou um registry interno que inspeccione, firme e aprove artefatos antes que entrem nos pipelines. Ferramentas de gestão de artefatos como Harbor podem ajudar a construir este tipo de camada intermédia e automatizar políticas de aceitação; ver mais no projeto Harbor.

Na prática também vale a pena definir uma "ruta dourada" para os desenvolvedores: modelos padrão, imagens base aprovadas e pipelines oficiais que garantem segurança por defeito. Se as equipes seguirem esse caminho, a segurança se torna algo transparente para eles. Se alguém precisa sair do padrão, então exige revisões adicionais e processos manuais que justifiquem esse risco diante do negócio.

As ferramentas de política e controlo em infra-estruturas fazem parte da solução. Políticas declarativas aplicadas com módulos de Terraform, composições de Crossplane ou regras em Open Policy Agent evitam que ocorram erros humanos repetitivos: por exemplo, impedir que exista um bucket S3 sem versionado ou recusar implantaçãos com imagens que não cumpram requisitos mínimos. Open Policy Agent oferece um quadro para codificar este tipo de restrições e pode ser integrado em pipelines e controladores de admissão; consulta Open Policy Agent Para mais informações.

Da mesma forma, a automação deve abranger tanto a detecção como a resposta. As digitalizaçãos de contêineres devem ser executadas dentro do CI/CD e os controladores de admissão de Kubernetes devem impedir que contentores com vulnerabilidades críticas cheguem ao cluster. Em tempo de execução, as ferramentas não devem limitar-se a gerar alertas; diante de comportamento malicioso comprovado, o sistema deve ser capaz de isolar e matar cargas comprometidas, e até mesmo marcar nodos para contenção automática. A documentação oficial sobre controladores de admissão em Kubernetes explica como estes mecanismos funcionam: Kubernetes admission controllers.

Também é inteligente adotar abordagens que automaticem a correção: se for detectada uma vulnerabilidade em uma imagem base, a plataforma pode gerar um Pull Request para atualizar automaticamente e, após validações, promover a versão segura. Este tipo de fluxos reduz o tempo de exposição e aligeira a carga sobre equipamentos que não devem dedicar seu tempo a tarefas repetitivas de manutenção.

Isso não significa que a segurança deixe de colaborar com o desenvolvimento; ao contrário: requer uma relação mais estreita e proativa. Segurança e plataforma devem entender os requisitos do negócio e trabalhar para que a entrega segura seja a opção mais rápida e econômica. Isto evita o conflito entre cumprir objetivos de negócio e respeitar controles de segurança, porque ambos se alinham na mesma infraestrutura.

A mudança cultural também é relevante: deixar de culpar os desenvolvedores por atalhos e começar a desenhar sistemas que prevalem esses atalhos. Modelos como DevSecOps permanecem válidos, mas a sua implementação tem de ser orientada para a simplificação e a automação eficaz. Recursos de organismos como o OWASP ou o NIST fornecem guias e marcos para entender riscos na cadeia de fornecimento de software e como mitigar; ver por exemplo o projeto OWASP SAMM e as publicações de NIST sobre segurança da cadeia de fornecimento: OWASP SAMM e NIST - Software Supply Chain Security.

A conclusão é clara: se continuarmos carregando a responsabilidade sobre os ombros de desenvolvedores já sobrecarregados, obteremos evasões e exposição. Em vez disso, precisamos de plataformas que façam a opção segura também a opção fácil. A segurança deve "mover-se para baixo" na pilha, incorpondo-se na infraestrutura e automatizando-se, de modo que o negócio obtenha velocidade sem sacrificar controle ou proteção. Para quem quiser aprofundar a análise e recomendações específicas, o estudo de Qualys é um bom ponto de partida e está disponível em seu blog técnico aqui, e se você está avaliando soluções para ambientes cloud-native, o relatório de Forrester sobre CNAPP é outra referência útil disponível através do Qualys.