Software Bill of Materials (SBOM): entenda por que eles são essenciais para a cibersegurança

Os SBOMs são um recurso valioso para:

• Conformidade regulatória

• Compatibilidade entre pacotes de software antigos e atualizações de código aberto

• Proteção dos clientes contra ataques cibernéticos à cadeia de suprimentos de software

• Proteções de segurança em fusões que envolvem software e licenciamento

Diferença entre SBOM e CBOM

O Cybersecurity Bill of Materials (CBOM) de 2018 abrange software e hardware em uma única ordem executiva. O SBOM documenta apenas os componentes de software presentes no código, além do histórico de versões, patches, licenças, atualizações e alterações.

Por que os SBOMs são importantes para a cibersegurança?

Os ataques cibernéticos à cadeia de suprimentos de software estão aumentando. Mais da metade desses ataques vem de grupos de cibercrime estabelecidos que realizam ameaças persistentes avançadas (APT). O objetivo deles é explorar a confiança que usuários e fornecedores depositam em seus sistemas.

A falta de transparência em torno dos incidentes cibernéticos deixa a cadeia de suprimentos vulnerável. Em alguns casos, os desenvolvedores desconhecem possíveis vulnerabilidades e, por consequência, os usuários também podem ficar expostos. Bibliotecas de código aberto dependem de outros componentes de software. Vulnerabilidades como a Log4Shell são exemplos de componentes — nesse caso, uma biblioteca de registro de logs — que muitos desenvolvedores nunca verificam por não serem uma dependência direta de software, mas sim uma dependência transitiva, da qual outros componentes dependem.

As equipes de desenvolvimento já reconhecem a importância da segurança de aplicações, mas os SBOMs trazem mais visibilidade às cadeias de suprimentos de software e às possíveis vulnerabilidades. Quando os usuários sabem onde pode haver vulnerabilidades em um produto de software — e conhecem os componentes do software, especialmente se foremde código aberto —, ficam mais preparados para implementar ferramentas de segurança que detectem e ajudem a corrigir possíveis ataques.

Em caso de ataque cibernético, o SBOM pode ajudar a identificar quais softwares têm componentes vulneráveis e qual é o tipo de risco envolvido. Assim, os usuários podem trabalhar com os desenvolvedores para criar um patch ou outra solução de mitigação.

Ordem Executiva 14028 sobre SBOMs

Antes da Log4Shell, outros incidentes cibernéticos, como o ataque à cadeia de suprimentos da SolarWinds e o incidente da Equifax relacionado ao Apache Struts, mostraram como órgãos governamentais, grandes empresas e negócios estão vulneráveis em toda a infraestrutura crítica. Esses casos também evidenciaram a dependência de todas as organizações em relação à cadeia de suprimentos de software e como uma única vulnerabilidade explorada pode desencadear efeitos em larga escala.

A Ordem Executiva 14028 exige que órgãos governamentais, incluindo o National Institute of Standards and Technology (NIST), a National Security Agency (NSA), o Office of Management and Budget (OMB), a Cybersecurity & Infrastructure Security Agency (CISA) e o Director of National Intelligence (DNI), desenvolvam padrões e boas práticas para melhorar a segurança da cadeia de suprimentos de software. As diretrizes incluem:

• Critérios para avaliar a segurança do software

• Critérios para avaliar as práticas de segurança dos próprios desenvolvedores e fornecedores

• Ferramentas ou métodos inovadores para demonstrar a conformidade com práticas seguras

Até fevereiro de 2022, o NIST e os outros órgãos publicarão diretrizes de boas práticas para a cadeia de suprimentos de software. Enquanto isso, confira nossa lista de boas práticas de segurança para a cadeia de suprimentos que você já pode implementar.

Quando você deve usar um Software Bill of Materials?

Um novo SBOM deve ser criado a cada nova versão de um componente de software. Da mesma forma, o SBOM deve ser atualizado sempre que um componente for alterado.

A base mínima definida pela NTIA para um SBOM exige as seguintes informações:

• nome do autor

• nome do fornecedor

• nome do componente

• hash do componente

• string da versão

• identificador

• relacionamento

Para atender aos requisitos mínimos, foram desenvolvidos padrões de SBOM com um formato comum que pode ser usado em diversas ferramentas. Esses padrões são:

• SPDX: o Software Product Data Exchange é um padrão aberto para comunicar os componentes, as licenças e as informações de segurança de pacotes de software. O SPDX padroniza vários serviços, cada um com seu próprio SBOM.

• SWID: as Software Identification Tags são padrões que definem um ciclo de vida. As tags são adicionadas ao endpoint durante a instalação do software. Há quatro tipos de tag: Corpus, usadas na etapa anterior à instalação; primary, que fornecem o nome do produto e são consideradas identificadores globalmente exclusivos; patch, que descrevem patches aplicados ao software; e supplemental, que trazem informações adicionais.

• OWASP Cyclone DX: um padrão leve de SBOM usado para analisar componentes da cadeia de suprimentos e a segurança de aplicações.

• VEX: o Vulnerability Exploitability Exchange oferece informações adicionais sobre o produto, identificando vulnerabilidades encontradas nos componentes e recomendando ações para corrigi-las.

SBOMs e a integridade do software

Os SBOMs ajudam a avaliar a integridade da cadeia de suprimentos de software e permitem analisar riscos com base nas informações coletadas. Em uma avaliação geral, eles servem para inventariar os componentes de software da cadeia de suprimentos. Quando os padrões são aplicados, porém, os SBOMs atendem aos padrões de conformidade de OSS. Por exemplo, o padrão SPDX identifica as licenças desses componentes e ajuda a garantir a conformidade com elas.

Supply Chain Levels for Software Artifacts (SLSA) é um conjunto de padrões e controles que busca ajudar a manter a integridade dos artefatos de software de código aberto na cadeia de suprimentos. Criado pelo Google, atende às recomendações do NIST para a segurança da cadeia de suprimentos. O SLSA complementa os SBOMs nos esforços para proteger a grande quantidade de software de código aberto usada ao longo do processo de desenvolvimento.

Como usar SBOMs para encontrar dependências e vulnerabilidades

O principal objetivo dos SBOMs em segurança é identificar vulnerabilidades e riscos em toda a cadeia de suprimentos de software. As informações sobre vulnerabilidades mudam constantemente à medida que componentes são adicionados ou alterados, o que pode introduzir novas formas de exploração. Os SBOMs são basicamente estáticos, mas os dados usados para criá-los estão sempre mudando e evoluindo.

O SBOM é uma ferramenta para clientes de software que querem analisar vulnerabilidades e verificar se os desenvolvedores estão atualizando as dependências para reduzir riscos. Mas nem todas as vulnerabilidades apresentam o mesmo nível de risco — algumas não oferecem risco algum. Para lidar com essa questão, a NTIA propõe duas etapas:

• No lado do desenvolvimento e do fornecimento, é preciso determinar o impacto da vulnerabilidade, especificamente se ela afetará áreas específicas do software.

• As informações sobre a vulnerabilidade devem ser comunicadas com clareza por meio dos dados do SBOM, com a confirmação de que ela não aumenta o risco.

SBOMs para a segurança da cadeia de suprimentos

Os SBOMs reforçam a segurança da cadeia de suprimentos de software das seguintes formas:

• Mais visibilidade do produto de software, incluindo as relações entre os sistemas

• Compartilhamento de informações sobre vulnerabilidades

• Melhor comunicação em toda a cadeia de suprimentos, do desenvolvedor ao usuário, facilitando a identificação de riscos de segurança

• Registros detalhados de auditorias e padrões de conformidade

O SBOM é uma ferramenta de segurança em constante evolução que oferece mais proteção e ajuda a detectar riscos em toda a cadeia de suprimentos de software. Com informações mais precisas e detalhadas sobre cada componente, o SBOM ajuda a descobrir vulnerabilidades no início do ciclo de produção do software e, assim, permite mitigá-las antes que causem danos.

O Snyk pode automatizar a criação de SBOMs, facilitando o acompanhamento dos componentes de código aberto e das dependências usados pelas organizações. O Snyk também pode analisar cada componente para encontrar possíveis vulnerabilidades e oferecer recomendações práticas para corrigi-las.