XZ Utils Scare expõe duras verdades em segurança de software

A recente descoberta de um backdoor no utilitário de compactação de dados XZ Utils – presente em quase todas as principais distribuições Linux – é um forte lembrete de que as organizações que consomem componentes de código aberto, em última análise, possuem a responsabilidade pela segurança do software.

O XZ Utils, como milhares de outros projetos de código aberto, é administrado por voluntários e, no seu caso, tem um único mantenedor gerenciando-o. Esses projetos geralmente têm poucos ou nenhum recurso para lidar com problemas de segurança, o que significa que as organizações usam o software por sua própria conta e risco. Isso significa que as equipes de segurança e desenvolvimento devem implementar medidas para gerenciar riscos de código aberto da mesma forma que fazem com códigos desenvolvidos internamente, dizem especialistas em segurança.

“Embora seja improvável que uma organização consiga prevenir eficazmente [toda] a exposição aos riscos da cadeia de abastecimento, as organizações podem concentrar-se absolutamente numa estratégia para reduzir a probabilidade de um ataque à cadeia de abastecimento ser bem sucedido”, afirma Jamie Scott, gestor de produto fundador da Endor Labs.

Código aberto não é o mesmo que terceirização: “Os mantenedores de software de código aberto são voluntários. No nível da indústria, precisamos tratá-los como tal. Somos proprietários do nosso software; somos responsáveis ​​pelo software que reutilizamos.”

Bem intencionado, com poucos recursos

Preocupações com a segurança do software de código aberto não são de forma alguma novos. Mas muitas vezes são necessárias descobertas como a Vulnerabilidade do Log4Shell e os votos de backdoor em XZ Utils para realmente deixar claro o quão vulneráveis ​​as organizações são aos componentes de seu código. E muitas vezes, o código vem de projetos de código aberto bem-intencionados, mas com poucos recursos e com manutenção mínima.

XZ Utils, por exemplo, é essencialmente um projeto individual. Outro indivíduo conseguiu esgueirar a porta dos fundos para o utilitário durante um período de quase três anos, ganhando gradualmente confiança suficiente do mantenedor do projeto. Se um desenvolvedor da Microsoft não tivesse descoberto isso no final de março, ao investigar um comportamento estranho associado a uma instalação Debian, o backdoor poderia muito bem ter acabado em milhões de dispositivos em todo o mundo – incluindo aqueles pertencentes a grandes corporações e agências governamentais. No final das contas, o backdoor teve impacto mínimo porque afetou versões do XZ Utils que estavam presentes apenas em versões instáveis ​​​​e beta do Debian, Fedora, Kali, open SUSE e Arch Linux.

O próximo compromisso de código-fonte aberto poderia ser muito pior. “A parte mais assustadora para as organizações empresariais é que seus aplicativos são construídos com base em projetos de software de código aberto, como o XZ Utils”, diz Donald Fischer, cofundador e CEO da Tidelift. “XZ Utils é um pacote de dezenas de milhares que é usado todos os dias por organizações empresariais típicas”, diz ele.

A maioria destas organizações não tem visibilidade suficiente sobre a segurança e resiliência desta parte da sua cadeia de fornecimento de software para poder avaliar o risco, observa ele.

Um recente Harvard Business School estudo estimou que o valor do lado da demanda do software de código aberto seria de surpreendentes US$ 8.8 trilhões. Os mantenedores estão no centro deste ecossistema e muitos deles voam sozinhos, diz Fischer. Uma pesquisa realizada pela Tidelift no ano passado descobriu que 44% dos mantenedores de projetos de código aberto se descrevem como os únicos mantenedores de seus projetos. Sessenta por cento se identificaram como hobbyistas não remunerados, e a mesma porcentagem disse que desistiram ou consideraram abandonar suas funções como mantenedores de projetos. Muitos mantenedores descreveram seus esforços como um trabalho estressante, solitário e financeiramente pouco recompensador, diz Fischer.

“O hack dos utilitários XZ traz à tona os riscos de subinvestimento na saúde e na resiliência da cadeia de fornecimento de software de código aberto [da qual] as organizações empresariais dependem”, diz Fischer. “As organizações empresariais precisam perceber que a maioria dos pacotes de código aberto mais confiáveis ​​são mantidos por voluntários que se descrevem como hobbyistas não remunerados. Esses mantenedores não são fornecedores empresariais, mas espera-se que trabalhem e entreguem como eles.”

Perigo: Dependências Transitivas

A estudo que Endor conduziu em 2022 descobriu que 95% das vulnerabilidades de código aberto estão presentes nas chamadas dependências transitivas, ou pacotes secundários de código aberto ou bibliotecas dos quais um pacote primário de código aberto pode depender. Freqüentemente, esses são pacotes que os próprios desenvolvedores não selecionam diretamente, mas são automaticamente empregados por um pacote de código aberto em seu projeto de desenvolvimento.

“Por exemplo, quando você confia em um pacote Maven, em média há 14 dependências adicionais nas quais você confia implicitamente”, diz Scott. “Esse número é ainda maior em certos ecossistemas de software, como o NPM, onde você importa, em média, 77 outros componentes de software para cada um em que você confia.”

Uma maneira de começar a mitigar os riscos do código aberto é prestar atenção a essas dependências e ser seletivo quanto aos projetos que você escolher, diz ele.

As organizações devem examinar as dependências, especialmente os pacotes menores e únicos, administrados por equipes de uma ou duas pessoas, acrescenta Dimitri Stiliadis, CTO e cofundador da Endor. Eles devem determinar se as dependências em seu ambiente possuem controles de segurança adequados ou se um único indivíduo compromete todo o código; se eles têm arquivos binários em seus repositórios que ninguém conhece; ou mesmo se alguém estiver mantendo ativamente o projeto, diz Stiliadis.

“Concentre seus esforços em melhorar a eficácia de sua resposta – controles fundamentais, como a manutenção de um inventário de software maduro, continuam sendo um dos programas de maior valor que você pode ter para identificar, definir o escopo e responder rapidamente aos riscos de software assim que forem identificados”, Scott aconselha.

Ferramentas de análise de composição de software, scanners de vulnerabilidade, sistemas EDR/XDR e SBOMs também podem ajudar as organizações a identificar rapidamente componentes de código aberto vulneráveis ​​e comprometidos.

Reconhecendo a ameaça

“A mitigação da exposição começa com a compreensão e o reconhecimento compartilhados no alto escalão e até mesmo no nível do conselho de administração de que cerca de 70% dos ingredientes de um produto de software médio são software de código aberto, historicamente criados por colaboradores em sua maioria não remunerados”, diz Fischer da Tidelift.  

Novas regulamentações e diretrizes no setor de serviços financeiros, na FDA e no NIST moldarão a forma como o software será desenvolvido nos próximos anos e as organizações precisam se preparar para elas agora. “Os vencedores aqui se adaptarão rapidamente de uma estratégia reativa para uma estratégia proativa de gerenciamento de riscos relacionados ao código aberto”, diz ele.

Fischer recomenda que as organizações façam com que suas equipes de segurança e engenharia identifiquem como novos componentes de código aberto entram em seu ambiente. Eles também devem definir funções para monitorar esses componentes e remover proativamente aqueles que não atendem ao apetite de risco da empresa. “Reagir a problemas em estágio avançado tornou-se uma forma ineficaz de lidar com a escala do risco para o negócio nos últimos anos, e o O governo dos EUA está sinalizando essa era está chegando ao fim”, diz ele.

• Conteúdo com tecnologia de SEO e distribuição de relações públicas. Seja amplificado hoje.
• PlatoData.Network Gerativa Vertical Ai. Capacite-se. Acesse aqui.
• PlatoAiStream. Inteligência Web3. Conhecimento Amplificado. Acesse aqui.
• PlatãoESG. Carbono Tecnologia Limpa, Energia, Ambiente, Solar, Gestão de resíduos. Acesse aqui.
• PlatoHealth. Inteligência em Biotecnologia e Ensaios Clínicos. Acesse aqui.
• Fonte: https://www.darkreading.com/application-security/xz-utils-scare-exposes-hard-truths-in-software-security