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

Usar um SBOM – especialmente em OSS – permite que uma organização ganhe visibilidade sobre componentes e dependências, melhore o gerenciamento de riscos e muito mais. Abaixo, descrevemos esses benefícios.

Visibilidade do componente

O OSS geralmente incorpora vários componentes e dependências de terceiros. Um SBOM permite que desenvolvedores e usuários tenham visibilidade clara de todos os componentes usados no software. Isso inclui bibliotecas e estruturas de código aberto, juntamente com suas versões específicas. Essa visibilidade auxilia na compreensão da composição do software, na identificação de vulnerabilidades potenciais e no rastreamento de quaisquer obrigações de licenciamento associadas aos componentes de código aberto.

Gestão de Vulnerabilidades

Assim como qualquer outro software, o OSS pode ser suscetível a vulnerabilidades de segurança. Com um SBOM, as organizações podem rastrear as versões de componentes de código aberto e se manterem informadas sobre quaisquer vulnerabilidades conhecidas associadas a essas versões. Isso permite o gerenciamento proativo de vulnerabilidades por meio da aplicação imediata de patches ou atualizações para mitigar e relatar quaisquer problemas de segurança (consulte RFC8615 ). Ao ter um SBOM atualizado, as organizações podem avaliar o impacto das vulnerabilidades e tomar medidas apropriadas para proteger seu software.

Segurança da Cadeia de Suprimentos

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

Colaboração e gerenciamento de patches

O OSS incentiva a colaboração e o envolvimento da comunidade. Um SBOM facilita a colaboração eficaz ao fornecer um entendimento comum dos componentes do software entre diferentes colaboradores e partes interessadas. Ele auxilia na coordenação dos esforços de gerenciamento de patches, identificando claramente os componentes que exigem atualizações ou correções. A colaboração dentro da comunidade de código aberto se torna mais eficiente quando todos os participantes podem consultar um SBOM compartilhado para abordar 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 seus aplicativos ou sistemas. Um SBOM fornece a documentação necessária para satisfazer esses requisitos de conformidade. Ele permite que as organizações demonstrem a devida diligência, rastreabilidade e conformidade com regulamentações relevantes, especialmente quando se trata de aspectos de segurança e licenciamento de OSS.

Conformidade com a licença

O OSS normalmente é regido por licenças específicas que determinam como o software pode ser usado, modificado e distribuído. Um SBOM fornece uma visão geral abrangente de todos os componentes de código aberto e suas licenças correspondentes. Isso ajuda as organizações a garantir a conformidade com os termos de licenciamento do OSS que estão usando. Ao compreender as obrigações de licenciamento, as organizações podem tomar decisões informadas sobre a distribuição e o uso de seu software, evitando problemas legais ou de conformidade.

Vários governos e organizações em setores altamente regulamentados, como bancos e saúde, estão defendendo o uso de SBOMs ou considerando tornar o uso de um SBOM um requisito, seja internamente ou para seus fornecedores.

Exemplos de indústrias que usam SBOMs

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

A construção de um SBOM exige colaboração e envolvimento de diversas partes interessadas em toda a cadeia de fornecimento de software. Ao envolver essas partes interessadas e promover a colaboração entre elas, as organizações podem criar um SBOM robusto e confiável que capture as informações necessárias sobre os componentes de software, melhore a segurança da cadeia de suprimentos e facilite os esforços de gerenciamento de riscos e conformidade.

Aqui estão alguns indivíduos ou funções importantes que devem estar envolvidos no processo:

• Equipe de desenvolvimento – A equipe de desenvolvimento, incluindo engenheiros de software e desenvolvedores, desempenha um papel crucial na identificação e documentação dos componentes de software usados no projeto. Eles são responsáveis por fornecer informações precisas sobre as dependências, versões e origens dos componentes de software que utilizam.
• Gerentes de projeto – Os gerentes de projeto supervisionam o processo geral de desenvolvimento de software e devem estar envolvidos na construção de um SBOM. Eles podem coordenar com a equipe de desenvolvimento para garantir que as informações necessárias sejam coletadas e documentadas no SBOM. Os gerentes de projeto também desempenham um papel importante em garantir a conformidade com os requisitos do SBOM e integrá-los ao fluxo de trabalho do projeto.
• Equipe de segurança – A equipe de segurança, incluindo analistas e especialistas em segurança, é fundamental na avaliação e no gerenciamento de riscos de segurança associados aos componentes de software. Eles podem fornecer insights sobre vulnerabilidades e problemas de segurança conhecidos relacionados aos componentes listados no seu SBOM. A experiência deles ajuda a identificar potenciais riscos de segurança e priorizar esforços de correção.
• Equipe de aquisição – A equipe de aquisição, ou indivíduos responsáveis pelo fornecimento de componentes de software, desempenha um papel fundamental na construção de um SBOM. Eles podem fornecer informações sobre a origem e 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 por implantar e manter o software. Ao construir um SBOM, eles podem contribuir com informações valiosas sobre o ambiente de execução, configurações de implantação e quaisquer componentes de software adicionais introduzidos durante a fase operacional. Seus insights garantem um SBOM abrangente e atualizado.
• Especialistas jurídicos e de conformidade – Profissionais jurídicos e de conformidade são partes interessadas essenciais na construção de um SBOM, especialmente no que diz respeito a considerações de licenciamento e propriedade intelectual. Eles podem fornecer orientação sobre conformidade de licença e garantir que seu SBOM esteja alinhado com quaisquer requisitos ou restrições legais associados aos componentes de software.
• Fornecedores e parceiros externos – Se o projeto de software incorporar componentes ou serviços de fornecedores ou parceiros externos, envolvê-los no processo SBOM é crucial. 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 um SBOM abrangente e preciso.

As organizações devem aspirar a construir um 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 um melhor gerenciamento dos riscos da cadeia de suprimentos de software e melhora a segurança geral do software.

Aqui estão as principais etapas ao criar um SBOM:

• Identificar e inventariar componentes: Comece identificando cada componente de software usado no seu projeto, incluindo componentes proprietários e de código aberto. Crie uma lista de inventário que inclua informações como nome, versão e origem de cada componente.
• Determinar as origens dos componentes: Para cada componente, determine sua origem, se é proprietário, de código aberto ou uma combinação de ambos. Esta etapa ajuda a avaliar potenciais vulnerabilidades de segurança associadas a diferentes componentes.
• Dependências do documento: Documente as dependências entre os componentes, incluindo quaisquer bibliotecas ou estruturas usadas. Isso ajuda a entender as relações entre diferentes componentes e garante que todas as dependências sejam contabilizadas.
• Reúna metadados: Colete metadados para cada componente, como informações de licença, vulnerabilidades conhecidas e datas de lançamento. Essas informações são cruciais para rastrear os aspectos de segurança e conformidade dos componentes de software.
• Automatize a geração de SBOM: Para agilizar o processo, considere automatizar a geração do SBOM usando ferramentas especializadas. Essas ferramentas podem escanear seu projeto de software, identificar os componentes e coletar as informações necessárias automaticamente.
• Mantenha seu SBOM atualizado: À medida que seu projeto de software evolui, é essencial manter seu SBOM atualizado. Revise e atualize regularmente o inventário, as origens dos componentes, as dependências e os metadados conforme as alterações ocorrem.
• Compartilhe e utilize seu SBOM: Compartilhe seu SBOM com as partes interessadas relevantes em sua cadeia de suprimentos de software, como fornecedores, clientes e auditores. Isso promove transparência, permite uma melhor avaliação de riscos e ajuda a identificar e abordar vulnerabilidades.
• Monitore e gerencie vulnerabilidades: Monitore continuamente novas vulnerabilidades e atualizações de segurança relacionadas aos componentes do seu SBOM. Mantenha-se informado sobre os últimos patches de segurança e corrija quaisquer vulnerabilidades imediatamente para manter a segurança do seu software.

Há várias maneiras pelas quais um SBOM pode falhar ou não atingir seu propósito pretendido. Enfrentar esses desafios e garantir a precisão, integridade e atualidade do seu SBOM pode ajudar a mitigar o risco de falha.

Aqui estão algumas causas comuns de falhas que refletem as melhores práticas para criar um SBOM:

• Inventário incompleto ou impreciso: Se o seu SBOM não capturar com precisão todos os componentes de software usados em um projeto ou contiver informações incompletas, isso pode levar a pontos cegos e lacunas na compreensão da cadeia de suprimentos de software. Inventário ausente ou impreciso pode resultar na negligência de vulnerabilidades ou dependências, prejudicando a eficácia do seu SBOM.
• Falta de visibilidade do componente: Se o seu SBOM não fornecer visibilidade clara sobre as origens, versões e dependências dos componentes de software, será difícil avaliar e gerenciar os riscos associados de forma eficaz. Sem visibilidade abrangente, torna-se desafiador rastrear vulnerabilidades, identificar atualizações de patches e garantir a conformidade com os requisitos de licenciamento.
• Processos manuais e desatualizados: Depender de processos manuais para criar e manter um SBOM pode levar a ineficiências e erros. Se o seu SBOM não for atualizado regularmente para refletir as mudanças no projeto de software, ele rapidamente se tornará desatualizado e perderá seu valor como referência confiável para fins de segurança e conformidade.
• Metadados e contexto insuficientes: Um SBOM deve fornecer mais do que apenas uma lista de componentes de software – ele deve incluir metadados relevantes, como informações de licenciamento, vulnerabilidades conhecidas e datas de lançamento. Se esse contexto adicional estiver ausente ou incompleto, ele dificulta a capacidade de avaliar riscos com precisão e tomar decisões informadas.
• Falta de colaboração das partes interessadas: A colaboração e o compartilhamento de informações entre as partes interessadas na cadeia de fornecimento de software são vitais para a utilização eficaz do SBOM. Se houver falta de cooperação ou relutância em compartilhar informações do SBOM, fica difícil identificar e abordar vulnerabilidades coletivamente, comprometendo a segurança geral do software.
• Ferramentas e automação limitadas: A criação e manutenção manual de um SBOM pode ser demorada e propensa a erros. Sem ferramentas e automação adequadas, torna-se desafiador gerar, atualizar e gerenciar seu SBOM com eficiência. A falta de automação também pode levar a atrasos na identificação de novas vulnerabilidades ou dependências.
• Monitoramento inadequado de vulnerabilidades: Um SBOM deve ser complementado por um processo robusto de monitoramento de vulnerabilidades. Se houver falta de monitoramento regular de novas vulnerabilidades e atualizações de segurança associadas aos componentes do software, riscos potenciais podem passar despercebidos, deixando o software exposto a vulnerabilidades conhecidas.

No geral, um SBOM é uma ferramenta valiosa para gerenciar as complexidades do OSS. Ele promove transparência, segurança, conformidade e colaboração dentro do ecossistema de código aberto. Ao fornecer um inventário detalhado de componentes de software, suas versões e informações de licenciamento associadas, um SBOM capacita as organizações a tomar decisões informadas, gerenciar riscos e garantir a integridade e a segurança de seus projetos de software.