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

Uma lista de materiais de software (SBOM) é um documento que fornece um inventário detalhado dos componentes e das dependências usados em um projeto de software. Ela também relaciona todas as bibliotecas e estruturas de desenvolvimento, bem como suas respectivas versões, utilizadas no software. Quando se trata de software de código aberto (OSS), uma SBOM pode desempenhar um papel fundamental para garantir transparência, segurança e conformidade.

Por que sua organização deve usar SBOMs

O uso de uma SBOM — especialmente em software de código aberto (OSS) — permite que uma organização tenha visibilidade dos componentes e das dependências, melhore a gestão de riscos e muito mais. A seguir, apresentamos esses benefícios.

Visibilidade dos componentes

O software de código aberto (OSS) geralmente incorpora diversos componentes e dependências de terceiros. Uma SBOM permite que desenvolvedores e usuários tenham uma visão clara de todos os componentes utilizados no software. Isso inclui bibliotecas e frameworks de código aberto, bem como suas versões específicas. Essa visibilidade ajuda a compreender a composição do software, identificar possíveis vulnerabilidades e acompanhar quaisquer obrigações de licenciamento associadas aos componentes de código aberto.

Gerenciamento de vulnerabilidades

Assim como qualquer outro software, o software de código aberto (OSS) pode estar sujeito a vulnerabilidades de segurança. Com uma SBOM, as organizações podem acompanhar as versões dos componentes de código aberto e se manter informadas sobre quaisquer vulnerabilidades conhecidas associadas a essas versões. Isso permite o gerenciamento proativo de vulnerabilidades por meio da aplicação imediata de correções ou atualizações para mitigar e relatar quaisquer problemas de segurança (consulte RFC8615). Ao manter uma SBOM atualizada, as organizações podem avaliar o impacto das vulnerabilidades e tomar as medidas adequadas para proteger seu software.

Segurança da cadeia de suprimentos

Nos últimos anos, a segurança da cadeia de suprimentos de software tornou-se uma preocupação significativa. Uma SBOM contribui para reforçar a segurança da cadeia de suprimentos ao proporcionar transparência sobre os componentes usados no software e suas origens. Ela também permite que as organizações avaliem a confiabilidade e a postura de segurança dos componentes dos quais dependem. Com uma SBOM, as organizações podem identificar e mitigar os riscos associados a componentes comprometidos ou maliciosos, reduzindo o potencial de ataques à cadeia de suprimentos de software.

Colaboração e gerenciamento de patches

O software de código aberto (OSS) incentiva a colaboração e o envolvimento da comunidade. Uma SBOM facilita a colaboração eficaz ao proporcionar a diferentes colaboradores e partes interessadas uma compreensão comum dos componentes do software. Ela ajuda a coordenar os esforços de gerenciamento de patches, identificando claramente os componentes que precisam de atualizações ou correções. A colaboração na comunidade de código aberto se torna mais eficiente quando todos os participantes podem consultar uma SBOM compartilhada para solucionar vulnerabilidades de segurança e outros problemas.

Conformidade regulatória

Em alguns setores, as estruturas regulatórias exigem que as organizações demonstrem transparência e controle sobre os componentes de software usados em suas aplicações ou sistemas. Uma SBOM fornece a documentação necessária para atender a esses requisitos de conformidade. Ela permite que as organizações demonstrem a devida diligência, a rastreabilidade e a conformidade com as regulamentações pertinentes, especialmente no que diz respeito aos aspectos de segurança e licenciamento de software de código aberto (OSS).

Conformidade de Licenças

O software de código aberto (OSS) geralmente é regido por licenças específicas que determinam como ele pode ser usado, modificado e distribuído. Uma SBOM fornece uma visão abrangente de todos os componentes de código aberto e de suas respectivas licenças. Isso ajuda as organizações a garantir a conformidade com os termos das licenças do OSS que utilizam. Ao compreender as obrigações de licenciamento, as organizações podem tomar decisões fundamentadas sobre a distribuição e o uso de seu software, evitando problemas jurídicos ou de conformidade.

Requisitos de SBOM em setores altamente regulamentados

Diversos governos e organizações de setores altamente regulamentados, como os setores bancário e de saúde, estão defendendo o uso de SBOMs ou considerando tornar o uso de uma SBOM um requisito, seja internamente ou para seus fornecedores.

Exemplos de setores que utilizam SBOMs

• Setor público – Os Estados Unidos, a União Europeia, o Reino Unido, e o Japão estão entre os muitos países que utilizam, regulamentam ou recomendam o uso de SBOMs.
• Tecnologia – Grandes empresas de tecnologia, como Google, Microsoft e IBM, estão na vanguarda ao implementar SBOMs em seus próprios processos de desenvolvimento de software e contribuir para projetos como o Software Package Data Exchange (SPDX), OWASP, além de disponibilizar uma ferramenta de geração de SBOM como código aberto.
• Setor automotivo – Várias grandes montadoras, como a Ford e a General Motors, estão implementando SBOMs e incentivando seus fornecedores a disponibilizar SBOMs para os componentes e softwares usados em sistemas automotivos.
• Saúde – Os fabricantes de dispositivos médicos no mercado dos EUA agora estão usando SBOMs para cumprir uma norma de 2022 da Food and Drug Administration.

Quem faz parte de uma equipe de SBOM?

A criação de uma SBOM exige a colaboração e o envolvimento de diversas partes interessadas em toda a cadeia de suprimentos de software. Ao envolver essas partes interessadas e promover a colaboração entre elas, as organizações podem criar uma SBOM robusta e confiável, que reúna as informações necessárias sobre os componentes de software, aumente a segurança da cadeia de suprimentos e facilite as iniciativas de gestão de riscos e conformidade.

Veja algumas das principais pessoas ou funções que devem estar envolvidas no processo:

• Equipe de desenvolvimento – A equipe de desenvolvimento, incluindo engenheiros de software e desenvolvedores, desempenha um papel fundamental na identificação e documentação dos componentes de software usados no projeto. Ela é responsável por fornecer informações precisas sobre as dependências, versões e origens dos componentes de software utilizados.
• Gerentes de projeto – Os gerentes de projeto supervisionam todo o processo de desenvolvimento de software e devem participar da criação de uma SBOM. Eles podem trabalhar em conjunto com a equipe de desenvolvimento para garantir que as informações necessárias sejam coletadas e documentadas na SBOM. Os gerentes de projeto também desempenham um papel importante para assegurar a conformidade com os requisitos da SBOM e integrá-la ao fluxo de trabalho do projeto.
• Equipe de segurança – A equipe de segurança, incluindo analistas e especialistas em segurança, desempenha um papel fundamental na avaliação e no gerenciamento dos riscos de segurança associados aos componentes de software. Ela pode fornecer informações sobre vulnerabilidades e problemas de segurança conhecidos relacionados aos componentes listados na sua SBOM. A experiência da equipe ajuda a identificar possíveis riscos de segurança e a priorizar os esforços de correção.
• Equipe de compras – A equipe de compras, ou os responsáveis pela aquisição de componentes de software, desempenha um papel fundamental na elaboração de uma SBOM. Ela pode fornecer informações sobre a origem e os detalhes de licenciamento dos componentes obtidos de fontes externas. A colaboração com a equipe de compras garante o rastreamento e a verificação precisos dos componentes de software na cadeia de suprimentos.
• Equipe de operações – A equipe de operações geralmente é responsável pela implantação e manutenção do software. Ao criar uma SBOM, ela pode fornecer informações valiosas sobre o ambiente de execução, as configurações de implantação e quaisquer componentes de software adicionais introduzidos durante a fase operacional. Suas contribuições ajudam a garantir uma SBOM abrangente e atualizada.
• Especialistas jurídicos e de conformidade – Os profissionais das áreas jurídica e de conformidade são partes interessadas essenciais na elaboração de uma SBOM, especialmente no que diz respeito a questões de licenciamento e propriedade intelectual. Eles podem fornecer orientações sobre a conformidade com licenças e garantir que sua SBOM esteja alinhada a quaisquer requisitos legais ou restrições associados aos componentes de software.
• Fornecedores e parceiros externos – Se o projeto de software incorporar componentes ou serviços de fornecedores ou parceiros externos, é fundamental envolvê-los no processo de elaboração da SBOM. Eles podem fornecer as informações necessárias sobre suas ofertas, incluindo dependências, versões e vulnerabilidades. A colaboração com partes interessadas externas ajuda a garantir uma SBOM abrangente e precisa.

Como criar uma SBOM

As organizações devem buscar criar uma SBOM que forneça uma visão abrangente dos componentes de software, suas origens, dependências e informações de segurança associadas. Isso permite gerenciar melhor os riscos da cadeia de suprimentos de software e aprimora a segurança geral do software.

Estas são as principais etapas para criar uma SBOM:

• Identifique e inventarie os componentes: comece identificando todos os componentes de software usados em seu projeto, incluindo componentes proprietários e de código aberto. Crie uma lista de inventário com informações como nome, versão e origem de cada componente.
• Determine a origem dos componentes: para cada componente, determine sua origem, seja ele proprietário, de código aberto ou uma combinação de ambos. Essa etapa ajuda a avaliar possíveis vulnerabilidades de segurança associadas aos diferentes componentes.
• Documente as dependências: Documente as dependências entre os componentes, incluindo todas as bibliotecas ou frameworks utilizados. Isso ajuda a compreender as relações entre os diferentes componentes e garante que todas as dependências sejam consideradas.
• Colete metadados: Colete os metadados de cada componente, como informações de licença, vulnerabilidades conhecidas e datas de lançamento. Essas informações são essenciais para monitorar os aspectos de segurança e conformidade dos componentes de software.
• Automatize a geração da SBOM: Para simplificar o processo, considere automatizar a geração da SBOM usando ferramentas especializadas. Essas ferramentas podem analisar seu projeto de software, identificar os componentes e coletar automaticamente as informações necessárias.
• Mantenha sua SBOM atualizada: à medida que seu projeto de software evolui, é essencial manter sua SBOM atualizada. Revise e atualize regularmente o inventário, as origens dos componentes, as dependências e os metadados conforme ocorrerem mudanças.
• Compartilhe e utilize sua SBOM: Compartilhe sua SBOM com as partes interessadas relevantes da sua cadeia de suprimentos de software, como fornecedores, clientes e auditores. Isso promove a transparência, possibilita uma melhor avaliação de riscos e ajuda a identificar e corrigir vulnerabilidades.
• Monitore e gerencie vulnerabilidades: Monitore continuamente novas vulnerabilidades e atualizações de segurança relacionadas aos componentes da sua SBOM. Mantenha-se informado sobre os patches de segurança mais recentes e corrija prontamente quaisquer vulnerabilidades para preservar a segurança do seu software.

Sete maneiras pelas quais uma SBOM pode não cumprir seu objetivo

Há várias maneiras pelas quais uma SBOM pode falhar ou não cumprir plenamente sua finalidade. Enfrentar esses desafios e garantir que sua SBOM seja precisa, completa e esteja atualizada pode ajudar a reduzir o risco de falhas.

Veja algumas causas comuns de falha que refletem as práticas recomendadas para a criação de uma SBOM:

• Inventário incompleto ou impreciso: se a sua SBOM não identificar com precisão todos os componentes de software usados em um projeto ou contiver informações incompletas, isso poderá gerar pontos cegos e lacunas na compreensão da cadeia de suprimentos de software. Um inventário incompleto ou impreciso pode fazer com que vulnerabilidades ou dependências passem despercebidas, comprometendo a eficácia da sua SBOM.
• Falta de visibilidade dos componentes: se a sua SBOM não fornecer uma visão clara das origens, versões e dependências dos componentes de software, será difícil avaliar e gerenciar com eficácia os riscos associados. Sem uma visibilidade abrangente, torna-se desafiador rastrear vulnerabilidades, identificar atualizações de correção e garantir a conformidade com os requisitos de licenciamento.
• Processos manuais e desatualizados: Depender de processos manuais para criar e manter uma SBOM pode gerar ineficiências e erros. Se a sua SBOM não for atualizada regularmente para refletir as mudanças no projeto de software, ela rapidamente ficará desatualizada e perderá seu valor como referência confiável para fins de segurança e conformidade.
• Metadados e contexto insuficientes: uma SBOM deve fornecer mais do que apenas uma lista de componentes de software — ela deve incluir metadados relevantes, como informações de licenciamento, vulnerabilidades conhecidas e datas de lançamento. Se esse contexto adicional estiver ausente ou incompleto, isso prejudicará a capacidade de avaliar os riscos com precisão e tomar decisões fundamentadas.
• Falta de colaboração entre as partes interessadas: A colaboração e o compartilhamento de informações entre as partes interessadas na cadeia de suprimentos de software são essenciais para o uso eficaz da SBOM. Se houver falta de cooperação ou relutância em compartilhar informações da SBOM, será difícil identificar e corrigir vulnerabilidades de forma conjunta, comprometendo a segurança geral do software.
• Ferramentas e automação limitadas: a criação e a manutenção manuais de uma SBOM podem ser demoradas e propensas a erros. Sem ferramentas e automação adequadas, torna-se difícil gerar, atualizar e gerenciar sua SBOM com eficiência. A falta de automação também pode causar atrasos na identificação de novas vulnerabilidades ou dependências.
• Monitoramento inadequado de vulnerabilidades: uma SBOM deve ser complementada por um processo robusto de monitoramento de vulnerabilidades. Sem o monitoramento regular de novas vulnerabilidades e atualizações de segurança associadas aos componentes de software, possíveis riscos podem passar despercebidos, deixando o software exposto a vulnerabilidades conhecidas.

Resumo

De modo geral, uma SBOM é uma ferramenta valiosa para gerenciar as complexidades do software de código aberto (OSS). Ela promove transparência, segurança, conformidade e colaboração no ecossistema de código aberto. Ao fornecer um inventário detalhado dos componentes de software, suas versões e as respectivas informações de licenciamento, uma SBOM permite que as organizações tomem decisões fundamentadas, gerenciem riscos e garantam a integridade e a segurança de seus projetos de software.