Empresas nativas da nuvem estão gastando demais no gerenciamento de CVE

Pedir aos desenvolvedores nativos da nuvem que “construíssem agora” significou colocar vulnerabilidades (CVEs) em sua cadeia de suprimentos nativa da nuvem para “mais tarde”. O novo movimento CVE Zero está a repensar a forma de abordar a dívida de segurança de contentores.

As empresas modernas são viciadas na entrega rápida de novos recursos. É por isso que entregar software para uma equipe de software moderna muitas vezes é como alimentar um grupo frenético de tubarões com peixes. É também por isso que aceitar todos os tipos de dívidas técnicas é tão fácil para as equipes de software. Por que não alimentar os tubarões hoje? Eles querem isso hoje e estão dispostos a pagar.

As empresas nativas da nuvem tendem a sentir essa compensação de forma particularmente aguda. Os desenvolvedores de software escolhem imagens de contêiner base e outras imagens de terceiros e adicionam código e configuração personalizados. Pode haver problemas ocultos nessas imagens de contêineres de terceiros, mas os testes passam e os clientes ficam satisfeitos.

Só mais tarde é que os problemas surgem, quando as equipes de software nativo da nuvem descobrem dezenas de milhares de CVEs conhecidos exclusivos na frota de contêineres que alimentam seus aplicativos geradores de receita.

Qual é o custo real de “pagar depois” em CVEs?

É cada vez mais aceito que os contêineres mais populares, os blocos de construção fundamentais dos aplicativos nativos da nuvem, estão repletos de CVEs. A análise da indústria sugere que mesmo as versões mais recentes de contêineres populares possuem centenas de CVEs. Uma pesquisa do Ponemon Institute e de outras organizações está investigando como as equipes estão usando padrões emergentes de DevSecOps para gerenciar e lidar com vulnerabilidades.

Mas toda essa grande pesquisa não responde a uma questão fundamental: quanto custa a abordagem “pagar depois” para aceitar vulnerabilidades de contêineres como uma forma de dívida de segurança? custo? Qual é a penalidade real de identificar, fazer triagem e remediar CVEs?

Para fornecer à comunidade de segurança mais informações sobre o custo dos CVEs, o Chainguard Labs conduziu entrevistas profundas com profissionais de software que lidam com o gerenciamento de vulnerabilidades como parte de suas tarefas diárias em empresas de software nativas da nuvem. Nossa investigação se aprofundou em todas as tarefas e fluxos de trabalho associados ao gerenciamento de CVE para estimar o custo anual do tempo de gerenciamento de CVE.

O gerenciamento de CVE custa milhares de horas por ano

As descobertas foram assustadoras, especialmente do ponto de vista dos líderes de software que precisam manter a velocidade dos recursos para competir.

Aprendemos que a maioria das empresas de software nativo da nuvem gasta milhares de horas todos os anos no gerenciamento de vulnerabilidades. Para algumas empresas, são 10.000 horas por ano – ou mais. É uma equipe inteira de engenharia que não faz nada além de identificar, fazer triagem e corrigir vulnerabilidades.

A tabela a seguir revela esta realidade assustadora. Embora a média pareça ser de cerca de 1.000 horas por ano, algumas organizações gastam 10 vezes mais. Isso significa que equipes inteiras de engenheiros de software e segurança estão gerenciando CVEs em vez de enviar novos softwares.

As equipes racionalizam o adiamento do pagamento da dívida CVE de diferentes maneiras.

Um fator importante é que os consumidores de software são vorazes e exigem novos recursos criados rapidamente. Isso significa que os engenheiros de software com prazos apertados estão aceitando relutantemente o padrão nativo da nuvem – contêineres com CVEs. Se a funcionalidade funcionar, a verificação de CVEs (muito menos corrigi-los) será uma reflexão tardia.

Outro fator importante é que os desenvolvedores de aplicativos de software que geralmente selecionam uma imagem de contêiner – geralmente fazendo algumas edições em um Dockerfile – muitas vezes não são os que arcam com os custos posteriores do gerenciamento de vulnerabilidades.

Finalmente, é difícil criar software que seja fácil de atualizar. Embora esteja no centro da filosofia DevOps, é difícil de fazer na prática. Alterar um software, mesmo para consertar um CVE, muitas vezes acarreta o risco de inatividade do produto e frustração dos clientes. Conseqüentemente, muitas organizações de software acham penoso fazer pequenas alterações em seus softwares. Isso significa que consertar um CVE pode ser considerado não valer o risco.

Você não pode saber quando a dívida de segurança CVE deve ser paga

Cada organização enfrenta cronogramas diferentes sobre quando suas dívidas de segurança geradas por CVE exigem pagamento.

Para alguns, a dívida deve ser paga por motivos de conformidade. Por exemplo, as empresas nativas da nuvem que buscam entrar nos mercados federais muitas vezes se deparam com estruturas de conformidade que exigem uma quantidade enorme de papelada quando os CVEs estão presentes em contêineres (pense no FedRAMP).

Para os particularmente desafortunados, a dívida vence de uma só vez, como consequência da exploração de um CVE por hackers para aceder a um sistema. Esse custo pode ser de milhões de dólares em perdas de reputação, ações judiciais e ransomware. CVE-2017-5638, uma vulnerabilidade no Apache Struts, permitia a execução remota de código por meio de cabeçalhos HTTP. Produziu uma das maiores violações de dados da história, afectando quase 150 milhões de cidadãos dos EUA e 15 milhões de cidadãos do Reino Unido.

CVE-2021-44228, mais conhecido como Log4Shell, é outro exemplo de CVE que exige o pagamento de uma dívida de segurança de uma só vez. Como o peso pesado indiscutível de todos os CVEs, o Log4j é ainda tão difundido que quase todas as grandes organizações o administram, e muitas ainda estão tentando encontrar todas as instâncias.

CVE Zero trata de construir com segurança desde o início

Microsserviços e contêineres reescreveram as regras de como os desenvolvedores obtêm componentes de software. Já se foram os dias das abordagens de cima para baixo, em que a liderança técnica decidia sobre distribuições Linux, sistemas operacionais, infraestrutura de aplicativos e acordos de nível de serviço (SLAs) de segurança. Hoje, os desenvolvedores estão fazendo tudo isso em Dockerfiles e GitHub Actions.

Mas existem enormes lacunas de confiança entre distribuições e pacotes de software. Existem classes inteiras de vulnerabilidades que residem fora das distribuições e não são detectadas por scanners de segurança. Enquanto isso, a maioria das distribuições e pacotes de software vem com muitos CVEs conhecidos que criam uma tonelada de ruído de “falso positivo” nos scanners de segurança. A consequência de pagar a dívida de segurança CVE posteriormente é que é muito difícil obter uma imagem clara de quais CVEs são endereçados em seu ambiente. Também há muito trabalho envolvido para estimar o tempo de triagem de um CVE individual, com tantas variáveis ​​entre uma simples atualização de versão em lote e a migração de uma base de código para uma nova versão principal de uma dependência.

Pagar a dívida de segurança causada pela vulnerabilidade sempre que a conta vence é um pesadelo de gerenciamento de engenharia – um trabalho irregular e imprevisível.

O CVE Zero busca controlar o binário, a própria imagem do contêiner. Trata-se de mudar os blocos de construção do software para uma abordagem de vulnerabilidade zero. Trata-se de eliminar o excesso de componentes desnecessários das imagens básicas para que os sinais dos scanners de segurança se tornem mais confiáveis.

John Speed ​​Meyers é chefe do Chainguard Labs na Chainguard, uma startup de segurança da cadeia de suprimentos de software.

Leia mais de John Speed ​​Meyers