Nos últimos anos, as pessoas tornaram-se cada vez mais conscientes dos riscos inerentes ao uso de componentes de código aberto em seus softwares. Considerando que a maior parte do software é uma mistura de código aberto e lógica proprietária, saber quais ingredientes foram importados de fora, direta ou transitoriamente, é essencial para o gerenciamento adequado de riscos do produto de software final. Como os dias de rastreamento de ingredientes usando planilhas complicadas já se foram e são lamentavelmente ineficientes, a principal maneira de realizar esse rastreamento é utilizando um SBOM – uma lista de materiais de software. Como outras listas de materiais, é essencialmente uma lista dos ingredientes de software a partir dos quais o software é construído, com a adição das relações entre os diferentes ingredientes, com foco especial em quais componentes dependem uns dos outros.
Existem dois formatos principais de SBOM usados no mercado hoje: SPDX e CycloneDX.
Troca de dados de pacote de software (SPDX) é um projeto SBOM de código aberto e legível por máquina da fundação Linux. A versão mais recente do SPDX foi projetada de acordo com o padrão da NTIA para 'Elementos mínimos para uma lista de materiais de software.' Ele lista os componentes, direitos autorais, licenças e referências de segurança de um software.
CicloneDX (CDX) também é um formato SBOM de código aberto e legível por máquina desenvolvido pela comunidade Open Web Application Security Project (OWASP). Como formato BOM, o CycloneDX possui outras aplicações além da preparação de listas de materiais de software. Também pode ser usado para compilar componentes, vulnerabilidades e serviços de hardware e sistemas em nuvem.
Por que o SBOM é importante?
O SBOM é extremamente útil para equipes de desenvolvimento de software, organizações de compras e usuários finais. Usá-lo pode ajudar a garantir que os componentes de código aberto e de terceiros estejam atualizados e oferece visibilidade sobre quais dependências do projeto têm vulnerabilidades conhecidas que podem ser exploradas em seu software. Os compradores de software, por outro lado, podem utilizar SBOMs para analisar o risco inerente a um produto através de avaliações de vulnerabilidade.
As organizações seriam melhor servidas se colaborassem com os seus fornecedores para garantir que estes tenham acesso a informações corretas e atualizadas sobre os componentes do projeto que são implementados em sistemas e/ou produtos. Eles também devem avaliar seus SBOMs regularmente para ajudar a minimizar os riscos da utilização de componentes de código aberto e de terceiros.
Amostras SBOM
Dependendo do formato SBOM utilizado, pode haver diferenças nos componentes do SBOM. dependendo do tamanho e da complexidade do seu projeto, um arquivo JSON SBOM pode facilmente chegar a milhares de linhas ou mais. Como examinar um arquivo de mil linhas não é muito informativo, vamos usar exemplos existentes e mais simples para ver o que cada formato SBOM inclui. Analisaremos mais de perto amostras dos dois principais formatos no mercado hoje.
SPDX
O exemplo SPDX SBOM que seguiremos pode ser encontrado aqui.
O JSON começa com informações gerais sobre o próprio arquivo – metadados.
Depois disso, obtemos os metadados sobre o software que estamos examinando:
Observe a soma de verificação e seu valor. Cada seção do SBOM inclui a criptografia e o resultado da parte em questão para que as pessoas que examinam o arquivo possam ter certeza de que o software ou componente mencionado é idêntico ao que estão vendo.
Sem essa garantia, você poderia facilmente encontrar múltiplas cópias com o mesmo nome de componentes ou software e não teria ideia de qual dessas versões foi verificada ou incluída no software ou no SBOM que o descreve.
Seguindo a descrição do software verificado podemos começar a ver os componentes:
Você pode ver vários campos incluídos para descrever a licença de um componente, sua página inicial, versão, nome completo, etc.
Outra coisa que você pode encontrar no formato SPDX são as anotações – adições feitas posteriormente a uma seção e incluem mais informações e às vezes até texto livre:
Para saber mais sobre este formato e suas capacidades, você pode visitar o Página SPDX da Fundação Linux.
CicloneDX
O formato CycloneDX SBOM pode ser descrito em um arquivo JSON, um arquivo XML ou em buffers de protocolo. Para manter as coisas uniformes e simples, seguiremos um exemplo JSON simplificado do CycloneDX. O exemplo descrito pode ser encontrado aqui.
O JSON começa com informações gerais de metadados sobre o arquivo.
Em seguida, os metadados do software foram examinados:
Depois disso, os componentes de software e suas dependências:
Tenha em atenção que este é um exemplo simplificado e que o formato pode incluir muitas outras informações. Para uma visão mais abrangente dos vários casos de uso, você pode conferir a página de casos de uso do OWASP CyclonDX aqui.
Aqui está um exemplo dessa página que demonstra a construção de uma lista de dependências:
E aqui está uma descrição mais abrangente dos vários componentes deste formato retirado do OWASP Capacidades de lista de materiais página:
Como usar um SBOM
Não se sinta mal se não conseguir acompanhar os exemplos de arquivos vistos aqui. Embora os arquivos JSON sejam eminentemente legíveis por humanos, eles são muito mais adequados para serem legíveis por máquina, para que softwares especializados possam ingerir as informações e cuspir os resultados que a análise fornece.
Você pode usar uma lista de componentes de software para verificar se ela não inclui licenças de código aberto indesejadas (linha GPL3.0 ou MPL1.1). Você pode verificar uma lista de dependências regularmente para ver se há alguma atualização disponível ou verificar os nomes dos pacotes em bancos de dados de vulnerabilidades para saber quais dependências problemáticas seu software inclui.
Pode parecer complicado ingerir um SBOM e recuperar todas essas informações, mas lembre-se de que você não precisa fazer tudo sozinho. Serviços como a plataforma Scribe Security podem eliminar muitas dores de cabeça e oferecer muito mais benefícios. Sinta-se à vontade para conferir nossa plataforma e ver de que outra forma você pode gerenciar seus riscos usando nosso sistema de monitoramento contínuo ao longo de seu ciclo de vida de desenvolvimento e produtos finais.