os desenvolvedores estão analisando atentamente as lacunas de segurança da cadeia de suprimentos de software

Com tantas equipes de segurança e desenvolvedores fazendo post-mortems no fiasco da vulnerabilidade de segurança Log4j que se desenrolou no final de 2021, apenas 10 dias antes do Natal, a principal questão é: como evitar esse tipo de dor no futuro? A resposta, infelizmente, é… é complicado.

VEJO: Política de gerenciamento de patches (TechRepublic )

De acordo com novos dados do (ISC)2, a maior associação mundial sem fins lucrativos de profissionais de segurança cibernética certificados, quase metade (48%) das equipes de segurança cibernética desistiu de férias e fins de semana para ajudar na correção, e 52% das equipes gastaram “semanas ou mais ” corrigindo Log4j. Não exatamente como os desenvolvedores já esticados queriam ar as férias.

No lado positivo, no entanto, a dor dessa experiência desencadeou uma grande reformulação da segurança da cadeia de suprimentos de software por parte dos desenvolvedores e equipes de segurança.

Corrigindo vulnerabilidades sem quebrar o código legado

Um dos aspectos mais problemáticos do Log4j não era a vulnerabilidade em si, mas o quão profundamente a tecnologia está embutida no código legado. Afinal, o Java é uma das plataformas mais populares do mundo, e o Log4j é um sistema de log Java incrivelmente popular, cujo lançamento inicial remonta a 2001. Portanto, o Log4J toca não apenas uma tonelada de sistemas de produção, mas também muitos sistemas legados código.

“Ninguém quer tocar no código legado”, disse Sergei Egorov, CEO da AtomicJar, a nova startup por trás da estrutura de teste de integração de código aberto, Testcontainers. “Você não precisa apenas corrigir uma vulnerabilidade de segurança, você precisa saber que corrigiu a vulnerabilidade sem quebrar seu sistema. Quando você tem uma vulnerabilidade com uma biblioteca de log super popular como o Log4j, você está falando sobre dependências de código legado que normalmente carecem de testes, e onde às vezes os desenvolvedores que escreveram o código e entendem como ele funciona nem trabalham na empresa não mais.”

De acordo com Egorov, o Log4j geralmente é uma dependência transitiva de outras bibliotecas que precisam ser atualizadas. Ao contrário das plataformas que fornecem binários estáticos, com sistemas Java, a vinculação de código ocorre em tempo de execução, portanto, não há como ter 100% de confiança de que o aplicativo se comportará corretamente até que você realmente o execute e teste a vinculação em tempo real entre dependências e compilações.

Egorov disse que a Log4j acelerou o interesse na já popular plataforma Testcontainers, como forma de testar essas interações antes da implantação da produção. Ele vê desenvolvedores que foram picados pelo Log4j agora criando testes de integração entre sistemas e dependências externas, para que na próxima vez que uma vulnerabilidade de segurança chegar, os desenvolvedores possam testar se suas correções não derrubarão os sistemas de produção quando implantados. Testcontainers está se tornando um par popular com Snyk, porque os desenvolvedores podem obter solicitações de pull para solicitações de segurança automatizadas, e o teste de integração lhes dá a confiança de que podem mesclá-los sem quebrar nada.

O que é pior… a vulnerabilidade ou a interrupção dos usuários?

A chegada da vulnerabilidade de segurança Log4j e seu terrível momento durante a alta temporada de feriados criaram uma escolha perversa para as equipes de desenvolvedores – implantar correções agora e arriscar derrubar sistemas durante os ciclos de comércio eletrônico de feriados de pico ou adiar a implantação de correções para intervalos comercialmente menos arriscados ?

É uma decisão impossível de tomar se você não tiver o contexto certo.

“O Log4j causou pânico em muitas equipes de engenharia porque não tinham como prever como a correção afetaria seus usuários”, disse Marcin Kurc, CEO da startup de confiabilidade de software Nobl9, cujos clientes incluem grandes varejistas eletrônicos. “Existe uma análise de custo-benefício que precisa ocorrer em qualquer remediação de segurança. Você precisa determinar o intervalo certo para implantar a correção, o que requer uma compreensão completa do risco em termos de quantos usuários ela pode afetar e o nível aceitável de falta de confiabilidade que você pode aceitar.”

VEJO: NIST Cybersecurity Framework: Uma folha de dicas para profissionais (PDF grátis) (TechRepublic)

A empresa de Kurc está defendendo um movimento chamado objetivos de nível de serviço (SLOs) que nasceram nas práticas de engenharia de confiabilidade do site do Google e que a Nobl9 comercializou em uma plataforma.

Os SLOs permitem que os desenvolvedores modelem o tempo de atividade e as taxas de sucesso nas interações de software e definam limites para os resultados do usuário – digamos, por exemplo, qual porcentagem de checkouts de carrinho de compras são executados corretamente. As empresas que estão modelando SLOs, diz Kurc, podem ter uma conversa real sobre o risco de patching versus não patching.

Tais soluções, no entanto, vêm após o fato, ou melhor, depois que o software de código aberto foi escrito. Mas o que fazemos para torná-lo inerentemente mais seguro?

Um problema mais amplo: quem é o dono da segurança para o código aberto?

Ninguém vai parar de usar o código aberto. Seria absurdo construir uma solução de log do zero, em vez de usar ferramentas como o Log4j. Os desenvolvedores estão escrevendo menos lógica e integrando mais frameworks, bibliotecas e APIs nos dias de hoje, e isso não vai mudar.

Como Filippo Valsorda, do Google, escreveu em um post viral, muitos desses mantenedores de código aberto “se enquadram em uma das duas categorias: voluntários ou funcionários de grandes empresas. Às vezes ambos. Nenhum dos modelos é saudável.”

O Log4j iluminou o fato de que grande parte da cadeia de suprimentos de software moderna é apoiada em projetos de código aberto com um punhado de mantenedores, ou mesmo um único mantenedor, que muitas vezes criava a tecnologia como um projeto paralelo. (E sejamos claros: dados recentes sugerem que a grande maioria de todos os softwares de código aberto são escritos por menos de 10 pessoas.)

“Aplicativos modernos são construídos a partir de muitos componentes, muitos dos quais não são desenvolvidos internamente, mas sim montados usando soluções ‘de prateleira’”, de acordo com John , CISO do (ISC)2. “Uma grande parte da qualificação e identificação de problemas é saber quais componentes e bibliotecas são usados ​​por seu software e manter uma lista de materiais de software (SBOM).”

Mas, de acordo com um profissional de segurança anônimo na pesquisa de remediação Log4 do (ISC)2, “Os desenvolvedores em geral têm sido muito negligentes em rastrear o que usam em seus softwares. Quando um evento como esse exige que identifiquemos se alguma biblioteca ou componente é usado pelo nosso código, essa falta de rastreabilidade se torna um grande problema. Ele transforma um simples exercício de verificação de estoques e SBOMs em um processo de digitalização complexo, com muitas oportunidades para falsos positivos e falsos negativos. Se alguma vez precisávamos de um alerta, conseguimos um grande com o Log4j.”

O Google e outros pesos-pesados ​​estão investindo nesse desafio de vulnerabilidade de segurança de código aberto, e o tempo dirá se um investimento mais profundo e a colaboração de fornecedores podem ajudar a reduzir a frequência e a dor de incidentes como o Log4j. Mas, enquanto isso, os desenvolvedores estão elaborando estratégias para evitar terríveis surpresas de segurança na próxima temporada de festas.