As ferramentas SCA fornecem informações sobre os componentes de software de código aberto e as vulnerabilidades que eles possuem
Definição de análise de composição de software
A análise de composição de software (SCA) se refere à obtenção de insights sobre quais componentes e dependências de código aberto estão sendo usados em seu aplicativo e como – tudo de maneira automatizada. Esse processo tem o objetivo de avaliar a segurança desses componentes e quaisquer riscos potenciais ou conflitos de licenciamento por eles causados. Incorporar ferramentas SCA em seu fluxo de trabalho de desenvolvimento de software corretamente é um passo significativo para fortalecer a segurança e integridade da cadeia de suprimentos de software, garantindo que qualquer código emprestado não introduza riscos de segurança ou problemas de conformidade legal em seus produtos.
Por que a análise de composição de software é necessária
Já se foi o tempo em que os aplicativos de software eram desenvolvidos do zero. A adoção desenfreada de software de código aberto revolucionou o desenvolvimento de aplicativos. Desenvolvedores e empresas independentes podem usar componentes e bibliotecas existentes em seu código para implementar funcionalidades, desde validações simples de formulários da web até operações criptográficas complexas.
Embora a reutilização de código aberto tenha eliminado em grande parte a necessidade de reinventar a roda, ela vem com algumas ressalvas: e se o código que você está emprestando tiver bugs ou vulnerabilidades de segurança? Além disso, e se os termos da licença do componente de código aberto entrarem em conflito com a licença do seu aplicativo? Quem vai revisar tudo isso?
Rever uma dúzia de componentes pode ser uma tarefa simples de executar manualmente, mas os aplicativos de software modernos são construídos usando centenas de bibliotecas. Essas bibliotecas podem ter outras dependências. Esse processo pode ser executado em muitas camadas profundas e, antes que você perceba, seu aplicativo, que de outra forma parece conter apenas um punhado de bibliotecas, pode estar puxando centenas ou milhares de dependências transitivas. É aqui que a SCA vem ao resgate.
Análise de composição de software e SBOMs
A maioria das ferramentas SCA pode gerar uma lista de materiais de software (SBOM). Um SBOM é uma conta detalhada do inventário – todas as dependências e componentes que constituem o seu aplicativo. Um SBOM ideal fornece o nome do componente, número da versão, data de lançamento, soma de verificação, informações de licença, entre outros metadados para cada componente presente em seu aplicativo.
Isso pode ser feito de diferentes maneiras:
Normalmente, os SBOMs são fornecidos como arquivos de texto em XML, JSON ou formatos semelhantes que os tornam legíveis para humanos e máquinas. Abaixo está um exemplo de SBOM para o aplicativo Keycloak, versão 10.0.2. O documento XML é baseado no padrão OWASP CycloneDX e lista os componentes que constituem o Keycloak, incluindo suas somas de verificação, número de versão, data de lançamento e informações de licença. Digno de nota é que uma única versão do Keycloak contém mais de 900 componentes, de acordo com o SBOM:
O formato SPDX da Linux Foundation, embora ainda baseado em texto, difere do padrão CycloneDX. Um exemplo é mostrado abaixo.
Como as ferramentas SCA ajudam a encontrar vulnerabilidades de código aberto?
As ferramentas SCA automatizadas podem ajudar as equipes de software a criar e enviar códigos de alta qualidade e capacitar as partes interessadas com uma abordagem proativa para o gerenciamento de riscos. Ao identificar vulnerabilidades e riscos de segurança no início do processo de desenvolvimento de software, as ferramentas SCA podem permitir que os desenvolvedores de software selecionem componentes mais seguros com antecedência. Essa vantagem acelera o processo de desenvolvimento, minimizando a necessidade de avaliações de segurança repetidas, pois é tomado cuidado suficiente desde o início ao incluir componentes e bibliotecas de terceiros em um aplicativo.
Se um componente com riscos e vulnerabilidades conhecidos for absolutamente necessário, as equipes de desenvolvimento podem fazer uma avaliação quando o componente for introduzido pela primeira vez e considerar a adoção de possíveis soluções alternativas para usar o componente com segurança.
O objetivo do processo e das ferramentas de SCA não termina em apenas escanear as fontes e binários de seu aplicativo para produzir um SBOM. O principal desafio está em mapear com precisão cada versão do componente para vulnerabilidades conhecidas. Além disso, vem o aspecto de conformidade: permitir que as partes interessadas revisem e resolvam perfeitamente quaisquer conflitos de licenciamento apresentados pelos componentes.
Alguns anos atrás, o processo pode ter sido simples. Basta revisar os feeds CVE fornecidos pelo MITER ou NVD e mapeá-los para as versões dos componentes presentes em seu aplicativo. Pesquisas incluindo um artigo produzido pela University of Central Florida, George Mason e Georgia Tech mostraram que os avisos de CVE podem frequentemente ser imprecisos e conter inconsistências. Outras vezes, os dados CVE podem ser mal interpretados devido à forma como os dados Common Platform Enumeration (CPE) são apresentados nesses avisos.
Por exemplo, um comunicado CVE emitido para vulnerabilidade no servidor Tomcat pode se aplicar a apenas um componente selecionado no namespace Apache Tomcat, como org.apache.tomcat:coyote em vez de todo o namespace Apache Tomcat, mas isso pode não estar claro sozinho dos CPEs mencionados no comunicado.
As ferramentas SCA, portanto, precisam ser inteligentes o suficiente para mapear com precisão as vulnerabilidades de segurança para os componentes afetados, ao invés de confiar cegamente em recomendações CVE e sinalizar componentes benignos. Para minimizar o atrito para os desenvolvedores e, ao mesmo tempo, deixar as equipes de avaliação de segurança e conformidade em paz, as soluções SCA precisam minimizar a ocorrência de vulnerabilidades falso-positivas em seus resultados, mas não correndo o risco de introduzir falsos negativos (ou seja, riscos de segurança ausentes). Isso pode justificar a intervenção humana e a pesquisa de segurança e ferramentas de varredura de arquivos baseadas em assinaturas.
Além disso, confiar apenas nos feeds do CVE para a inteligência de segurança não é suficiente. Avisos de vulnerabilidade podem aparecer em sites de fornecedores de produtos, GitHub e em muitos outros lugares, incluindo bancos de dados privados. Da mesma forma, exploits de prova de conceito para zero-day ou vulnerabilidades conhecidas podem aparecer no Exploit-DB, fóruns de hackers e outros lugares misteriosos. Nem todas as ferramentas SCA são iguais e precisam ter capacidade suficiente para obter inteligência de uma infinidade de fontes e dar sentido a milhares dessas entradas.
Ameaças mais recentes da cadeia de suprimentos: malware, bibliotecas sequestradas, confusão de dependências
Ao selecionar ferramentas SCA para sua organização, outro desafio que surge é acompanhar novos ataques, não apenas riscos de segurança e vulnerabilidades conhecidas.
Como se ficar à frente do dia zero já não fosse um problema, agora estamos vendo um aumento na incidência de ataques de typosquatting e malware de confusão de dependências se infiltrando em registros de código aberto como npm, PyPI e RubyGems, e estes continuam evoluindo.
Como pesquisador de segurança sênior, analisei centenas de amostras de malware e pacotes de confusão de dependências que se infiltram no ecossistema de código aberto. Outubro de 2021 marcou a primeira vez que vimos código de ransomware funcional incluído em um typosquat habilmente chamado: noblox.js-proxies. O pacote legítimo é denominado noblox.js-proxied e é um espelho do pacote oficial Noblox.js, um empacotador da API do jogo Roblox.
No mesmo mês, os próprios agentes de ameaças sequestraram bibliotecas npm extremamente populares, ua-parser-js, coa e rc para instalar criptomineradores e ladrões de senhas. A biblioteca UA Parser é baixada mais de 7 milhões de vezes por semana e é usada pelo Facebook, Microsoft, Amazon, Google, entre outras empresas de tecnologia, demonstrando o impacto potencial que poderia ter resultado de um sequestro como este. Da mesma forma, coa consegue cerca de 9 milhões de downloads semanais e rc cerca de 14 milhões.
Em vez de um ataque de typosquatting ou sequestro de dependência, no entanto, esse incidente da cadeia de suprimentos envolveu agentes de ameaça comprometendo a conta npm dos mantenedores líderes por trás desses projetos. JetBrains revelou o impacto potencial para desenvolvedores Kotlin/JS que executaram casos de teste Karma durante a janela de compromisso, já que ua-parser-js era uma das dependências para a estrutura de teste Karma.
Tudo isso levanta a questão: suas ferramentas SCA são capazes de detectar injeções de malware, typosquats maliciosos, sequestros de dependência e bibliotecas comprometidas antes de serem distribuídas no fluxo abaixo?
Identificar os milhares de componentes que compõem seu aplicativo é em si uma tarefa difícil para uma ferramenta automatizada, quanto mais para uma equipe de desenvolvedores humanos. Em seguida, vem a tarefa de vasculhar os feeds de segurança, listando milhares de vulnerabilidades que podem ou não se aplicar ao seu aplicativo. Finalmente, o cenário de ameaças em constante evolução complicou ainda mais as questões de segurança e integridade da cadeia de suprimentos de software. Integrar uma solução SCA abrangente, rápida e precisa em seu fluxo de trabalho de desenvolvimento de software tornou-se indispensável, mas adquirir uma que aborde a maioria, senão todas as novas ameaças mencionadas, permanece um desafio.
