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

SBOMs na cadeia de suprimentos de software: lições aprendidas com o backdoor XZ Utils

O caso do backdoor XZ Utils, identificado como CVE-2024-3094, envolveu um backdoor malicioso inserido em um utilitário Linux amplamente utilizado. Esta vulnerabilidade foi descoberta por Andres Freund pouco antes de sua integração nas principais distribuições Linux, colocando em risco milhões de servidores. O pesquisador encontrou essa vulnerabilidade antes de entrar em produção, evitando qualquer dano real. Embora os SBOMs não desempenhassem um papel neste caso específico, eles seriam cruciais se a vulnerabilidade tivesse se espalhado, como visto com o Log4j em 2021. Em uma vulnerabilidade generalizada como o Log4j, as plataformas SBOM poderiam efetivamente ajudar na compreensão do raio da explosão e realização de análises de impacto. Se a vulnerabilidade XZ Utils tivesse sido implementada, ferramentas como o Scribe Hub poderiam ter sido fundamentais para alertar as empresas, permitindo-lhes pesquisar o seu inventário de software, bloquear a implementação de versões comprometidas e melhorar a sua postura geral de segurança.

Definição de lista de materiais de software

A lista de materiais de software (SBOM) lista todas as partes componentes e dependências de software envolvidas no desenvolvimento e entrega de um aplicativo. SBOMs são semelhantes às listas de materiais (BOMs) usadas nas cadeias de suprimentos e na fabricação. Não existe um recurso comum para todos os fornecedores do setor de TI descrever com precisão os componentes básicos do código nos quais um aplicativo é criado.

O SBOM típico incluiria informações de licenciamento, números de versão, detalhes de componentes e fornecedores. Uma lista formal de todos os fatos diminui os riscos tanto para o fabricante quanto para o usuário, permitindo que outros entendam o que está em seu software e ajam de acordo. Os SBOMs não são novidade na indústria de software, mas estão se tornando cada vez mais vitais à medida que o desenvolvimento se torna mais sofisticado e caro. Ultimamente, eles se tornaram um requisito básico em várias empresas.

Protegendo aplicativos nativos da nuvem: o poder dos SBOMs aprimorados

A ascensão dos aplicativos nativos da nuvem introduziu uma complexidade crescente na proteção de ambientes de software modernos. Estas aplicações, caracterizadas pela sua natureza dinâmica e distribuída, são compostas por microsserviços interligados e componentes externos, aumentando a superfície de ataque. O aprimoramento dos SBOMs torna-se fundamental neste contexto, pois eles fornecem visibilidade detalhada de todos os componentes e dependências dentro de uma arquitetura nativa da nuvem. Um SBOM eficaz ajuda a identificar vulnerabilidades, garante a conformidade com os padrões de segurança e facilita a resposta rápida a incidentes. Ao aproveitar SBOMs robustos, as organizações podem manter um inventário abrangente de seus ativos de software, rastrear alterações e detectar antecipadamente possíveis riscos de segurança. Na era dos aplicativos nativos da nuvem, aprimorar as práticas SBOM é indispensável para reforçar a segurança e manter a integridade de ecossistemas de software complexos.

Benefícios do SBOM

Lida com ameaças à integridade

Os ataques podem acontecer em qualquer ponto de uma cadeia normal de fornecimento de software e estes ataques estão a tornar-se mais visíveis, perturbadores e dispendiosos no mundo de hoje. A integridade pode ser mantida usando um SBOM, verificando se os componentes e arquivos que aparecem nele são os mesmos pretendidos. Por exemplo, um dos componentes do formato CycloneDX é um valor hash que pode ser usado na correspondência exata de arquivos e componentes. Como um SBOM não é um documento estático, ele deve ser atualizado sempre que houver alteração no software descrito ou em seus componentes.

Permite visibilidade dos componentes do produto

As empresas devem criar a confiança do cliente para gerar fidelidade e promover compras repetidas. Em vez de garantias ou promessas, os SBOMs partilhados proporcionam maior visibilidade sobre a qualidade das tecnologias que utilizam.

Permite uma verificação de vulnerabilidades mais fácil

As empresas podem usar SBOMs para identificar e eliminar vulnerabilidades antes que cheguem à produção. Novas vulnerabilidades no software de produção podem ser corrigidas rapidamente. No final das contas, os SBOMs ajudam os engenheiros a descobrir e resolver falhas de segurança mais rapidamente.

Aproveita a governança de licenciamento para seu produto

A adoção da Lista de Materiais de Software pode ajudar a aprimorar a governança de licenciamento de software. Cada software vem com uma licença que especifica como ele pode ser usado e distribuído legalmente. Os componentes constituintes de uma cadeia de abastecimento que constituem uma aplicação completa podem ter uma variedade de licenças diferentes. Qualquer empresa que utilize o programa é legalmente obrigada a seguir o licenciamento. Pode não haver maneira de determinar o que as licenças precisam ou como cumpri-las sem uma lista de materiais do software.

Princípios de um SBOM bem formado

Os componentes mínimos de um SBOM bem formado são divididos em três categorias:

Campos de Dados

O objetivo desses campos é fornecer a identificação adequada desses componentes. Isso permite monitorá-los ao longo da cadeia de fornecimento de software e relacioná-los a outras fontes de dados úteis, como vulnerabilidades ou bancos de dados de licenças. Alguns exemplos de campos de dados são nome do fornecedor, nome do componente, versão do componente, outros identificadores exclusivos, relacionamento de dependência, autor dos dados SBOM e carimbo de data/hora.

Suporte de automação

As organizações que desejam ficar de olho nos dados dos componentes SBOM exigirão que eles sejam fornecidos em um estilo consistente e fácil de entender. Isso é abordado na seção de requisitos básicos do SBOM em “Suporte de automação”. Ao enviar SBOMs através das fronteiras organizacionais, existem três padrões para escolher:

1. Troca de dados do pacote de software (SPDX)
2. CicloneDX
3. Etiquetas de identificação de software (SWID)

Eles serão discutidos mais adiante neste artigo.

Práticas e Processos

Finalmente, a seção “Práticas e Processos” apresenta seis padrões sobre como e quando os SBOMs devem ser atualizados e fornecidos. Eles são os seguintes:

• Se o componente de software for atualizado com uma nova compilação ou versão, novos SBOMs deverão ser produzidos.
• Os autores de SBOMs devem incluir componentes de nível superior, bem como suas dependências transitivas.
• Se o SBOM não oferecer uma árvore de dependências completa, o autor do SBOM deve explicar se isso ocorre porque (a) o componente não possui mais dependências ou (b) a existência de dependências é desconhecida e incompleta.
• Os SBOMs devem ser distribuídos e entregues “oportunamente”, com “direitos de acesso e funções adequados em vigor”.
• As empresas que desejam manter alguns componentes de um SBOM em segredo devem especificar parâmetros de controle de acesso, que conteriam regras e procedimentos específicos para incorporar informações relacionadas ao SBOM no manual e nas ferramentas do usuário. Simplificando: se há algo que deve ser mantido em segredo para o bem da organização, então o processo de mantê-lo em segredo é definido nesta seção. 
• Como os padrões que controlam a geração do SBOM são novos, os usuários do SBOM são aconselhados a perdoar falhas ou omissões (não intencionais).

Diferentes formatos SBOM

Claro, você pode gerar manualmente uma fatura SBOM listando os vários componentes do software que você produziu. No entanto, manter enormes bases de código com dezenas ou até centenas de dependências e componentes de terceiros é uma tarefa cansativa e demorada, especialmente para desenvolvedores que gerenciam grandes bases de código com vários componentes e dependências de terceiros. Alguns desenvolvedores podem ter incluído componentes de terceiros em um aplicativo sem documentá-lo. Como resultado, os desenvolvedores atuais podem não estar familiarizados com toda a base de código.

Para tornar a adoção uma realidade, os SBOMs devem aderir a padrões aceitos pela indústria que permitam a interoperabilidade entre diversos setores e organizações. As organizações já possuem a arquitetura implementada para desenvolver, gerenciar e distribuir dados de componentes de software, graças a alguns padrões.

SPDX: troca de dados de pacotes de software

O Troca de dados do pacote de software (SPDX) é o principal padrão aberto para formatos de lista de materiais de software desenvolvido pela Linux Foundation em 2010. Componentes de software, direitos autorais, licenças e referências de segurança estão todos incluídos nos arquivos SPDX. A especificação SPDX é compatível com a proposta da NTIA Padrões mínimos SBOM e casos de uso. As organizações podem usar o SPDX Lite para trocar dados, pois é uma versão condensada do padrão SPDX. O SPDX obteve um padrão oficial como ISO/IEC 5962 em agosto de 2021.

documento spdx

SWID: Marcação de identificação de software

O Organização Internacional de Padrões (ISO) começou a estabelecer um padrão para marcar componentes de software com IDs legíveis por máquina antes do final da década. As tags SWID, como são conhecidas agora, são metadados estruturados incorporados em software que transmitem informações como nome do produto de software, versão, desenvolvedores, relacionamentos e muito mais. As tags SWID podem ajudar a automatizar o gerenciamento de patches, validação de integridade de software, detecção de vulnerabilidades e permissão ou proibição de instalações de software, semelhante ao gerenciamento de ativos de software. Em 2012, a ISO/IEC 19770-2 foi confirmada e modificada em 2015. Existem quatro tipos principais de tags SWID que são usadas em vários estágios do ciclo de vida de desenvolvimento de software:

1. Tags do Corpus: Eles são usados ​​para identificar e caracterizar componentes de software que não estão prontos para serem instalados. As tags Corpus são “projetadas para serem utilizadas como entradas para ferramentas e procedimentos de instalação de software”, de acordo com o Instituto Nacional de Padrões e Tecnologia.
2. Tags primárias: O objetivo principal de uma tag é identificar e contextualizar itens de software depois de instalados.
3. Tags de patch: As tags de patch identificam e descrevem o patch (em oposição ao próprio produto principal). As tags de patch também podem incorporar, e muitas vezes o fazem, informações contextuais sobre a relação do patch com outros produtos ou patches.
4. Tags suplementares: Tags suplementares permitem que usuários de software e ferramentas de gerenciamento de software adicionem informações úteis de contexto de utilidade local, como chaves de licenciamento e informações de contato de partes relevantes.

Quando se trata de determinar quais tags e dados precisos oferecer com seus produtos, as empresas têm uma margem de manobra considerável. Além dos dados obrigatórios, o padrão SWID especifica vários componentes e características opcionais. Finalmente, apenas algumas características que caracterizam o produto de software (como nome e ID da etiqueta) e a entidade que o gerou são necessárias para uma etiqueta básica válida e compatível.

CicloneDX

Em 2017, a Fundação OWASP lançou CicloneDX como parte do Dependency-Track, uma ferramenta de análise de componentes de software de código aberto. CycloneDX é um padrão leve para uso em vários setores, com casos de uso como detecção de vulnerabilidades, conformidade de licenciamento e avaliação de componentes antigos. CycloneDX 1.4 foi lançado em janeiro de 2022. O Cyclone DX pode lidar com quatro tipos diferentes de dados:

• Metadados do fluxograma de materiais: Contém informações sobre a aplicação/produto em si, como fornecedor, fabricante e componentes descritos no SBOM, bem como quaisquer ferramentas utilizadas para criar um SBOM.
• Componentes: Esta é uma lista abrangente de componentes proprietários e de código aberto, juntamente com informações de licença.
• Serviços: URIs de endpoint, requisitos de autenticação e travessias de limites de confiança são exemplos de APIs externas que o software pode usar.
• Dependências: incluem conexões diretas e indiretas.

Fonte: CicloneDX

Qual é a aparência de um SBOM?

Para a identificação de riscos, é necessário um inventário completo e preciso de todos os componentes próprios e de terceiros. Todos os componentes diretos e transitivos, bem como as dependências entre eles, devem ser incluídos nas BOMs. Por exemplo, os seguintes tipos de componentes podem ser descritos usando CycloneDX:

{ "bomFormat": "CycloneDX", "specVersion": "1.4", "serialNumber": "urn:uuid:3e673487-395b-41h8-a30f-a58468a69b79", "versão": 1, "componentes": [ { " type": "biblioteca", "nome": "nacl-library", "versão": "1.0.0" } ] }

Formato XML:

 biblioteca nacl 1.0

Por que assinar seu SBOM?

O que é uma assinatura digital?

A assinatura digital é exatamente o que parece: uma versão eletrônica da tradicional assinatura em papel e caneta. Verifica a validade e integridade das comunicações e documentos digitais utilizando uma abordagem matemática sofisticada. Ele garante que o conteúdo de uma mensagem não seja adulterado durante o trânsito, ajudando-nos a superar o problema da falsificação de identidade e da adulteração nas comunicações digitais. A adoção de assinaturas digitais aumentou ao longo do tempo e é um padrão criptográfico. 

Como funcionam as assinaturas digitais

As assinaturas digitais são criadas usando criptografia de chave pública, também conhecida como criptografia assimétrica. Uma abordagem de chave pública como RSA (Rivest-Shamir-Adleman) gera duas chaves, uma privada e outra pública, levando a um par de chaves matematicamente relacionado. Um dos principais mecanismos por trás das assinaturas digitais é o hashing. Ele transforma efetivamente os dados em uma saída de tamanho fixo, independentemente do tamanho da entrada. Isso é feito por meio de funções hash, que são basicamente algoritmos, e a saída que produzem é chamada de valor hash. As funções hash criptográficas geram um valor hash que atua como uma impressão digital, tornando-o único para todos. Assim como a impressão digital de cada pessoa é diferente, diferentes mensagens de entrada gerarão diferentes valores de hash. As duas chaves criptográficas de autenticação mútua da criptografia de chave pública (PKC) são usadas principalmente para assinaturas digitais. O criador da assinatura digital usa uma chave privada para criptografar os dados relacionados à assinatura, e esses dados só podem ser decodificados usando a chave pública do signatário. É assim que um destinatário sabe que o remetente não está comprometido e que os dados recebidos estão corretos. Actualmente, lidar com infra-estruturas de chave pública é dispendioso e complicado, uma vez que as pessoas muitas vezes perder suas chaves privadas como se alguém perdesse suas chaves físicas. As Autoridades de Certificação (CAs) atuam como terceiros confiáveis ​​e emitem assinaturas digitais aceitando, verificando, emitindo e mantendo certificados digitais. As CAs ajudam a impedir a criação de certificados digitais falsos. Também valida o provedor de serviços de confiança (TSP). Um TSP é uma pessoa física ou jurídica que valida assinaturas digitais em nome de uma empresa e comunica os resultados da validação.

Benefícios de um SBOM assinado digitalmente

Um SBOM assinado fornece uma soma de verificação, que é uma longa sequência de letras e números que representa a soma dos dígitos precisos de um dado digital e pode ser comparada para encontrar falhas ou alterações. Uma soma de verificação é semelhante a uma impressão digital. Regularmente, verifica a redundância (CRC). Alterações nos dados brutos em redes digitais e dispositivos de armazenamento são detectadas usando um código de detecção de erros e uma função de verificação. Dado que a assinatura digital se destina a servir como uma forma validada e segura de comprovar a autenticidade nas transações – ou seja, uma vez assinada, uma pessoa não pode reivindicar o contrário – ela obriga todos os signatários aos procedimentos e ações estabelecidos no projeto de lei. 

Problemas com um SBOM não assinado

Como um dos principais objetivos das assinaturas digitais é a verificação, um SBOM não assinado não é verificável. Pense nisso como um contrato: se um contrato não foi assinado pelas partes participantes, não há nenhuma maneira real de aplicá-lo. Da mesma forma, um SBOM não assinado é apenas um documento não assinado: seu cliente não pode responsabilizá-lo.  Isto também pode levar a mais problemas no futuro, já que um SBOM não assinado também pode representar riscos para a segurança da sua organização. Qualquer coisa que pudesse ter sido protegida por um SBOM assinado agora não está protegida e, portanto, os dados e informações podem ser enviados ou replicados em qualquer lugar. Um dos principais objetivos dos SBOMs assinados – a responsabilidade – é perdido quando um SBOM não é assinado, pois alterações podem ser feitas nele sem consequências por parte do criador ou do cliente. 

Usando SBOM para aprimorar a segurança cibernética

Os SBOMs estão entre as melhores formas para as organizações manterem a segurança e a autenticidade dos seus dados e procedimentos. Eles também estabeleceram um precedente no setor ao aumentar a abertura entre desenvolvedores, fornecedores de software e clientes. As organizações podem informar com segurança aos parceiros detalhes operacionais durante todo o processo de contratação se os padrões estiverem em vigor. As organizações terão mais sucesso na identificação de falhas, vulnerabilidades e ameaças de dia zero à medida que os SBOMs se tornarem mais difundidos. A adoção da lista de materiais de software é um claro ganho para a segurança da cadeia de fornecimento de software em todo o mundo.

Usando VEX para obter mais usabilidade de seu SBOM

Vulnerability Exploitability eXchange (VEX) é um aviso de segurança que visa expor a explorabilidade de vulnerabilidades no contexto do produto em que são encontradas. Ao executar uma verificação de vulnerabilidades na maioria dos aplicativos modernos, os resultados podem facilmente chegar a centenas ou milhares de vulnerabilidades. Do número total de vulnerabilidades descobertas, apenas cerca de 5% são realmente exploráveis. Também é importante lembrar que a explorabilidade quase nunca é um problema isolado. Na maioria das vezes, é um caso de uso complexo de bibliotecas de código aberto, módulos e o código que os utiliza trabalhando juntos que transformam uma vulnerabilidade em um problema realmente explorável. Até que você altere seu aplicativo e execute um novo SBOM para descrevê-lo, o inventário descrito em uma BOM normalmente permanecerá estático. As informações sobre vulnerabilidades são muito mais dinâmicas e sujeitas a mudanças. Ter suas informações VEX disponíveis como uma lista independente torna possível atualizar os dados VEX sem a necessidade de gerar e gerenciar BOMs adicionais. A CISA fornece uma lista dos elementos de dados mínimos recomendados que deve ser incluído em um comunicado ou documento útil da VEX. Estes são:

Metadados VEX: Identificador de formato VEX, String identificadora do documento VEX, Autor, Função do autor, Carimbo de data e hora. 

Detalhes do produto: Identificador(es) de produto ou identificador de família de produto (por exemplo, identificador exclusivo ou uma combinação de nome do fornecedor, nome do produto e string de versão, conforme estabelecido na orientação estabelecida do SBOM3). 

Detalhes de vulnerabilidade: Identificador da vulnerabilidade (CVE ou outros identificadores) e descrição da vulnerabilidade (por exemplo, descrição do CVE). 

Status do produto Detalhes (ou seja, informações de status sobre uma vulnerabilidade nesse produto): 

• NÃO AFETADO – Nenhuma correção é necessária em relação a esta vulnerabilidade.
• AFETADO – São recomendadas ações para remediar ou resolver esta vulnerabilidade.
• CORRIGIDO – Essas versões do produto contêm uma correção para a vulnerabilidade. 
• SOB INVESTIGAÇÃO – Ainda não se sabe se essas versões de produtos são afetadas pela vulnerabilidade. Uma atualização será fornecida em uma versão posterior.

Superando os desafios da adoção do SBOM

Incorporar o SBOM no ciclo de vida de desenvolvimento de software (SDLC) de uma organização apresenta vários desafios. Primeiro, gerar e manter SBOMs precisos pode ser demorado e caro, exigindo investimentos significativos em ferramentas e processos. Os desafios do SBOM também incluem a integração do gerenciamento do SBOM com pipelines de CI/CD existentes, o que pode envolver a simplificação da integração do pipeline de CI/CD. Além disso, garantir a integridade e a precisão dos SBOMs exige um rastreamento meticuloso de todos os componentes de software, incluindo dependências de terceiros. Outro obstáculo significativo é a promoção de uma cultura de transparência e sensibilização para a segurança entre as equipas de desenvolvimento, o que é crucial para a adoção bem-sucedida de práticas SBOM. Superar estes desafios SBOM requer uma abordagem estratégica, combinando ferramentas robustas, formação eficaz e um forte compromisso organizacional para melhorar a segurança da cadeia de fornecimento de software.

Resumo

Concluindo, embora os SBOMs ainda sejam uma ideia nova para a maioria das organizações, espera-se que a capacidade de produzir SBOMs se torne mais significativa no futuro. Se você ainda não começou a incorporar a criação de SBOM em seu processo de entrega de software, este é um ótimo momento para fazê-lo.