O software de código aberto tem suas vantagens, mas os riscos da cadeia de suprimentos não podem ser ignorados

Os componentes de código aberto desempenham um papel cada vez mais central no cenário de desenvolvimento de software, provando ser um benefício em um momento de integração e implantação contínuas, DevOps e atualizações diárias de software.

Em um relatório do ano passado, a empresa de automação de design de silício Synopsys descobriu que 97% das bases de código em 2021 continham código aberto e que em quatro das 17 indústrias estudadas – hardware e chips de computação, segurança cibernética, energia e tecnologia limpa e a Internet das Coisas (IoT) – o software de código aberto (OSS) estava em 100% das bases de código auditadas. As outras verticais tinham código aberto em pelo menos 93% delas.

Ele pode ajudar a aumentar a eficiência, a economia de custos e a produtividade do desenvolvedor.

“O código aberto realmente está em toda parte”, escreveu Fred Bals, redator técnico sênior da Synopsys, em um post de blog sobre o relatório.

Dito isso, o uso crescente de pacotes de código aberto no desenvolvimento de aplicativos também cria um caminho para grupos de ameaças que desejam usar a cadeia de suprimentos de software como um backdoor para inúmeros alvos que dependem dela.

O amplo uso de pacotes OSS no desenvolvimento significa que muitas vezes as empresas não sabem exatamente o que há em seu software. Ter muitas mãos diferentes envolvidas aumenta a complexidade e é difícil saber o que está acontecendo na cadeia de suprimentos de software. Um relatório do ano passado da VMware descobriu que as preocupações com o OSS incluíam ter que confiar em uma comunidade para corrigir vulnerabilidades e os riscos de segurança que vêm com isso.

Varun Badhwar, cofundador e CEO da Endor Labs – uma startup que trabalha para proteger o OSS no desenvolvimento de aplicativos – chamou-o de “a espinha dorsal de nossa infraestrutura crítica”. Mas ele acrescentou que os desenvolvedores e executivos costumam se surpreender com a quantidade de código de seus aplicativos que vem do OSS.

Badhwar observou que 95 por cento de todas as vulnerabilidades são encontradas em “dependências transitivas” – pacotes de código-fonte aberto que são indiretamente puxados para projetos em vez de selecionados pelos desenvolvedores.

“Esta é uma arena enorme, mas tem sido amplamente negligenciada”, alertou.

Conscientização crescente sobre a ameaça

A tendência de usar pacotes OSS não é nova. Os desenvolvedores fazem isso há doze anos ou mais, de acordo com Brian Fox, cofundador e CTO da fornecedora de gerenciamento de cadeia de suprimentos de software Sonatype e membro do conselho administrativo da OpenSSF (Open Source Security Foundation).

Os desenvolvedores juntam os componentes de origem e adicionam lógica de negócios, disse Fox ao The Register . Dessa forma, o código aberto se torna a base do software.

O que mudou nos últimos anos é a consciência geral disso – não apenas entre os desenvolvedores bem-intencionados que estão criando o software a partir dessas partes díspares.

“Os atacantes descobriram isso também”, disse ele. “Uma grande mudança notável nos últimos cinco anos foi o aumento de ataques intencionais de malware na cadeia de suprimentos”.

Isso veio à tona com a violação da SolarWinds em 2020, na qual criminosos ligados à Rússia invadiram o sistema de software da empresa e introduziram códigos maliciosos. Os clientes que baixaram e instalaram o código sem saber durante o processo de atualização foram comprometidos. Seguiram-se ataques semelhantes – incluindo Kaseya e, mais notavelmente, Log4j.

Obtendo a imagem através do Log4j

A ferramenta de log baseada em Java é um exemplo da consolidação massiva de riscos que vem com o amplo uso de componentes populares em software, argumentou Fox.

“É um componente simples [no software] e era tão popular que você pode basicamente estipular que ele existe em todos os aplicativos Java – e você acertaria 99,99% das vezes”, disse ele. “Como invasor… você vai se concentrar nesses tipos de coisas. Se você descobrir como explorá-lo, será possível ‘pulverizar e rezar’ pela Internet – ao contrário dos anos 90, quando você tinha que sentar e descobrir como quebrar cada aplicativo da web sob medida porque todos eles tinham código personalizado.”

As empresas “terceirizaram efetivamente 90 por cento de seu desenvolvimento para pessoas que você não conhece e não pode confiar. Quando coloco dessa forma, parece assustador, mas é o que vem acontecendo há dez anos. as implicações disso”.

A Log4j também destacou outro problema na cadeia de suprimentos de software e despertou muitos para o quão dependentes eles são do OSS. Mesmo assim, cerca de 29% dos downloads do Log4j ainda são das versões vulneráveis.

De acordo com a análise da Sonatype, na maioria das vezes que uma empresa usa uma versão vulnerável de qualquer componente, uma versão fixa do componente está disponível – mas eles não a estão usando. Isso aponta para a necessidade de mais educação, de acordo com Fox. “96 por cento do problema é que as pessoas continuam tirando a comida contaminada da prateleira em vez de pegar uma comida limpa.”

Segmentando os repositórios

Há outra ameaça crescente relacionada ao OSS: a injeção de malware em repositórios de pacotes como GitHub, Python Package Index (PyPI) e NPM. Os cibercriminosos estão criando versões maliciosas de códigos populares por meio de confusão de dependências e outras técnicas para induzir os desenvolvedores a inserir o código em seus softwares.

Eles podem usar um sublinhado em vez de um traço em seu código, na esperança de confundir os desenvolvedores para que peguem o componente errado.

“O desafio disso é que o ataque acontece assim que o desenvolvedor baixa esse componente e esses downloads acontecem pelas ferramentas”, disse Fox. “Não é como se eles estivessem literalmente indo para um navegador e baixando como nos velhos tempos, mas eles estão colocando em sua ferramenta e isso acontece nos bastidores e pode executar esse malware.

“A sofisticação dos ataques é baixa e esses componentes de malware nem sempre fingem ser um componente legítimo. Eles não compilam. Eles não vão executar o teste. Tudo o que eles fazem é entregar a carga útil. É como um quebra-galho”.

As defesas estão subindo

Apesar dos riscos de segurança inerentes ao OSS, há vantagens em usá-lo. É mais visível e transparente do que o software comercial, argumentou Fox. Ele apontou para a resposta às vulnerabilidades do Log4j: a equipe que trabalhava no Log4j corrigiu em poucos dias – algo que as organizações comerciais provavelmente não seriam capazes de fazer.

Mike Parkin, engenheiro técnico sênior da Vulcan Cyber, concordou que o modelo de código aberto de ter mais atenção ao código pode ajudar a mitigar ameaças cibernéticas, mas também facilita para invasores em potencial.

Dito isso, “historicamente, a compensação geralmente favorece os desenvolvedores de código aberto”, disse Parkin ao The Register.

O ataque da SolarWinds colocou muito foco na segurança da cadeia de suprimentos de software. Com base na Ordem Executiva de Segurança Cibernética de 2021 do presidente dos EUA Biden, a Casa Branca em setembro de 2022 ordenou que as agências federais [PDF] seguissem as diretrizes do NIST ao usar software de terceiros – incluindo autoatestação e listas de materiais de software (SBOMs) pelos fabricantes de software.

Há uma ampla gama de esforços em treinamento por fornecedores que buscam fortalecer a segurança da cadeia de suprimentos de software. Isso inclui o surgimento de estruturas de vários fornecedores, como o Open Software Supply Chain Attack Reference, ferramentas como o Vulnerability Exploitability Exchange (VEX) e outros produtos desenvolvidos por fornecedores de segurança cibernética.

Ainda assim, há outras medidas que a Fox da Sonatype gostaria de ver – como exigir que os fabricantes de software retirem os componentes defeituosos do software. No momento, eles são feitos para criar um SBOM. Fox comparou isso com os fabricantes de automóveis que precisam apenas fornecer aos compradores uma lista de peças do veículo, que podem ser colocadas em um porta-luvas e esquecidas, sem a responsabilidade de fazer o recall do carro se alguma dessas peças estiver com defeito.

“O que realmente precisamos é algo que basicamente determine que eles possam fazer um recall, porque isso implica que eles conhecem todas as peças e para onde as enviam e quais versões dos aplicativos têm quais dependências de código aberto, mas também significa que eles são realmente gerenciando e cuidando disso”, disse ele. “Isso leva você a esse comportamento adequado.”

A Fox quer o foco na manutenção dos pacotes OSS. Há algum movimento dos governos nessa direção, disse ele, observando que a Lei de Resiliência Cibernética da UE fala sobre a necessidade de recalls, mesmo que não use as palavras exatas. Fox disse que o governo Biden pode estar começando a aceitar a ideia.

Ele também está abordando a ideia de firewalls em nível de componente que funcionam de maneira semelhante aos firewalls em nível de pacote, que podem inspecionar o tráfego de rede e bloquear o tráfego malicioso antes que um ataque possa começar. Da mesma forma, um firewall em nível de componente pode interromper o código mal-intencionado antes que ele comprometa o software.

“Se você nem sabe o que há em seu software para começar, provavelmente não tem visibilidade do que está acontecendo com o malware, o que é quase um problema pior porque não é apenas a vulnerabilidade que está latente, esperando que alguém a explore, ” ele disse. “Está causando danos no momento em que você o toca. Não há pessoas suficientes que estejam realmente entendendo essa parte do problema também.”

A Sonatype construiu essa capacidade em sua plataforma com o Nexus Firewall, que a Fox disse ter sido modelado após a proteção contra fraudes de cartão de crédito. O firewall entende como é o comportamento normal e, usando inteligência artificial e técnicas de aprendizado de máquina, pode detectar comportamentos anormais. Em 2022, o firewall sinalizou mais de 108.000 tentativas de ataques maliciosos.

“Tantas organizações nem sabem que isso é um problema”, disse ele. “É onde o jogo está acontecendo agora e os atacantes estão tendo um dia de campo, infelizmente.”

É necessária uma combinação de recursos do tipo SBOM e firewall.

“Sim, você precisa saber onde estão todas essas partes, então, quando o próximo Log4j acontecer, você pode corrigi-lo imediatamente e não ter que começar a triagem de milhares de aplicativos”, argumentou Fox. “Mas isso não vai impedir esses ataques maliciosos. Você também precisa ser perfeito para proteger a fábrica.”

 

Fonte: The Register