Crie uma lista de materiais do software (SBOM, software bill of materials) para garantir a segurança da cadeia de open source supply chain

Mais do que nunca, os desenvolvedores criam aplicações para a Web com base em bibliotecas de software de código aberto. No entanto, ainda que essas bibliotecas constituam o inventário de componentes da SBOM, nem todos os desenvolvedores e stakeholders da empresa entendem o impacto que as bibliotecas de terceiros geram na segurança da cadeia de suprimentos de código aberto. Com isso em mente, vamos abordar a segurança da SBOM e a importância de monitorá-la para os aplicativos que você está desenvolvendo.

A preocupação com a software supply chain security vem se tornando um dilema cada vez maior para organizações e governos. O relatório Cenário das Ameaças dos Ataques de Supply Chain, publicado pela Agência da União Europeia para a Cibersegurança (ENISA), estimou um aumento de 400% em ataques a software supply chain em 2021.

O vasto uso de software de código aberto disponível a desenvolvedores e a facilidade de importar componentes de software contribuem para um maior fator de risco, devido a preocupações jurídicas e de segurança para os desenvolvedores e, consequentemente, para suas empresas. É por isso que é importante instruir equipes de desenvolvedores e segurança, equipando-as com soluções avançadas de segurança da cadeia de suprimentos.

Antes de prosseguirmos, vamos observar alguns aspectos básicos da SBOM e esclarecer alguns termos técnicos usados neste artigo.

O que é uma lista de materiais do software?

Uma lista de materiais do software, geralmente indicada pela sigla SBOM (software bill of materials), é uma lista completa de todos os componentes de software usados em uma organização. A lista de materiais de software é composta por bibliotecas de código aberto de terceiros, pacotes oferecidos por fornecedores e artefatos internos desenvolvidos pela organização.

Por que preciso criar uma SBOM?

A SBOM é, em essência, um inventário de todos os componentes de software que você usa nos seus aplicativos. Sem ela, não é possível ter visibilidade dos riscos de licença e segurança associados ao software em desenvolvimento ou uso. Manter uma SBOM atualizada e em conformidade é crucial para acompanhar o rápido desenvolvimento de um software, no qual os componentes e suas versões mudam com frequência.

O que é o CycloneDX?

O CycloneDX da OWASP é um padrão de SBOM criado para contextos de segurança de aplicativos e análise de componentes de cadeia de suprimentos, fornecendo um inventário de todos os componentes de software internos e de terceiros. A especificação é vasta e se estende além das bibliotecas de software, incluindo padrões de listas de materiais de software como serviço (SaaSBOM),o Vulnerability Exploitability Exchange (VEX) e outros. O padrão é um projeto de código aberto com licença Apache 2.0 e está aberto a colaboração no seguinte repositório de código aberto do GitHub: https://github.com/CycloneDX/specification.

Preocupações com segurança exigem que os desenvolvedores mantenham uma SBOM

A SBOM não é uma terminologia conhecida pelos desenvolvedores, pois essa atividade tem sido realizada pelas equipes de segurança e avaliação de risco das organizações. No entanto, o panorama mudou devido ao forte aumento no uso dos componentes de software de código aberto, como mostra o registro de pacotes npm, que abrange mais de 1.800.000 de pacotes gratuitos de código aberto.

Se você desenvolve software e não sabe se precisa de uma SBOM para todos os componentes que usa, vamos recordar os diversos incidentes de segurança de ampla repercussão que ocorreram nos últimos anos devido a bibliotecas de software de código aberto:

1. event-stream: O popular pacote de npm foi comprometido para incluir código malicioso.

2. Log4Shell: A popular biblioteca de logs Java Log4j tinha uma vulnerabilidade de execução de código remoto de alta gravidade, Essa vulnerabilidade já existia por sete anos antes de ser encontrada.

Quando esses incidentes ou vulnerabilidades de segurança ocorrem e são descobertos, e seus aplicativos usam uma versão vulnerável, quem você acha que é responsável por fazer upgrade das bibliotecas e enviar a nova versão? Isso mesmo, os desenvolvedores.

Mesmo que a equipe de segurança tome medidas para manter a lista de materiais do software, ela emite um alerta quando esses problemas são descobertos, informa as equipes envolvidas e procura desenvolvedores para atualizar as versões vulneráveis. Mas, em um mundo de gerenciamento avançado de fluxos de trabalho, será que não podemos automatizar todo esse processo para que ele seja integrado de forma mais nativa aos fluxos dos desenvolvedores? Claro que sim. É isso que faz a Snyk gratuitamente.

Por que os desenvolvedores devem se importar com o impacto jurídico da lista de materiais do software?

Hoje em dia, os desenvolvedores não se preocupam tanto com os aspectos legais do uso do software quando começam a escrever o código e criar aplicativos. No entanto, as coisas não eram bem assim há umas décadas. Os desenvolvedores e suas equipes prestavam muita atenção à licença específica dos componentes do software que inseriam nos códigos. O que mudou? Antigamente, as licenças mais usadas eram do tipo “copyleft”, como a General Public License (GPL) da GNU, que removeu várias limitações à distribuição de software. Para não nos alongarmos, basta saber que a GPL teve um efeito cascata, e qualquer código que use um componente com a licença GPL se torna automaticamente licenciado pela GPL, algo a se considerar antes de criar um modelo de negócios.

Vinte anos depois, caminhamos na direção oposta às licenças copyleft. Em 2015, a licença mais utilizada em repositórios de código aberto criada no GitHub era a licença MIT. Junto com outras licenças, a MIT pertence a uma família de licenças permissivas que eliminaram várias limitações na forma como o software pode ser usado, aumentando a liberdade dos desenvolvedores para usar software com essa licença.

Na era atual do software de código aberto, estamos observando um grande crescimento na adoção de software com contribuições recentes e licenças bastante permissivas. Será que nos acostumamos a usar o código aberto por padrão? Será que estamos desvalorizando as licenças de software de código aberto?

Dois casos populares de problemas jurídicos de software que afetam o uso da licença do próprio projeto são fundamentais para os desenvolvedores:

1. O React, biblioteca extremamente popular de JavaScript em código aberto, viu sua licença mudar da versão “BSD+Patents” para a permissiva licença MIT porque a Apache Software Foundation baniu o projeto React por considerar a licença do Facebook como muito restritiva. Isso também foi recebido com pressão por desenvolvedores do mundo todo, que consideraram abandonar inteiramente o projeto e adotar opções alternativas, como o projeto Preact. Quincy Larson apresenta uma interessante cronologia dos eventos neste artigo do freecodecamp.

2. A Elastic, empresa e projeto de código aberto de mesmo nome, da popular ferramenta de pesquisa Elasticsearch e do ELK Stack, também precisou lidar com alterações de licença devido ao aumento na concorrência de fornecedores de nuvem e seu impacto nos negócios da Elastic.

Por usar React, Elastic ou outras bibliotecas de softwares de código aberto no seu trabalho de desenvolvimento, você provavelmente será responsável por considerar a migração de um projeto para outro quando surgirem problemas com licenças.

Além disso, o que acontece se você acabar criando aplicativos e lançando software em que um dos componentes aninhados tem uma licença copyleft? Os ecossistemas JavaScript e Node.js são conhecidos pelo alto número de pacotes npm instalados. O risco ao negócio é real e requer sua atenção, pois os desenvolvedores precisam monitorar e entender quais licenças de software são usadas nos projetos.

Os aplicativos que você cria e o software que usa provavelmente já incluem referências da licença que está sendo usada. Por exemplo, se você está criando um projeto em JavaScript, as informações da licença fazem parte do arquivo de manifesto package.json:

1{
2  "name": "snyk",
3  "version": "1.0.0-monorepo",
4  "description": "snyk library and cli utility",
5  "files": [
6    "help/cli-commands",
7    "dist",
8    "bin",
9    "pysrc",
10    "config.default.json",
11    "SECURITY.md",
12    "LICENSE",
13    "README.md"
14  ],
15  "author": "snyk.io",
16  "license": "Apache-2.0",

A licença descrita no arquivo package.json usa o formato SBOM conhecido como SPDX para manter a conformidade com padrões internacionais e de interoperabilidade entre diferentes ferramentas.

O que é o SPDX?

O Software Package Data Exchange (SPDX) é um projeto colaborativo da Fundação Linux que oferece um padrão de formato comum de SBOM para rastrear listas de materiais de software e facilitar a criação de relatórios de interoperabilidade por diferentes ferramentas. Mais especificamente, a SPDX License List oferece um identificador de listas de licenças comuns e um URL canônico para cada licença.

Esta página da SPDX License List contém a lista completa de todas as licenças e seus identificadores:

A Snyk fornece recursos de auditoria de código aberto que, assim como a tabela acima, geram relatórios de listas de materiais de software para estabelecer uma auditoria de software abrangente, totalmente interativa, pesquisável e com filtros.

Padronização do uso de bibliotecas de código aberto por desenvolvedores

As organizações de engenharia maduras evoluem do uso oportunista e ocasional das bibliotecas de código aberto para uma utilização mais intencional e planejada dos seus projetos, seguindo diretrizes e práticas recomendadas.

Por exemplo, as equipes de desenvolvimento em JavaScript precisam garantir que os desenvolvedores de diferentes equipes definam um padrão sobre o uso de uma única dependência de solicitações HTTP, em vez de recorrer a várias dependências, como request, axios, node-fetch e outros para pacotes npm. Isso ocorre para facilitar a gestão de dependências de código aberto e também centralizar o conhecimento e expertise em API, simplificar a resolução de problemas e outros motivos.

As equipes de desenvolvimento devem responder de forma realística às perguntas a seguir:

• Quais bibliotecas de código aberto usamos com mais frequência em todos os projetos da nossa organização de P&D?

• Quais bibliotecas de código aberto usadas por nós foram descontinuadas?

• Quais bibliotecas de código aberto nos nossos projetos usam licenças copyleft como a GPL-2?

• Quais bibliotecas de código aberto foram publicadas ha mais de 15 anos e não receberam atualização? Devemos nos preocupar com isso?

Todos esses insights e outros são benefícios que você obtém ao manter uma lista de materiais de software (SBOM). A Snyk disponibiliza essas informações valiosas de integridade dos pacotes de código aberto como parte dos recursos do Snyk Open Source:

Por que a SBOM acelera a capacitação de supply chain security?

O que é software supply chain security?

No desenvolvimento de software, as preocupações com a segurança de aplicações no ciclo de vida da segurança eram tradicionalmente voltadas apenas para o código desenvolvido pelos desenvolvedores, mas agora abrangem toda a infraestrutura de ferramentas de desenvolvimento. Dessa forma, uma grande superfície de ataque é criada a partir da etapa inicial da ferramenta de IDE que os desenvolvedores usam para escrever código e partir dos componentes de código aberto usados na criação dos aplicativos e até mesmo pipelines de CI/CD. Inclusive, pode-se argumentar que os riscos de segurança do supply chain incluem os chips de hardware no computador usado no ambiente de desenvolvimento.

O Departamento de Comércio dos EUA emitiu um documento que segue a Ordem Executiva 14028 sobre o aprimoramento da cibersegurança do país, no qual cita os elementos mínimos para uma SBOM. Vamos explicar o que é supply chain para ver o que podemos aprender.

Basicamente, software supply chain se refere a todos os componentes que fazem parte do fluxo de criação de um software. À primeira vista, podemos pensar em software supply chain apenas como as dependências que adicionamos aos nossos projetos. Isso é verdade, mas o software supply chain tem um escopo muito mais amplo.

O IDE também é um elemento crucial do seu fluxo de desenvolvimento de software, não é? Qual seria o nível de risco para sua empresa se o seu favorito IDE tivesse backdoors ou malware? E se uma extensão ou plug-in de IDE tivesse vulnerabilidades ou incluísse código malicioso?

Vulnerabilidades em extensões VS Code

As extensões VS Code vulneráveis não são apenas uma preocupação teórica. Em maio de 2021, a Snyk encontrou vulnerabilidades de segurança no supply chain em extensões do Visual Studio Code, no marketplace de extensões VS Code, que afetam mais de dois milhões de desenvolvedores, com base no número de downloads.

Essas extensões VS Code, como Open in Default Browser, com mais de 520.000 downloads, e o Instant Markdown, com mais de 120.000 downloads, representam uma ameaça real para os desenvolvedores. Se os desenvolvedores forem enganados por um invasor e clicarem em um link, poderão inserir uma vulnerabilidade transversal do caminho que expõe o acesso a arquivos e informações confidenciais no ambiente de desenvolvimento. Em casos mais graves de vulnerabilidade, basta os desenvolvedores clicarem em um link para disponibilizar uma execução de comando remota é disponibilizada aos violadores.

O vídeo a seguir ilustra um exploit da extensão Instant Markdown do VS Code e como ela rouba chaves SSH confidenciais de um desenvolvedor, demonstrando por que a segurança da SBOM do supply chain software é uma preocupação crucial para os desenvolvedores.

Vulnerabilidades de segurança que afetam Java IDE

Se você acha que supply chain secuirty gera caos no ecossistema de JavaScript, vou compartilhar a linha do tempo da ENISA com 24 incidentes de segurança da cadeia de suprimentos em um período de 18 meses (de janeiro de 2020 a julho de 2021), que inclui casos de incidentes maliciosos que afetaram desenvolvedores de Java pelo IDE NetBeans:

Como manter a segurança da SBOM de código aberto

Então, como fazemos para mitigar as preocupações com o software supply chain security em todo o ciclo de vida de desenvolvimento de software (SDLC)? Manter uma SBOM atualizada é um bom primeiro passo, ainda mais agora que se tornou obrigatório pela ordem executiva do governo dos EUA devido às imensas ameaças causadas pelos componentes de software de código aberto a empresas e governos.

Além das ameaças causadas pelas vulnerabilidades de segurança conhecidas e pelos possíveis atos maliciosos de zero-days, um aspecto importante da segurança supply chain de código aberto é a integridade geral dos pacotes. Sinais relacionados à cadência de entregas e lançamentos do projeto, à contagem de problemas abertos e à comunidade de pessoas envolvidas afetam a pontuação geral de integridade dos pacotes, podendo oferecer uma orientação sobre a manutenção do projeto e indicar se ele está suscetível a atividades maliciosas.

A Snyk desenvolveu o Snyk Advisor para resolver exatamente esse problema para considerações sobre pontuações de integridade de pacotes referentes à segurança supply chain de softwares de código aberto. Essa solução aceita metadados de ecossistemas como JavaScript, Go, Python e imagens de contêiner baseados em Docker, e recomendamos consultá-la na sua busca por bibliotecas de código aberto.

Como gerar uma SBOM de código aberto com a Snyk

O Snyk Open Source opera com manifestos de pacotes e lockfiles para criar um gráfico completo de dependências que ajuda a identificar vulnerabilidades na hierarquia ou outros problemas como pacotes descontinuados. No entanto, isso por si só não é uma SBOM.

Gareth Rushgrove, vice-presidente de produto na Snyk, escreveu sobre o avanço dos padrões da SBOM com a Snyk e a SPDX. No artigo, Gareth fala sobre como a Snyk desenvolveu diferentes maneiras de trabalhar com ferramentas criadas pela comunidade e destaca o snyk2spdx, um projeto de código aberto que converte o produto da CLI da Snyk para o formato SPDX.

Se você gosta do Snyk API, Gareth também destaca seu uso para buscar o manifesto do pacote associado e detalhes das vulnerabilidades como origem do uso, que depois podem ser convertidos para SPDX.

Em resumo, exigir o uso de uma SBOM como parte do desenvolvimento de software e processo de entrega é um elemento importante das preocupações de seguranca supply chain. pois ajuda a responder a questões sobre inventário, integridade e procedência.

Recomendamos os artigos a seguir para aprofundar o conhecimento sobre segurança supply chain em listas de materiais de software de código aberto.

• Entenda os requisitos de segurança de software supply chain referenciados na ordem executiva de segurança cibernética dos EUA, de Daniel Berman

• Para saber mais sobre a comparação de licenças, confira Licenças Open Source: tipos e comparação

• Gerenciamento da conformidade com licenças na sua organização com as políticas de licença da Snyk, de Josepha Riveros

• Consulte o gerenciamento prático de políticas de licenças na plataforma da Snyk na documentação da Snyk