O que é uma SBOM?
Software bill of materials (SBOM) é uma lista que reúne todos os componentes, bibliotecas e módulos usados em soluções de software, organizados em um formato que outros programas conseguem ler. Pense nisso como uma lista de ingredientes de uma receita.
Por que as organizações precisam de uma SBOM?
A maior parte dos software moderno é desenvolvida a partir da combinação de diversos componentes pré-criados fornecidos por terceiros, como bibliotecas de código. Quando você integra um grande número de componentes, as coisas podem se complicar.
Criar e manter uma SBOM permite saber a versão, a licença e as dependências de cada um desses componentes e o que mudou neles ao longo do tempo. Uma SBOM é um documento dinâmico que serve como source of truth para identificar e evitar riscos de segurança e cumprir as exigências de conformidade.
Ela estabelece o que compõe cada solução, e por isso é tão relevante para todos que atuam durante o ciclo de vida do software, como:
- Desenvolvedores e fabricantes do software: podem verificar se os componentes estão atualizados e atendem às suas necessidades.
- Decisores ou compradores do software: podem analisar a composição interna do software e avaliar os riscos antes da aquisição.
- Operadores do software: administradores de sistemas e equipes de TI podem comparar o software com as listas de vulnerabilidades e exposições comuns (CVE).
- Usuários do software: usuários finais e consumidores se beneficiam indiretamente de medidas de segurança mais robustas.
Quais informações uma SBOM contém?
A SBOM relaciona todos os componentes, bibliotecas e módulos de terceiros de uma aplicação e descreve os atributos de cada um deles. De acordo com os frameworks padrão da indústria, como a National Telecommunications and Information Administration (NTIA) dos EUA, uma SBOM deve incluir pelo menos:
Nome do componente e do fornecedor: O nome do módulo de software e de quem o criou, seja uma entidade, um fornecedor ou um mantenedor open source
Número da versão: a versão ou build, para identificar se um trecho específico de código contém alguma falha conhecida
Identificadores únicos: chaves de referência padronizadas (URL de pacote ou enumeração comum de plataformas) para que ferramentas automatizadas cruzem os componentes com bancos de dados globais de vulnerabilidades (Isso ajuda a descobrir se alguma parte do seu código contém uma vulnerabilidade conhecida.)
Relações de dependência: um mapa mostrando como os componentes se encaixam e o que depende de quê
Informações de licenciamento: a licença open source ou comercial que rege cada parte do código (como a licença do Apache 2.0 ou MIT)
Autoria e registro de data e hora: metadados que indicam quando a SBOM foi criada e quem gerou o documento
A Cybersecurity and Infrastructure Security Agency (CISA) dos Estados Unidos aprimorou esses requisitos e lançou uma lista atualizada com mais orientações.
Como as SBOMs são criadas?
As SBOMs são criadas durante o processo de desenvolvimento, por meio de ferramentas de análise de composição de software (SCA) integradas a pipelines de integração/implantação contínuas (CI/CD). Nesse processo, ferramentas de varredura automatizada identificam, gerenciam e rastreiam os pacotes open source e os componentes de terceiros de uma base de código e depois exportam essas informações em um formato legível por máquina.
Como as SBOMs são implantadas e distribuídas?
Implantar uma SBOM é anexar os metadados do inventário (dados descritivos que identificam, rotulam e rastreiam cada componente de um software) à versão lançada, para que outras pessoas possam consultar essas informações.
O arquivo da SBOM fica em um repositório, que também deve conter os binários do código compilado ou as imagens de container. No caso de softwares comerciais, as SBOMs são entregues aos usuários empresariais por meio de endpoints de interface de programação de aplicações (API), portais do cliente ou diretamente para as equipes de segurança.
Como é feita a manutenção das SBOMs ?
A SBOM mostra a composição do software em um determinado momento, mas é atualizada constantemente. Sempre que um desenvolvedor faz commit de um novo código, atualiza uma biblioteca ou publica um novo build em produção, uma nova versão da SBOM é gerada.
A manutenção também inclui monitoramento. Monitorar uma SBOM significa usar ferramentas de gerenciamento dedicadas para comparar continuamente o que está no inventário com bancos de dados como o National Vulnerability Database (NVD). Com isso, as equipes de segurança recebem um alerta sempre que uma nova vulnerabilidade é descoberta e conseguem agir rapidamente.
Quais são os principais formatos e padrões de SBOM?
As SBOMs são estruturadas para que ferramentas automatizadas consigam verificar instantaneamente se há vulnerabilidades nas atualizações de software. Ou seja, elas precisam adotar um formato que facilite o processamento por máquina. Os principais padrões de SBOM incluem:
CycloneDX (OWASP): com foco na segurança de aplicações e no gerenciamento de vulnerabilidades em tempo real, o CycloneDX é a melhor opção para equipes de DevOps dinâmicas que buscam soluções leves para pipelines modernos.
Software Package Data eXchange (SPDX): voltado à conformidade de licenças open source e à auditoria aprofundada, o SPDX é a melhor opção para equipes jurídicas e de conformidade que precisam de um formato de SBOM mais detalhado.
Software Identification (SWID): voltado ao gerenciamento de ativos de software (SAM) e ao controle do inventário de endpoints, o SWID atende perfeitamente aos administradores de sistema de TI que precisam monitorar quais aplicações comerciais são instaladas nos dispositivos da rede.
Como as SBOMs ajudam na segurança?
As SBOMs organizam as dependências de software (código externo pré-criado que uma aplicação usa para executar uma tarefa) em dados estruturados e pesquisáveis, o que permite a detecção automática de riscos. Elas melhoram a cibersegurança em áreas como:
Resposta de dia zero: quando surge uma vulnerabilidade grave, como Log4j ou Heartbleed, basta uma consulta no inventário da SBOM para identificar todas as aplicações afetadas em segundos.
Monitoramento contínuo da segurança: os scanners comparam continuamente a SBOM com bancos de dados de vulnerabilidade globais e alertam automaticamente as equipes quando um componente se torna inseguro.
Visibilidade das dependências transitivas: o software depende de componentes que, por sua vez, dependem de outros componentes. Isso cria uma série de camadas e relações (transitórias) que precisam ser expostas para serem analisadas. As SBOMs ajudam a mapear essas relações e mostrar como as conexões se articulam, facilitando a avaliação do código.
SBOMs e análise de composição de software (SCA)
Uma ferramenta de análise de composição de software (SCA) examina as dependências de software e gera uma SBOM como parte desse processo. Depois de criar a SBOM, a SCA continua a monitorar o documento e a consultar bancos de dados externos em busca de vulnerabilidades.
As SBOMs apenas armazenam informações. Elas não executam nenhuma análise. Quem faz o trabalho pesado é a SCA, que usa a SBOM como fonte de informações.
Desafios à adoção das SBOMs
As SBOMs rastreiam informações importantes e oferecem transparência, mas sua adoção apresenta desafios como:
Imprecisão e omissão de informações nas ferramentas: os scanners automatizados não são perfeitos. Eles podem deixar escapar detalhes pouco visíveis e dependências localizadas nas camadas mais profundas do software, criando um inventário incompleto.
Excesso de alertas: as ferramentas de segurança podem sinalizar vulnerabilidades não críticas e sobrecarregar as equipes com alarmes falsos.
Nomenclatura inconsistente: diferentes fornecedores de ferramentas e software podem nomear a mesma biblioteca de software de maneiras diferentes. Isso dificulta a identificação precisa dos componentes e a busca automatizada por vulnerabilidades correspondentes nos bancos de dados.
Propriedade intelectual dos fornecedores: alguns fornecedores de softwares comerciais temem publicar uma SBOM completa para seus clientes porque não querem expor acidentalmente segredos comerciais ou informações proprietárias.
Falta de expertise: é necessário ter conhecimento especializado em DevSecOps para interpretar os dados e definir como agir diante de vulnerabilidades.
Práticas recomendadas para SBOMs
Para obter o máximo de uma SBOM, as equipes precisam priorizar a automação e padronizar o ciclo de vida de desenvolvimento de software:
Automação e monitoramento
- Integre ferramentas de SCA diretamente aos fluxos de trabalho de CI/CD para gerar SBOMs automaticamente a cada build.
- Crie o hábito de gerar uma SBOM automaticamente sempre que o software for atualizado, recompilado ou reempacotado. Não confie em uma SBOM desatualizada.
- Envie as SBOMs geradas para plataformas automatizadas de gestão de vulnerabilidades, que monitoram os componentes continuamente e os cruzam com bancos de dados de segurança atualizados em tempo real.
Padrões, formatos e metadados
- Certifique-se de que os metadados contenham pelo menos as informações essenciais, como o nome do fornecedor e do componente, o número da versão e as dependências diretas/ transitivas.
- Inclua identificadores padronizados, como URLs de pacote (PURLs), enumerações comuns de plataformas (CPEs) e hashes criptográficos, para evitar ambiguidade nos nomes dos componentes.
- Adote formatos legíveis por máquina padrão da indústria, como CycloneDX ou SPDX.
- Padronize o processamento exigindo o formato JSON ou XML em todas as soluções internas.
Armazenamento, segurança e governança
- Armazene em um repositório (como o JFrog Artifactory ou o GitHub Releases) cada versão da SBOM, vinculada diretamente ao código do lançamento correspondente.
- Exija assinaturas criptográficas sempre que uma SBOM for criada ou alterada.
- Estabeleça políticas para sinalizar ou rejeitar automaticamente fornecedores que entreguem software com dados incompletos ou adulterados.
- Defina os responsáveis por cada etapa da operação para que as equipes (de segurança, jurídica e de DevSecOps) consigam acompanhar e acessar as informações de que precisam na SBOM.
Segurança da cadeia de suprimentos de software e SBOM
Proteger a cadeia de suprimentos de software é ter evidências verificáveis de como o software foi criado e entregue.
Ao integrar elementos de IA à cadeia de suprimentos de software, é importante:
- Tratar a IA no CI/CD como uma nova entidade de segurança, com credenciais e escopo próprios.
- Assumir que qualquer mensagem de texto recebida por um agente de IA é uma injeção de prompt.
- Gerar SBOMs e AIBOMs para cada versão, não apenas as regulamentadas.
- Usar a IA para procurar padrões conhecidos em grande escala.
- Designar uma pessoa responsável pela segurança. Quando todos são responsáveis, ninguém é responsável.
Ao mesmo tempo, evite:
- Tratar pull requests geradas por IA como de baixo risco.
- Tratar uma verificação feita por IA como se fosse uma revisão humana.
- Ignorar assinaturas.
O que é uma AIBOM?
Uma AI bill of materials (AIBOM) expande a SBOM tradicional para incluir detalhes relacionados a pesos do modelo, fontes de dados de treinamento, etapas de ajuste fino e dependências das inferências. Se o seu projeto envia, incorpora ou ajusta modelos, você precisa de uma AI bill of materials.
Casos de uso de SBOM
As SBOMs trazem benefícios para organizações de diversos setores. Elas transformam o código em dados transparentes e fáceis de gerenciar, por isso são essenciais para proteger as empresas contra violações na cadeia de suprimentos e penalidades regulatórias. Em muitos casos, elas também ajudam a estabelecer confiança e a estimular a colaboração entre as diferentes partes envolvidas. Veja alguns exemplos de como as SBOMs podem ajudar a proteger os dados:
Setor de saúde
- A Lei de Portabilidade e Responsabilidade de Seguros de Saúde (HIPAA) dos Estados Unidos exige avaliações de riscos contínuas em todos os sistemas que lidam com informações de saúde protegidas eletronicamente (ePHI). As SBOMs oferecem o inventário detalhado necessário para identificar vulnerabilidades nos softwares de TI do setor de saúde.
- Antes de lançar equipamentos como marca-passos, bombas de infusão e sistemas de ressonância magnética, os fabricantes de dispositivos médicos precisam apresentar SBOMs que comprovem que esses produtos não contêm vulnerabilidades em seus códigos.
Setor financeiro
- Equipes de segurança que trabalham com aplicações voltadas à operações bancárias e investimentos usam SBOMs para monitorar os componentes de software e proteger os clientes contra riscos como fraudes financeiras e exposição de dados pessoais.
- Quando as instituições financeiras contratam fornecedores externos, como fintechs parceiras e gateways de pagamento, as SBOMs ajudam a impedir que código inseguro e não verificado chegue às redes financeiras centrais.
Setor governamental
- As SBOMs ajudam a verificar a origem e a integridade do software implantado em equipamentos militares e sistemas de satélites. Essas informações ajudam a prevenir adulterações na cadeia de suprimentos e permitem que agências governamentais identifiquem vulnerabilidades de software que agentes mal-intencionados possam explorar.
- É possível usar as SBOMs para monitorar os componentes de sistemas de controle industrial utilizados por serviços como abastecimento de água, redes de energia e os sistemas de transporte.
Setor de tecnologia
- As empresas que vendem Software como serviço (SaaS) compartilham as SBOMs para acelerar o processo de auditoria de segurança e a assinatura de acordos.
- A verificação dos metadados da SBOM durante o desenvolvimento permite identificar licenças restritivas antes da compilação do código e evitar possíveis implicações legais.
Tendências do setor apontam para a automação com IA
Para empresas que querem competir no mercado global de software, criar e manter SBOMs não é mais apenas uma opção. Marcos regulatórios, como a Lei sobre Resiliência Cibernética da União Europeia (EU CRA), exigem transparência na cadeia de suprimentos de software para todos os produtos digitais vendidos na UE. Essas normas obrigam os fabricantes a comunicar vulnerabilidades às autoridades de cibersegurança da UE em até 24 horas. A forma mais prática de monitorar o código com a agilidade necessária para cumprir esse prazo é manter SBOMs automatizadas.
O setor de tecnologia se esforça para acompanhar as exigências regulatórias, que demandam cada vez mais agilidade e transparência. Vemos isso acontecer em situações como:
Geração automatizada de SBOMs
O desenvolvimento de software moderno avança em um ritmo que nenhuma equipe consegue acompanhar com inventários manuais. Por isso, as organizações vêm investindo em ferramentas que automatizam a criação de SBOMs em todas as etapas do processo de desenvolvimento do software.
Governança, auditoria e verificação contínuas
Os setores vêm adotando fluxos de trabalho baseados em SBOMs para manter a governança contínua da cadeia de suprimentos de software, em vez de usar esse documento apenas para verificações pontuais de conformidade.
Correção automatizada de vulnerabilidades orientada por IA
As SBOMs podem ajudar a localizar vulnerabilidades, mas não conseguem corrigi-las. Historicamente, encontrar uma vulnerabilidade no código obrigava a equipe a tirar a aplicação do ar e esperar que a comunidade ou os desenvolvedores criassem um patch. Hoje, os hackers usam IA para explorar vulnerabilidades mais rápido do que os desenvolvedores conseguem criar correções. As empresas recorrem à IA para identificar e corrigir riscos automaticamente, em tempo real. Muitas vezes, isso envolve o backporting de correções de segurança.
O que é backporting de correções de segurança?
Assim como você pode usar um novo pedaço de tecido para consertar uma roupa, o backporting de correções de segurança usa um material mais novo e mais forte para consertar algo com problema.
O backporting de correções de segurança consiste em aplicar uma correção de segurança originalmente desenvolvida para uma versão mais recente a uma versão mais antiga do software. Essa solução causa menos impacto na operação do que atualizar para uma versão mais recente e preserva a estabilidade da arquitetura do software, porque não traz novos recursos nem mudanças nas APIs.
Como a Red Hat pode ajudar
A experiência da Red Hat em criar, gerenciar e automatizar SBOMs nos permite ajudar as organizações a proteger suas cadeias de suprimentos de software e a acompanhar a evolução dos padrões de conformidade. A Red Hat continua aprimorando a segurança da cadeia de suprimentos de software com iniciativas estratégicas como o Lightwell.
O Lightwell é uma colaboração entre a Red Hat e a IBM que tem como objetivo proteger aa cadeia de suprimentos de software open source. Ele atua como uma camada de entrega contínua e verificação da confiabilidade das suas SBOMs. O Lightwell usa IA para gerar, validar e implantar correções em código open source. Ele amplia o modelo validado de manutenção de software open source empresarial da Red Hat. A solução faz o backporting de correções de segurança, mantém as SBOMs atualizadas e entrega artefatos assinados e em conformidade, sem necessidade de upgrades.
