Em um mundo onde 87% das imagens de contêiner em produção contêm vulnerabilidades críticas ou altas, uma pergunta desconfortável emerge: quem seria responsabilizado, ou até demitido, se uma dessas falhas fosse explorada em um ataque? Esta pergunta, por mais incômoda que seja, tem o poder de apontar instantaneamente um dos maiores problemas de segurança nas empresas hoje: a indefinição sobre quem gerencia CVEs em containers.
Há um "jogo de empurra" das vulnerabilidades em containers nas empresas. A responsabilidade pela segurança das imagens de containers frequentemente se divide entre os times de segurança, desenvolvedores e equipes de operações, cada um assumindo que o outro está cuidando do problema.
Esta fragmentação cria um ambiente perfeito para que vulnerabilidades críticas permaneçam sem tratamento, afinal, quando todos são parcialmente responsáveis, ninguém é verdadeiramente responsável. Em conversas com clientes e parceiros, observamos consistentemente esta divisão como um desafio significativo na segurança em ambientes containerizados, onde a ausência de um responsável claro resulta em exposições prolongadas a riscos conhecidos.
A ausência de métricas específicas para remediar vulnerabilidades de contêineres agrava o problema: times são avaliados por velocidade de entrega, disponibilidade de sistemas ou conformidade geral, mas raramente pelo tempo de resolução de CVEs. Esta dissociação entre responsabilidade e mensuração de desempenho resulta em negligência sistemática, onde vulnerabilidades conhecidas persistem indefinidamente em ambientes de produção.
O mito da responsabilidade compartilhada na gestão de vulnerabilidades
O conceito de que “segurança é responsabilidade de todos” soa inspirador. Mas, na prática, sem papéis bem definidos e mecanismos de governança eficazes, essa crença se torna um problema: quando algo é responsabilidade de todos, muitas vezes acaba sendo responsabilidade de ninguém.
Na gestão de CVEs em containers, o mito da responsabilidade compartilhada gera um limbo operacional. Segurança, DevOps e infraestrutura sabem que as vulnerabilidades precisam ser corrigidas, mas cada equipe assume que a outra está cuidando do problema. Enquanto isso, a disputa por prioridades nos backlogs adia correções críticas, prolongando o aging das vulnerabilidades e ampliando a janela de exposição a ataques. Sem um responsável claro, CVEs permanecem sem correção por semanas ou meses, aumentando riscos, custos operacionais e até penalidades regulatórias.
Segurança pode ser compartilhada, mas responsabilidade não pode ser difusa. Empresas que lidam bem com esse problema não eliminam a colaboração, mas deixam claro quem lidera, quem executa e quais métricas garantem que CVEs não fiquem esquecidas.
Um modelo DevSecOps realista
O DevSecOps precisa ser mais do que um ideal teórico, ele deve funcionar na prática, sem sobrecarregar equipes ou criar barreiras para o desenvolvimento. A segurança não pode ser simplesmente empurrada para os desenvolvedores como uma responsabilidade extra, mas sim integrada ao fluxo de trabalho de maneira eficiente.
Um modelo realista estrutura a segurança como parte do processo de desenvolvimento sem gerar atritos desnecessários. Imagens base seguras (CVEs próximo de zero) e pré-aprovadas eliminam vulnerabilidades antes mesmo do código ser escrito. Automação no CI/CD permite que vulnerabilidades sejam identificadas e tratadas sem impacto na velocidade de entrega. Políticas centralizadas e enforcement automatizado garantem que requisitos de segurança sejam aplicados de forma consistente, sem depender de decisões individuais ou gerar atrasos operacionais.
O shift-left tem um papel importante, mas deve ser usado como um complemento estratégico—permitindo que os desenvolvedores tenham mais visibilidade sobre segurança sem que isso comprometa a entrega ou exija expertise avançada na área.
Conclusão: De quem é a responsabilidade pelas CVEs, afinal?
Como muitas coisas em TI, a resposta pode variar conforme a cultura e estrutura de cada empresa. Mas uma coisa é inegociável: é preciso ter um responsável claro. Quando ninguém assume formalmente essa função, as vulnerabilidades permanecem sem correção, ampliando os riscos para o negócio.
As empresas mais resilientes adotam um modelo híbrido: a segurança é compartilhada, mas com papéis e processos bem definidos. Isso significa combinar automação, policy enforcement e práticas estruturadas para integrar a segurança ao ciclo de vida do software, sem sobrecarregar equipes ou criar gargalos operacionais.