A Lista de Materiais de Software (SBOM) é uma lista de todos os componentes, bibliotecas e outras dependências usadas em um aplicativo de software. Os formatos padrão para SBOMs incluem SPDX, CycloneDX e CPE (Common Platform Enumeration). Esses formatos fornecem uma maneira estruturada de representar os componentes e as dependências de um aplicativo de software, facilitando a compreensão e o gerenciamento dos riscos de segurança associados a esses componentes.
Neste artigo, explicaremos — em detalhes — quais são os vários formatos e padrões do SBOM, o que um SBOM deve incluir e por que todas as organizações precisam usá-lo.
O que é um padrão SBOM?
A complexidade e a natureza dinâmica das cadeias de abastecimento de sistemas de software modernos representam um desafio significativo à transparência. Esta falta de transparência contribui para riscos de segurança cibernética e aumenta os custos associados ao desenvolvimento, aquisição e manutenção. As consequências disto são de grande alcance, afectando não só as empresas, mas também questões colectivas, como a segurança pública e a segurança nacional no nosso mundo interligado.
O aumento da transparência nas cadeias de fornecimento de software pode levar a uma redução dos riscos e custos de segurança cibernética ao:
- Melhorar a identificação de sistemas vulneráveis e identificar a causa raiz dos incidentes
- Diminuindo o trabalho não planejado e improdutivo
- Permitindo uma diferenciação de mercado e seleção de componentes mais informada
- Padronização de formatos em vários setores, levando a uma redução na duplicação de esforços
- Detecção de componentes de software suspeitos ou falsificados
A recolha e partilha destas informações num formato claro e consistente pode ajudar a reduzir custos, melhorar a fiabilidade e aumentar a confiança na nossa infraestrutura digital.
Para aquele propósito, o Grupo de Trabalho de Transparência de Software da NTIA sobre Padrões e Formatos foi criada em 2018 para avaliar os formatos atuais de listas de materiais de software e identificar possíveis usos futuros. O grupo examinou padrões e iniciativas existentes relacionadas à identificação de componentes externos e bibliotecas compartilhadas usadas em produtos de software e à comunicação dessas informações em um formato legível por máquina. O grupo não considerou formatos proprietários. A pesquisa original foi divulgada no final de 2019 e atualizada em 2021, com foco em destacar os benefícios do ecossistema de ferramentas SBOM e a importância da coordenação e harmonização no mundo técnico SBOM. A principal conclusão é que os dados SBOM podem ser transmitidos em vários formatos e o ecossistema deve apoiar a interoperabilidade entre eles.
O grupo de trabalho descobriu que três formatos são comumente usados:
- Software Package Data Exchange (SPDX®), um formato de código aberto e legível por máquina desenvolvido pela Linux Foundation e agora um padrão ISO/IEC
- CycloneDX (CDX), um formato de código aberto e legível por máquina desenvolvido pela comunidade OWASP
- Identificação de Software (SWID), um padrão industrial ISO/IEC usado por vários editores de software comercial
Vale a pena notar que estes três formatos compartilham algumas informações comuns. No entanto, eles têm sido tradicionalmente utilizados em diferentes estágios do processo de desenvolvimento de software e são destinados a públicos distintos. Discutiremos cada um desses formatos detalhadamente neste artigo.
O que um SBOM deve incluir?
Os componentes mínimos da NTIA de um SBOM, denominados elementos, consistem em três áreas amplas e inter-relacionadas. Esses elementos permitem uma abordagem flexível à transparência do software, abordando tanto a tecnologia quanto a operação funcional. Mais detalhes ou avanços técnicos podem ser adicionados no futuro. Conforme mencionado anteriormente, estes são os componentes mínimos atualmente e as organizações podem exigir mais. A capacidade de transparência na cadeia de fornecimento de software pode melhorar e evoluir ao longo do tempo.
Este elementos mínimos exigidos para SBOM são normalmente agrupados em três categorias:
- Campos de dados: Um SBOM deve incluir dados importantes sobre componentes de software, como nome do componente, nome do fornecedor, versão e identificadores exclusivos. Deve também incluir informações sobre dependências entre componentes, permitindo a identificação e rastreamento precisos de todos os componentes de software ao longo da cadeia de abastecimento.
- Práticas e processos: A documentação do SBOM também deve descrever práticas e procedimentos padrão para criar e atualizar o SBOM, distribuí-lo e acessá-lo, bem como lidar com erros.
- Suporte de automação: A lista de materiais do software deve ser legível por máquina e poder ser gerada automaticamente para rastreamento contínuo de dados. Normalmente está em formatos padrão como tags SPDX, CycloneDX e SWID, que também os tornam legíveis para humanos.
Formato padrão SPDX SBOM
A especificação SPDX® (Software Package Data Exchange) é um padrão ISO/IEC para compartilhar informações sobre componentes de software, licenças, direitos autorais e detalhes de segurança em vários formatos de arquivo. Este projeto desenvolveu e continua a melhorar um conjunto de padrões de troca de dados que permitem às empresas e organizações partilhar metadados de software num formato que pode ser compreendido tanto por humanos como por máquinas, simplificando os processos da cadeia de fornecimento de software.
As informações SPDX podem ser vinculadas a produtos de software específicos, componentes ou conjuntos de componentes, arquivos individuais ou até mesmo pequenos trechos de código. O projeto SPDX está focado na criação e no refinamento de uma linguagem para descrever os dados que podem ser trocados como parte de um SBOM e na capacidade de apresentar esses dados em vários formatos de arquivo (RDF/XML, XLSX, tag-value, JSON, YAML , e XML) para facilitar a coleta e o compartilhamento de informações sobre pacotes de software e conteúdo relacionado, resultando em melhorias de tempo e precisão.
A especificação SPDX descreve os campos e seções necessários para um documento válido, mas é importante observar que nem todas as seções são obrigatórias – apenas a seção de informações de criação é obrigatória. O criador do documento pode escolher quais seções e campos deseja incluir, que descrevem o software e as informações de metadados que planejam compartilhar.
O SPDX pode capturar com eficácia dados de lista de materiais de software, representando todos os componentes encontrados no desenvolvimento e implantação de software. Ele é usado para documentar imagens de distribuição .iso, contêineres, pacotes de software, arquivos binários, arquivos de origem, patches e até mesmo pequenos trechos de código incorporados em outros arquivos. O SPDX oferece um conjunto abrangente de relacionamentos para conectar elementos de software em documentos e entre documentos SBOM. Um documento SPDX SBOM também pode fazer referência a fontes externas, como o Banco de Dados Nacional de Vulnerabilidades e outros metadados do sistema de empacotamento.
Existem vários componentes que compõem um documento SPDX: informações de criação, informações de pacote, informações de arquivo, informações de snippet, outras informações de licenciamento, relacionamentos e anotações.
Cada documento SPDX pode ser representado por uma implementação completa de modelo de dados e sintaxe de identificador, permitindo a troca entre diferentes formatos de saída de dados (RDF/XML, tag-value, XLSX) e validação formal da precisão do documento. O lançamento da versão 2.2 da especificação SPDX inclui formatos de saída adicionais, como JSON, YAML e XML, e também aborda “incógnitas conhecidas” conforme identificado no documento SBOM original. Mais informações sobre o modelo de dados subjacente do SPDX podem ser encontradas no Apêndice III da Especificação SPDX e no site do SPDX.
Formato padrão CycloneDX SBOM
O projeto CycloneDX foi estabelecido em 2017 com o objetivo de desenvolver um padrão SBOM totalmente automatizado e focado em segurança. O grupo de trabalho principal lança anualmente versões imutáveis e compatíveis com versões anteriores, usando um processo de padrões baseado em risco. CycloneDX inclui especificações existentes, como URL do pacote, CPE, SWID e IDs e expressões de licença SPDX. Os SBOMs podem ser representados em diferentes formatos, incluindo XML, JSON e Protocol Buffers (protobuf).
CycloneDX é uma especificação SBOM leve destinada ao uso na análise de componentes da cadeia de suprimentos e segurança de software. Ele permite a comunicação do inventário de componentes de software, serviços externos e os relacionamentos entre eles. É um padrão de código aberto desenvolvido pelo OWASP (Open Web Application Security Project).
CycloneDX pode capturar a natureza dinâmica de componentes de código aberto cujo código-fonte é acessível, modificável e redistribuível. A especificação pode representar o pedigree de um componente, incluindo seus ancestrais, descendentes e variantes, descrevendo a linhagem do componente de qualquer perspectiva, bem como os commits, patches e diferenças que o tornam único.
O projeto CycloneDX mantém uma lista de ferramentas proprietárias e de código aberto conhecidas que suportam ou são compatíveis com o padrão, que é apoiado pela comunidade.
A especificação CycloneDX apresenta um modelo de objeto detalhado que garante consistência em todas as implementações. Ele pode ser validado usando XML Schema e JSON Schema ou usando a interface de linha de comando CycloneDX. Os tipos de mídia para XML e JSON também são fornecidos para entrega e consumo automatizados de formatos suportados.
Os SBOMs CycloneDX podem conter as seguintes informações: Metadados da BOM, componentes, serviços, dependências, composições e extensões
CycloneDX é um padrão SBOM abrangente que pode caracterizar vários tipos de software, incluindo aplicativos, componentes, serviços, firmware e dispositivos. É amplamente utilizado em todos os setores para descrever pacotes de software, bibliotecas, estruturas, aplicativos e imagens de contêineres. O projeto é compatível com os principais ecossistemas de desenvolvimento e oferece implementações para fábricas de software, como ações do GitHub, permitindo que as organizações automatizem totalmente a criação de SBOM.
Etiqueta SWID
Tags SWID, ou tags de identificação de software, foram criadas para permitir que as organizações rastreiem software instalado em seus dispositivos gerenciados de maneira transparente. O padrão foi estabelecido pela ISO em 2012 e revisado como ISO/IEC 19770-2:2015 em 2015. Essas tags contêm informações detalhadas sobre uma versão específica de um produto de software.
O padrão SWID descreve um ciclo de vida para software de rastreamento: uma etiqueta SWID é adicionada a um terminal durante a instalação de um produto de software e removida pelo processo de desinstalação do produto. A existência de uma Tag SWID específica corresponde diretamente à presença do software que ela descreve. Várias organizações de padronização, como o Trusted Computing Group (TCG) e a Internet Engineering Task Force (IETF), incorporam tags SWID em seus padrões.
Para rastrear o ciclo de vida de um componente de software, a especificação SWID possui quatro tipos de tags: primária, patch, corpus e suplementar. As tags Corpus, primárias e de patch servem a propósitos semelhantes, pois descrevem a existência e a presença de diferentes tipos de software, como instaladores de software, instalações de software e patches de software, e os possíveis estados dos produtos de software. Por outro lado, tags suplementares fornecem detalhes adicionais não encontrados em tags corpus, primárias ou patch.
Tags suplementares podem ser vinculadas a qualquer outra tag para fornecer metadados extras que podem ser úteis. Juntas, as tags SWID podem executar uma variedade de funções, como descoberta de software, gerenciamento de configuração e gerenciamento de vulnerabilidades.
As tags SWID podem funcionar como um SBOM, pois fornecem informações de identificação para um componente de software, uma lista de arquivos e hashes criptográficos para os artefatos do componente e informações de procedência sobre o criador do SBOM (tag) e o criador do componente de software. As tags também podem ser vinculadas a outras tags, permitindo a representação de uma árvore de dependências.
Tags SWID podem ser geradas durante o processo de construção e empacotamento, permitindo a criação automática de um SBOM baseado em tag SWID quando o componente de software correspondente é empacotado.
Por que as listas de materiais de software são importantes?
A Lista de Materiais de Software (SBOMs) está se tornando cada vez mais importante para as organizações, pois elas visam gerenciar e proteger o software que usam. Não há uma resposta curta para a questão de o que é um SBOM. Os SBOMs fornecem uma lista abrangente de todos os componentes e dependências que compõem um pacote de software, incluindo informações como números de versão, autores e informações de licença. Essas informações são essenciais para segurança e conformidade, bem como para rastrear a procedência dos componentes de software.
Muitas organizações, incluindo aquelas em setores regulamentados, estão usando SBOMs para garantir a conformidade com regulamentações como o Regulamento Geral de Proteção de Dados (GDPR) e o Padrão de Segurança de Dados da Indústria de Cartões de Pagamento (PCI DSS). Os SBOMs também podem ajudar na identificação e gerenciamento de vulnerabilidades em software, bem como no rastreamento da origem dos componentes de software. Além disso, os SBOMs podem auxiliar no gerenciamento de licenças de software, garantindo que as organizações utilizem o software em conformidade com os termos de suas licenças.
Os SBOMs também podem ser usados para rastrear o uso de software de código aberto, que está se tornando cada vez mais comum no desenvolvimento de software. Ao fornecer informações detalhadas sobre os componentes de código aberto usados em um pacote de software, os SBOMs podem ajudar as organizações a garantir a conformidade com licenças de código aberto.
Além disso, os SBOMs podem ser usados para apoiar o desenvolvimento e manutenção de software. Ao fornecer informações detalhadas sobre os componentes usados em um pacote de software, os SBOMs podem ajudar os desenvolvedores a compreender as dependências de um pacote de software, o que pode ajudá-los a identificar possíveis problemas de compatibilidade e a tomar decisões informadas sobre o uso de novos componentes.