O que é uma lista de materiais de software (SBOM)?

As equipes de desenvolvimento de software começaram a usar SBOMs há mais de uma década para gerenciar bibliotecas de código aberto e repositórios de terceiros. Preocupações de cibersegurança levaram os SBOMs ao centro do palco depois que grandes ataques a cadeias de suprimentos expuseram fraquezas críticas. A violação SolarWinds de 2020 fez com que  invasores inserissem código malicioso em atualizações de software confiáveis, afetando 18.000 organizações, incluindo vários órgãos do governo. Pouco depois, a vulnerabilidade Log4j 2021 foi exposta, afetando centenas de milhões de dispositivos em todo o mundo  e revelando ainda mais como componentes comprometidos podem ameaçar sistemas inteiros.

Esses ataques cibernéticos destacaram uma dura realidade: as organizações, incluindo órgãos do governo federal, não tinham visibilidade dos componentes e das dependências em seus sistemas de software. Essa falta de visibilidade dificulta a avaliação dos riscos de cibersegurança e a resposta eficaz às ameaças. A urgência da ameaça estimulou uma ação decisiva da Casa Branca. O Decreto Executivo 14028 tornou obrigatórios os SBOMs para todas as aquisições federais de software em maio de 2021.

A National Telecommunications and Information Administration (NTIA) estabeleceu os elementos mínimos para SBOMs  que os fornecedores de software devem seguir ao vender para entidades governamentais. Em setembro de 2024, a CISA publicou um documento intitulado "Framing Software Component Transparency",  expandindo esses requisitos mínimos e fornecendo orientações mais detalhadas sobre a implementação e o gerenciamento de SBOMs em todo o ecossistema de software.

Essa diretiva federal agora serve como modelo para transparência de software em todos os setores. Por exemplo, no setor de serviços financeiros, o Payment Card Industry Data Security Standard (PCI DSS) versão 4.0 inclui requisitos para gerenciamento de inventário de software para proteger sistemas de pagamentos e lidar com vulnerabilidades. Na área de saúde, a FDA exige SBOMs  para dispositivos médicos, enquanto o International Medical Device Regulators Forum (IMDRF) recomenda seu uso  para proteger os dispositivos médicos e sistemas de dados de pacientes.

Essas diretrizes e recomendações setoriais refletem uma mudança mais ampla em direção à adoção dos SBOMs no setor privado. A Gartner prevê que, até 2025, 60% das organizações que criam ou adquirem software  de infraestrutura crítica exigirão SBOMs, contra menos de 20% em 2022. Essa adoção é impulsionada pela necessidade — análises recentes mostram que mais de 90% das aplicações de software modernas  contêm dependências de código aberto , sendo que 74% contêm dependências de alto risco. As organizações estão usando cada vez mais os SBOMs para atender aos requisitos de conformidade, validar componentes de terceiros e lidar com vulnerabilidades de segurança à medida que são descobertas.

Assim como os rótulos de alimentos que detalham os ingredientes e suas fontes, os SBOMs fornecem documentação estruturada de componentes de software, seus fornecedores e os relacionamentos entre dependências.

Os requisitos de SBOMs evoluíram significativamente desde sua introdução no Decreto Executivo 14028 (2021). O que começou como requisitos mínimos da NTIA se expandiu por meio da adoção dos setores e do refinamento regulatório. O framework atual, publicado pela CISA em setembro de 2024, baseia-se nesses fundamentos com orientações aprimoradas para uma implementação mais ampla.

As organizações enfrentam diferentes requisitos de SBOMs, dependendo de seu setor e de suas relações com o governo federal. Os prestadores de serviços do Governo dos EUA, os provedores de infraestrutura crítica e as organizações de setores regulamentados devem cumprir os requisitos específicos de SBOMs. Embora o governo federal exija a adoção do SBOM para seus fornecedores, organizações do setor privado fora dos contratos do governo têm adoção voluntária, embora a implementação de práticas de SBOM tenha se tornado cada vez mais importante para a segurança da cadeia de suprimentos e a confiança do cliente.

O framework de 2024 da CISA introduz um modelo de maturidade de três camadas que ajuda as organizações a aprimorar progressivamente suas práticas de SBOMs:

• Mínimo esperado: elementos essenciais necessários para a funcionalidade e conformidade básicas de SBOMs
  
  
• Prática recomendada: documentação aprimorada que oferece suporte a casos de uso mais amplos de segurança e conformidade
  
  
• Objetivo aspiracional: funcionalidades avançadas que permitem visibilidade abrangente da cadeia de suprimentos

Os atributos a seguir representam os elementos essenciais necessários em um SBOM completo:

• Metainformações do SBOM: dados principais do próprio documento do SBOM, incluindo o autor dos dados do SBOM, o registro de data e horário de sua criação e o componente principal que está sendo documentado
  
  
• Nome do fornecedor: a entidade que cria, define e fabrica o componente de software
  
  
• Nome do componente: o nome designado do componente de software, atribuído pelo fornecedor original
  
  
• Versão do componente: captura alterações específicas da versão para rastrear com precisão atualizações e modificações
  
  
• Outros identificadores exclusivos: inclui tipos de referência como Common Platform Enumeration (CPE), tags SWID ou URLs de pacotes (PURL) para rastreamento preciso de componentes
  
  
• Hash criptográfico: uma impressão digital única para cada componente de software que permite a verificação da integridade e a identificação precisa
  
  
• Relação de dependências: um mapa estruturado que mostra como os componentes estão interconectados, abrangendo dependências diretas e transitivas
  
  
• Informações sobre licenças: documentação dos termos legais para componentes de software fornecidos
  
  
• Aviso de direitos autorais: pessoa jurídica que detém os direitos exclusivos e legais sobre os componentes listados

As dependências de software criam interconexões complexas dentro de aplicações modernas. Uma SBOM deve capturar essas relações de forma clara, distinguindo entre dependências diretas (componentes explicitamente incluídos no software) e dependências transitivas (componentes extraídos por outras dependências).

Ao documentar as dependências, as organizações devem indicar explicitamente a integridade de seu conhecimento. O pressuposto padrão é que as informações de dependências podem estar incompletas, a menos que seja explicitamente marcado de outra forma. Essa transparência ajuda os usuários downstream a entender os possíveis pontos cegos em sua cadeia de suprimentos de software.

As organizações também devem levar em conta as dependências dinâmicas carregadas em tempo de execução e as dependências remotas chamadas de serviços externos. Embora isso possa não fazer parte da compilação de software tradicional, entender esses relacionamentos é crucial para uma avaliação de segurança abrangente.

Em implementações do mundo real, o conhecimento completo de todos os componentes de software nem sempre é possível. As organizações devem lidar com essas lacunas de forma transparente, documentando explicitamente dependências desconhecidas e informações incompletas. Quando certos componentes não podem ser totalmente documentados devido a obrigações contratuais ou outras restrições, a SBOM deve indicar essas redações e, ao mesmo tempo, preservar a estrutura geral de dependências.

Em vez de omitir informações incertas, as organizações devem marcar explicitamente essas áreas como desconhecidas ou incompletas. Esta abordagem ajuda os usuários downstream a tomar decisões informadas sobre o gerenciamento de riscos e as necessidades de investigação adicional. Para componentes redigidos, as organizações devem manter SBOMs internas completas e versões adequadamente redigidas para compartilhamento externo.

O processo de criação e manutenção de SBOMs envolve vários stakeholders ao longo do ciclo de vida de desenvolvimento de software (SDLC). As organizações devem gerar SBOMs para componentes de software proprietário e de código aberto (OSS). Os fornecedores e desenvolvedores de software são os principais responsáveis por gerar as SBOMs iniciais no início do processo de desenvolvimento. Essas SBOMs capturam uma visão abrangente dos componentes de toda a base de código. Os compradores de software desempenham um papel fundamental na validação e manutenção desses documentos para suas aplicações implementadas.

As equipes de desenvolvimento de software integram a geração de SBOMs diretamente a seus pipelines de integração contínua e entrega contínua (CI/CD). Durante o processo de construção, ferramentas de varredura automatizadas analisam o código-fonte para criar um inventário de todos os componentes, capturando dependências diretas e transitivas. Essas ferramentas geram arquivos SBOM padronizados em formatos como SPDX e CycloneDX. (As tags SWID são menos proeminentes, mas ainda são uma opção válida.) Elas documentam os metadados, informações da versão e detalhes de licenciamento de cada componente.

Os sistemas de controle de versões mantêm registros históricos de alterações de SBOMs, acompanhando como a composição de software evolui ao longo do tempo. As organizações podem rastrear alterações de versões e patches de segurança dentro de componentes de software para cada versão, o que é vital para gerenciar vulnerabilidades e lidar com incidentes de segurança.

As equipes de desenvolvimento normalmente configuram seus pipelines para acionar atualizações de SBOMs com base em eventos específicos: quando novas dependências são adicionadas, quando componentes existentes são atualizados ou quando patches de segurança são aplicados. Esse processo de atualização contínua mantém o alinhamento entre a composição real do software e sua documentação.

Os pontos de verificação de controle de qualidade em todo o pipeline de desenvolvimento validam a integridade e a precisão das SBOMs. Essas etapas de validação verificam se cada SBOM cumpre as normas obrigatórias e contém todas as informações de componentes necessárias antes do lançamento do software. A validação automatizada reduz as lacunas de documentação e melhora a consistência entre as versões.

O ecossistema de ferramentas que dá suporte à criação de SBOMs continua a se expandir. Os geradores de SBOMs formam a base, digitalizando automaticamente o código-fonte para identificar componentes e seus relacionamentos. As ferramentas de validação então verificam as SBOMs gerados em relação aos padrões e especificações estabelecidos, sinalizando informações ausentes ou incorretas. A automação de SBOMs bem-sucedida depende de melhores práticas estabelecidas: padronização de formatos entre equipes, implementação consistente de convenções de nomenclatura, manutenção de documentação clara das regras de automação e estabelecimento de ciclos de feedback para melhoria contínua.

As plataformas de gerenciamento se baseiam nesses recursos, oferecendo funcionalidades para armazenamento, análise e distribuição de SBOMs em todas as organizações. As plataformas avançadas vão além ao integrar os dados de SBOMs a fluxos de trabalho mais amplos de risco e conformidade.

Por exemplo, as ferramentas de automação podem mapear vulnerabilidades em componentes de software específicos, priorizar os esforços de remediação com base na gravidade e rastrear as alterações ao longo do tempo para identificar riscos recém-introduzidos. Ao consolidar dados e fornecer insights em tempo real, essas ferramentas capacitam as equipes de desenvolvimento, segurança e conformidade a colaborar de forma eficaz.

A seleção do formato de SBOMs correto é crucial para uma implementação eficaz. As SBOMs devem ser compatíveis com a geração automatizada e a legibilidade de máquina para escalar em todos os ecossistemas de software. A automação dos processos de SBOMs elimina erros de entrada manuais durante a criação e permite a integração sem dificuldades com ferramentas de segurança e desenvolvimento.

Existem vários formatos padronizados usados para permitir a geração, validação e consumo automatizados de dados de SBOMs e, ao mesmo tempo, proporcionar compatibilidade com a integração com ferramentas de segurança e desenvolvimento existentes. As organizações devem implementar a geração automatizada de SBOMs em seus pipelines de CI/CD para garantir que a documentação permaneça atualizada com as alterações de software.

O framework atual da CISA reconhece principalmente dois formatos: SPDX e CycloneDX. Cada um aborda a documentação de componentes de software de forma diferente, oferecendo níveis variados de detalhamento e focando em casos de uso específicos dentro do ciclo de vida de desenvolvimento de software.

O Software Package Data Exchange (SPDX) foi desenvolvido pela Linux Foundation e ganhou adoção generalizada em todo o ecossistema de código aberto e em fornecedores de softwares comerciais. O formato é compatível com a verificação de pacotes criptográficos e oferece várias opções de formato legível por máquina, incluindo JSON, RDF, XML e YAML. Sua vasta compatibilidade com metadados permite rastreamento detalhado de segurança e procedência em toda a cadeia de suprimentos de software.

O SPDX se destaca em cenários de conformidade de código aberto, fornecendo informações detalhadas sobre licenças e ajudando as organizações a gerenciar seu uso de componentes de código aberto de forma eficaz. Os principais fornecedores de software e provedores de serviços de nuvem adotaram o SPDX por sua especificação robusta e ampla compatibilidade com o ecossistema.

O CycloneDX, desenvolvido pela OWASP Foundation, foi projetado especificamente para segurança de aplicações e gerenciamento de riscos da cadeia de suprimentos de software. Ele fornece funcionalidades essenciais para gerenciamento de vulnerabilidades, rastreamento de componentes e segurança da cadeia de suprimentos, com forte ênfase na integração de VEX e compatibilidade com a análise de contêineres.

Os elementos focados em segurança do formato o tornam especialmente adequado para organizações que implementam programas abrangentes de segurança da cadeia de suprimentos de software. Sua compatibilidade nativa com casos de uso de segurança impulsionou a adoção entre equipes de segurança e fluxos de trabalho de gerenciamento de vulnerabilidades.

As tags de identificação de software (SWID) fornecem um mecanismo padronizado para identificação e gerenciamento de software. O formato é compatível com o rastreamento abrangente de ativos de software com funcionalidades para gerenciamento do ciclo de vida, rastreamento de patches e controle de inventário em ambientes empresariais. Notavelmente, as tags SWID não estão mais listadas como um formato compatível na orientação de 2024 para mapeamento de atributos, mas continuam sendo uma opção válida como um identificador exclusivo dentro das SBOMs.

A análise de composição de software (SCA) é um processo ativo de cibersegurança (com ferramentas associadas) que verifica o código em busca de vulnerabilidades, enquanto a lista de materiais de software (SBOM) fornece um inventário padronizado de todos os componentes de software em um produto. Embora ambos ajudem na segurança da cadeia de suprimentos de software, eles servem a propósitos distintos em ambientes de desenvolvimento modernos.

Embora ambas as ferramentas se concentram em componentes de software, as ferramentas de SCA verificam e analisam ativamente o código durante o desenvolvimento, focando principalmente em componentes de código aberto e dependências de terceiros. Essas ferramentas fornecem insights em tempo real para detecção de vulnerabilidades, conformidade de licenças e imposição de políticas de segurança.

A SBOM funciona como um documento de inventário padronizado que captura todos os componentes de software, incluindo o código proprietário. As SBOMs fornecem transparência na composição do software por meio de formatos estruturados, como SPDX e CycloneDX, mas não incluem inerentemente recursos analíticos. Embora as ferramentas de SCA normalmente sejam compatíveis com práticas de segurança internas, as SBOMs são cada vez mais exigidas por regulamentos e normas setoriais.

Normalmente, as organizações implementam ambas as soluções juntas, usando ferramentas de SCA para monitorar ativamente a segurança durante o desenvolvimento e, ao mesmo tempo, mantendo SBOMs para requisitos de conformidade e visibilidade da cadeia de suprimentos. As ferramentas de SCA frequentemente geram e validam SBOMs de forma automática, enquanto a documentação do SBOM ajuda a informar as políticas de varredura.

A complexidade das cadeias de suprimentos de software modernas tornou a adoção de SBOMs essencial para o gerenciamento abrangente de riscos e garantia de segurança. As organizações usam cada vez mais plataformas automatizadas que podem consolidar dados de SBOMs com outras informações de segurança e conformidade para uma tomada de decisão mais eficaz.

As equipes de segurança integram dados de SBOMs a suas estratégias mais amplas de gerenciamento de riscos de aplicações por meio de plataformas automatizadas que permitem detecção e resposta a vulnerabilidades em tempo real. Quando novas vulnerabilidades e exposições comuns (CVEs) surgem, essas plataformas podem mapeá-las instantaneamente para os componentes afetados em todo o portfólio de software usando inventários de SBOMs. Isso ajuda as organizações a apoiar práticas de software seguras.

Essa integração viabiliza insights orientados por IA para priorização de riscos, ajudando as equipes a lidar com as CVEs mais críticas primeiro. Durante a resposta a incidentes, os dados detalhados dos componentes das SBOMs fornecem inteligência crucial sobre componentes potencialmente comprometidos. Isso possibilita esforços de remediação direcionados e avaliações de riscos mais precisas.

As SBOMs desempenham um papel importante no gerenciamento de vulnerabilidades, ao proporcionar um inventário abrangente de componentes de software e permitir a rápida identificação dos sistemas afetados quando novas vulnerabilidades são descobertas.

No entanto, nem todas as vulnerabilidades representam o mesmo risco, e determinar a capacidade de exploração pode ser um desafio. É aqui que entra o Vulnerability Exploitability eXchange (VEX). O VEX é um framework de segurança que fortalece a utilidade das SBOMs ao fornecer um contexto essencial sobre vulnerabilidades conhecidas. Embora uma SBOM identifique todos os componentes de um produto de software, ela não indica se as vulnerabilidades descobertas são exploráveis. O VEX preenche essa lacuna ao esclarecer o impacto no mundo real das vulnerabilidades.

O VEX informa às equipes de resposta a incidentes de segurança de produtos (PSIRTs) e às equipes de segurança se vulnerabilidades específicas afetam seus ambientes de software. Usando o Common Security Advisory Framework (CSAF), o VEX fornece atualizações de status legíveis por máquina sobre o impacto das vulnerabilidades. Com essas informações, as equipes de segurança podem tomar decisões mais rápidas e bem fundamentadas.

Ao integrar dados do VEX com SBOMs, as organizações podem reduzir falsos positivos, priorizar riscos reais e simplificar fluxos de trabalho de gerenciamento de vulnerabilidades. Essa abordagem combinada marca um avanço significativo na avaliação automatizada de riscos de segurança e na remediação direcionada.

À medida que os requisitos regulatórios evoluem, as organizações precisam de recursos sofisticados de gerenciamento de conformidade que possam lidar com requisitos complexos das SBOMs. As SBOMs atuam como uma forma de atestado, fornecendo documentação verificável de que os componentes de software cumprem normas como as diretrizes do NIST e o Decreto Executivo 14028. Ao oferecer registros transparentes da composição e segurança do software, as SBOMs simplificam as auditorias e demonstram o alinhamento regulatório em todos os setores.

Órgãos federais e setores regulamentados devem demonstrar conformidade com vários frameworks, incluindo as diretrizes do NIST e o Decreto Executivo 14028. Plataformas de conformidade avançadas podem verificar automaticamente se os componentes de software cumprem as normas de segurança, rastrear o status de conformidade em vários frameworks e fornecer alertas em tempo real quando os componentes se desviam dos requisitos. Esses recursos podem ajudar as organizações a manter a conformidade contínua e, ao mesmo tempo, reduzir a supervisão manual.

Ambientes nativos da nuvem e conteinerizados representam desafios únicos para o gerenciamento de SBOMs. A natureza dinâmica desses ambientes exige abordagens especializadas para lidar com arquiteturas complexas de microsserviços, frequentemente alterando imagens de contêineres e implementações que abrangem vários provedores de nuvem e plataformas.

As organizações lidam com esses desafios por meio de ferramentas de SBOM especializadas que se integram diretamente às plataformas de orquestração de contêineres. Essas soluções permitem a geração de SBOMs em tempo real à medida que as imagens de contêineres são criadas e implementadas, ao mesmo tempo em que fornecem visibilidade unificada em ambientes de nuvem híbrida.

Ao automatizar o rastreamento de componentes e a integração com as ferramentas de segurança na nuvem existentes, as organizações podem manter inventários precisos de componentes de software e responder rapidamente a ameaças à segurança em toda a infraestrutura na nuvem. Esse recurso se aplica independentemente de as aplicações serem executadas em contêineres, como funções serverless ou em ambientes tradicionais.

Os SBOMs servem como base para o gerenciamento de riscos da cadeia de suprimentos, ao possibilitar visibilidade abrangente de software de terceiros. As organizações frequentemente usam plataformas orientadas por IA para analisar dados de SBOM juntamente com outras métricas de segurança, criando uma visão holística da integridade de suas aplicações e da postura de riscos.

Essas plataformas rastreiam versões de componentes, avaliam os riscos dos fornecedores e impulsionam a conformidade das licenças, ao mesmo tempo em que fornecem insights praticáveis para mitigação de riscos. A integração de dados de SBOM a processos de gerenciamento de risco mais amplos permite que as organizações tomem decisões informadas sobre suas dependências de software e mantenham ambientes de aplicações mais seguros e conformes.

As organizações podem enfrentar vários obstáculos significativos ao implementar práticas de SBOM em seu ecossistema de software. Compreender e lidar com esses desafios é uma parte fundamental da adoção bem-sucedida e da manutenção da segurança de dados em toda a cadeia de suprimentos.

Os seguintes desafios frequentemente surgem quando as organizações implementam práticas de SBOM:

• Gerenciamento de milhares de componentes de software em diversos ambientes
  
  
• Integração de dados de SBOMs entre diferentes ferramentas de desenvolvimento e plataformas de segurança
  
  
• Manutenção da qualidade de dados, especialmente para software legado e componentes de terceiros
  
  
• Rastreamento de dependências em ambientes de nuvem com ciclos rápidos de implementação
  
  
• Equilíbrio de restrições de recursos com a necessidade de dados de SBOMs precisos e atuais
  
  
• Adaptação a arquiteturas dinâmicas nativas da nuvem, onde os componentes mudam com frequência

A implementação bem-sucedida de SBOMs requer uma abordagem estratégica que esteja alinhada com as normas do setor e as necessidades organizacionais. Os principais elementos incluem:

• Automatize processos durante todo o ciclo de vida do desenvolvimento de software
  
  
• Integre-se sem dificuldades a fluxos de trabalho existentes e a ferramentas de segurança
  
  
• Use uma plataforma unificada para gerenciamento de SBOMs

• Implemente elementos essenciais para a funcionalidade e conformidade básicas de SBOMs
  
  
• Melhore a documentação para casos de uso mais amplos de segurança e conformidade
  
  
• Permita visibilidade abrangente da cadeia de suprimentos por meio de funcionalidades avançadas

• Gere e atualize SBOMs em tempo real, principalmente em ambientes nativos da nuvem
  
  
• Documente informações desconhecidas de forma transparente, em vez de omiti-las
  
  
• Gerencie SBOMs internas completas e versões editadas para compartilhamento externo
  

• Crie políticas claras de governança de SBOMs com auditorias regulares e validação automatizada
  
  
• Conecte dados de SBOMs com o Vulnerability Exploitability eXchange (VEX) para melhorar o gerenciamento de vulnerabilidades

Ao seguir essas práticas, as organizações podem melhorar a visibilidade da cadeia de suprimentos, fortalecer a segurança e manter a conformidade, ao mesmo tempo em que lidam com os desafios da implementação de SBOMs.

O cenário de segurança da cadeia de suprimentos de software continua evoluindo, gerando inovações na tecnologia e adoção de SBOMs. Com as organizações enfrentando ameaças cada vez mais sofisticadas, a função das SBOMs na segurança do ecossistema de software se torna mais crítica.

Várias tendências importantes estão moldando o futuro da implementação e utilização das SBOMs:

Avanços da inteligência artificial estão transformando a forma como as organizações gerenciam e utilizam SBOMs. Os sistemas de IA modernos agora automatizam a geração e a análise de SBOMs, ao mesmo tempo em que fornecem análises preditivas de riscos mais precisas e detecção refinada de vulnerabilidades. Essa automação se estende à identificação proativa de riscos de segurança em todas as cadeias de suprimentos de software.

Um desenvolvimento significativo é o surgimento de BOMs de IA/ML especializadas, que lidam com desafios únicos em código e modelos gerados por IA. Essas BOMs aprimoradas documentam arquiteturas de modelos de IA, dados de treinamento e métodos de testes, trazendo a transparência necessária aos processos de desenvolvimento de IA.

O cenário de segurança para o gerenciamento de SBOMs continua evoluindo. Blockchain e tecnologia de livro-razão distribuído oferecem novas soluções para armazenamento e compartilhamento seguros de SBOMs, criando trilhas de auditoria imutáveis que são particularmente valiosas para sistemas de infraestrutura críticos. As organizações exigem cada vez mais dados praticáveis de SBOMs que permitam a rápida identificação de componentes comprometidos e a remediação simplificada.

A blockchain pode aprimorar a segurança de SBOMs, ao fornecer armazenamento inviolável, permitindo a verificação descentralizada e facilitando o compartilhamento seguro entre organizações com controles de acesso rigorosos.

Essa convergência tecnológica impulsiona a adoção de plataformas unificadas que se integram às práticas de DevSecOps existentes. Essas soluções automatizam todo o ciclo de vida das SBOMs (desde a fusão de diferentes fontes de dados até o gerenciamento de aprovações em várias versões e ramificações de software), ao mesmo tempo em que fornecem inteligência para mitigação de riscos.