Crie uma lista de materiais de software (SBOM) para proteger a cadeia de suprimentos de software de código aberto

Mais do que nunca, desenvolvedores criam aplicações web com base em bibliotecas de software de código aberto. No entanto, embora essas bibliotecas componham o inventário de componentes da lista de materiais de software (SBOM), nem todos os desenvolvedores e stakeholders do negócio entendem o impacto significativo que a inclusão de bibliotecas de terceiros tem na segurança da cadeia de suprimentos de software. Pensando nisso, vamos explorar a segurança de SBOMs e a importância de monitorá-las nas aplicações que você desenvolve.

A preocupação com a segurança da cadeia de suprimentos de software tem se tornado um dilema cada vez maior para organizações e governos. O relatório Cenário de ameaças de ataques à cadeia de suprimentos, publicado pela Agência da União Europeia para a Cibersegurança (ENISA), estimou um aumento de 400% nos ataques à cadeia de suprimentos de software em 2021.

O uso massivo de software de código aberto disponível para desenvolvedores hoje e a facilidade de importar componentes de software aumentam o nível de risco devido a questões de segurança e jurídicas para o desenvolvedor e, consequentemente, para a empresa. Por isso, é importante capacitar desenvolvedores e equipes de segurança e oferecer a eles soluções avançadas de segurança da cadeia de suprimentos.

Antes de avançarmos, vamos conferir alguns conceitos básicos de SBOM e esclarecer os termos técnicos usados neste artigo.

O que é uma lista de materiais de software?

Uma lista de materiais de software, geralmente chamada de SBOM, é uma lista completa de todos os componentes de software usados em uma organização. Essa lista é composta por bibliotecas de código aberto de terceiros, pacotes fornecidos por fornecedores e artefatos próprios desenvolvidos pela organização.

Por que preciso criar uma SBOM?

Uma SBOM é, essencialmente, um inventário de todos os componentes de software usados nas suas aplicações. Sem ela, você não tem visibilidade dos riscos de licença e segurança associados ao software que desenvolve ou consome. Manter uma lista de materiais de software atualizada e em conformidade com o formato SBOM também é essencial para acompanhar o ritmo acelerado do desenvolvimento de software, em que componentes e suas versões mudam rapidamente.

O que é o CycloneDX?

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

Questões de segurança que levam desenvolvedores a manter uma lista de materiais de software

A expressão “lista de materiais de software” não costuma fazer parte do vocabulário dos desenvolvedores. Tradicionalmente, essa era uma atividade reservada às equipes de segurança e avaliação de riscos das organizações. Mas isso mudou com o enorme crescimento do uso de componentes de software de código aberto, como mostra o registro de pacotes npm, que conta com mais de 1.800.000 pacotes gratuitos e de código aberto.

Se você é desenvolvedor e não entende por que precisa de uma SBOM para todos os componentes de software que usa, basta lembrar de alguns incidentes de segurança de grande repercussão ocorridos nos últimos anos por causa de bibliotecas de software de código aberto:

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

2. Log4Shell: foi encontrada uma vulnerabilidade grave de execução remota de código na popular biblioteca de registro do Java Log4j. Essa vulnerabilidade existia havia sete anos antes de ser descoberta!

Quando essas vulnerabilidades ou incidentes de segurança são descobertos e acontecem, e sua aplicação usa uma dessas versões vulneráveis, quem você acha que é responsável por atualizar essas bibliotecas e publicar uma nova versão? Isso mesmo: os desenvolvedores.

Mesmo que a equipe de segurança cuide da própria parte e mantenha a lista de materiais de software por conta própria, quando identifica problemas, ela alerta as equipes necessárias e procura os desenvolvedores para atualizar as versões vulneráveis. Mas, em um mundo com gerenciamento avançado de fluxos de trabalho, não podemos automatizar todo esse processo e integrá-lo de forma mais natural aos fluxos de trabalho dos desenvolvedores? Claro que sim. É isso que a Snyk, que é gratuita, oferece.

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

Hoje, os aspectos jurídicos do uso de software provavelmente não estão entre as preocupações dos desenvolvedores quando eles experimentam com o código e criam aplicações. Mas, algumas décadas atrás, era diferente. Desenvolvedores e suas equipes prestavam muita atenção à licença específica dos componentes de software que incorporavam ao código. O que mudou? Naquela época, as licenças mais comuns eram do tipo copyleft, como a GNU General Public License (GPL), que impunha várias restrições à distribuição de software. Em resumo, a GPL tem um efeito cascata: qualquer código criado com um componente licenciado sob GPL também passa automaticamente a ser licenciado sob GPL — algo que você deve levar em conta ao criar seu modelo de negócio.

Cerca de 20 anos depois, vimos uma grande mudança em relação às licenças copyleft. Em 2015, a licença mais comum nos repositórios de código aberto criados no GitHub era a licença MIT. Junto com outras licenças, a MIT faz parte de uma família de licenças permissivas, que eliminam muitas das restrições sobre como o software pode ser usado e ampliam as liberdades de quem usa software licenciado dessa forma.

Vivemos um momento na história do software de código aberto marcado por um crescimento expressivo na adoção e na contribuição de novos softwares com licenças bastante permissivas. Será que nos acostumamos a usar software de código aberto como padrão? Será que passamos a considerar as licenças de código aberto como algo garantido?

Dois casos muito conhecidos de questões jurídicas relacionadas às licenças dos próprios projetos preocupam os desenvolvedores:

1. O React, a popular biblioteca de visualização de código aberto para JavaScript, mudou de licença: deixou sua própria versão da “BSD + Patents grant” e adotou a licença permissiva MIT, depois que a Apache Software Foundation baniu o projeto React por considerar a licença do Facebook restritiva demais. A mudança também foi motivada pela pressão de desenvolvedores do mundo todo, que cogitaram abandonar o projeto e migrar para alternativas como o Preact. Quincy Larson reuniu uma linha do tempo útil dos acontecimentos neste artigo do freeCodeCamp.

2. A Elastic, empresa e projeto de código aberto por trás da popular ferramenta de busca e do ELK Stack, também precisou lidar com mudanças de licença devido ao aumento da concorrência com provedores de nuvem e ao impacto disso nos negócios da Elastic.

Como desenvolvedor que usa React, Elastic ou outras bibliotecas de software de código aberto, provavelmente caberá a você planejar a migração de um projeto para outro quando surgirem problemas com licenças.

Além disso, o que acontece se você criar aplicações e distribuir software que inclua componentes aninhados com licença copyleft? Os ecossistemas JavaScript e Node.js são conhecidos pelo grande número de pacotes npm instalados. O risco para a empresa é real e merece sua atenção como desenvolvedor: você precisa rastrear e entender quais licenças de software são usadas nos seus projetos.

As aplicações que você cria e o software que consome provavelmente já incluem referências à licença utilizada. Por exemplo, se você está criando um projeto 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 neste arquivo package.json usa o formato comum de SBOM chamado SPDX, para garantir a conformidade com padrões internacionais e de interoperabilidade entre ferramentas.

O que é SPDX?

O Software Package Data Exchange (SPDX) é um projeto colaborativo da Linux Foundation que oferece um padrão de formato comum para SBOMs, facilitando a criação de relatórios interoperáveis com diversas ferramentas. Mais especificamente, a lista de licenças SPDX fornece identificadores padronizados para as licenças, acompanhados de um URL canônico para cada uma.

A página da lista de licenças SPDX a seguir apresenta a lista completa de licenças e seus identificadores:

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

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

Organizações de engenharia maduras deixam para trás o uso oportunista e ocasional de bibliotecas de código aberto e passam a adotá-las de forma intencional e planejada nos projetos, seguindo diretrizes e boas práticas.

Por exemplo, equipes de desenvolvimento JavaScript podem querer garantir que os desenvolvedores de diferentes equipes padronizem o uso de uma única dependência para requisições HTTP, em vez de depender de várias, como os pacotes npm request, axios, node-fetch e outros. O motivo não é apenas facilitar o gerenciamento das dependências de código aberto, mas também centralizar o conhecimento e a experiência em APIs, simplificar a resolução de problemas e muito mais.

Para qualquer equipe de desenvolvimento, você consegue responder com confiança às seguintes perguntas?

• Quais bibliotecas de código aberto são mais usadas em todos os projetos da minha organização de P&D?

• Quais bibliotecas de código aberto que uso foram marcadas como obsoletas?

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

• Quais bibliotecas de código aberto foram publicadas há mais de 15 anos e não receberam nenhuma atualização? Isso deveria preocupar você?

Esses e muitos outros insights são benefícios de manter uma lista de materiais de software, ou SBOM. A Snyk também disponibiliza informações valiosas sobre a integridade dos pacotes de código aberto como parte dos recursos do Snyk Open Source:

Por que a SBOM acelera sua preparação para proteger a cadeia de suprimentos?

O que é segurança da cadeia de suprimentos de software?

As preocupações tradicionais com a segurança de aplicações no ciclo de vida de desenvolvimento seguro de software deixaram de se limitar ao código criado pelo desenvolvedor e passaram a abranger toda a infraestrutura de ferramentas usada para criar software. Isso cria uma superfície de ataque extremamente ampla, que vai desde a primeira etapa, com a ferramenta de IDE usada para escrever código, passando pelos componentes de código aberto usados para criar aplicações, até os pipelines de CI/CD e a configuração da infraestrutura de implantação. Na verdade, é possível argumentar que os riscos à segurança da cadeia de suprimentos se estendem até os chips de hardware do computador usado como ambiente de desenvolvimento.

O Departamento de Comércio dos Estados Unidos publicou um documento em cumprimento à Ordem Executiva 14028 sobre o aprimoramento da cibersegurança nacional, que cita Os elementos mínimos para uma lista de materiais de software (SBOM). Vamos explorar melhor essa história sobre a cadeia de suprimentos e ver o que podemos aprender com ela.

A cadeia de suprimentos de software é, essencialmente, o conjunto de todos os componentes que fazem parte do fluxo de trabalho completo de desenvolvimento de software. A princípio, você pode pensar que ela se resume às dependências adicionadas aos seus projetos. Isso é verdade, mas a cadeia de suprimentos de software vai muito além disso.

Seu IDE também é uma parte fundamental do fluxo de trabalho de desenvolvimento de software, certo? Que riscos isso representaria para a empresa se o seu IDE favorito tivesse backdoors ou malware? E se uma das extensões ou dos plugins do IDE apresentasse vulnerabilidades graves ou até mesmo incluísse código malicioso?

Vulnerabilidades em extensões do VS Code

As vulnerabilidades em extensões do VS Code não são apenas uma preocupação teórica. Em maio de 2021, a Snyk descobriu vulnerabilidades na segurança da cadeia de suprimentos em extensões do Visual Studio Code disponíveis no marketplace de extensões do VS Code, que, com base no número de downloads, afetavam mais de 2.000.000 de desenvolvedores.

Essas extensões do VS Code, como Open in Default Browser, com mais de 520.000 downloads, ou Instant Markdown, com mais de 120.000 downloads, representam uma ameaça real para os desenvolvedores. Se um invasor induzir um desenvolvedor a clicar em um link, poderá explorar uma vulnerabilidade de path traversal para acessar arquivos e informações confidenciais no ambiente de desenvolvimento. Em casos mais graves, basta o desenvolvedor clicar em um link para que invasores consigam executar comandos remotamente.

O vídeo a seguir mostra por que a segurança de SBOMs na cadeia de suprimentos de software é uma preocupação fundamental para desenvolvedores. Nele, você verá a exploração da extensão Instant Markdown do VS Code e como ela rouba chaves SSH confidenciais de um desenvolvedor:

Vulnerabilidades de segurança que afetam IDEs Java

Se você acha que a segurança da cadeia de suprimentos está causando estragos no ecossistema JavaScript, confira a cronologia da ENISA com 24 incidentes de segurança na cadeia de suprimentos ocorridos em apenas 18 meses (de janeiro de 2020 a julho de 2021). Ela inclui casos de incidentes maliciosos que afetaram desenvolvedores Java por meio do IDE NetBeans:

Como manter um SBOM seguro de código aberto

Então, como reduzir os riscos à segurança da cadeia de suprimentos de software ao longo de todo o ciclo de vida de desenvolvimento de software (SDLC)? Manter um SBOM atualizado é um ótimo começo e também uma exigência estabelecida por uma ordem executiva do governo dos EUA, em resposta às enormes ameaças que os componentes de software de código aberto representam para empresas e governos.

Um aspecto importante da segurança da cadeia de suprimentos de código aberto não é apenas o panorama de ameaças, que inclui vulnerabilidades conhecidas e possíveis ataques de dia zero, mas também a integridade geral dos pacotes. Indicadores como a frequência de commits e lançamentos do projeto, o número de problemas em aberto e a comunidade de colaboradores ajudam a compor a pontuação de integridade do pacote. Esses indicadores orientam a avaliação da manutenção geral do projeto e de sua suscetibilidade a atividades maliciosas.

A Snyk criou o Snyk Advisor para resolver esse problema específico na avaliação da integridade de pacotes para a segurança da cadeia de suprimentos de software de código aberto. Atualmente, ele oferece suporte a metadados de ecossistemas como JavaScript, Go e Python, além de imagens de contêiner baseadas em Docker. Recomendamos consultá-lo ao procurar bibliotecas de código aberto.

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

O Snyk Open Source analisa manifestos de pacotes e arquivos de lock para criar um grafo completo de dependências, o que ajuda a identificar vulnerabilidades na hierarquia e outros problemas, como pacotes obsoletos. No entanto, isso, por si só, não constitui um SBOM.

Gareth Rushgrove, vice-presidente de Produto da Snyk, escreveu sobre como avançar os padrões de SBOM com a Snyk e o SPDX. No artigo, Gareth conta que a Snyk está explorando diferentes formas de trabalhar com ferramentas da comunidade e destaca o snyk2spdx, um projeto de código aberto que converte a saída da CLI da Snyk para o formato SPDX.

Se você gosta da API da Snyk, Gareth também recomenda usá-la para buscar manifestos de pacotes e detalhes de vulnerabilidades como fonte de consumo, que podem ser convertidos para SPDX.

Em resumo, exigir um SBOM como parte do processo de desenvolvimento e entrega de software é essencial para lidar com os desafios atuais de segurança da cadeia de suprimentos. Ele ajuda a responder a questões que vão do inventário à integridade e à procedência.

Recomendamos os artigos a seguir para você aprofundar seus conhecimentos sobre segurança da cadeia de suprimentos de código aberto e lista de materiais de software:

• Entenda os requisitos de segurança da cadeia de suprimentos de software da ordem executiva de cibersegurança, por Daniel Berman

• Para uma análise detalhada da comparação entre licenças, consulte a documentação Licenças de código aberto: tipos e comparação

• Gerencie a conformidade de licenças em toda a sua organização com as políticas de licença da Snyk, por Josepha Riveros

• Conheça uma abordagem prática para o gerenciamento de políticas de licença na plataforma Snyk na documentação da Snyk