As vulnerabilidades do código estão a aumentar em frequência e impacto. Como o software é cada vez mais composto por peças de diferentes fornecedores, frequentemente referidos como a cadeia de fornecimento de software, pode ser difícil encontrá-los e corrigi-los rapidamente.

Uma solução para este problema é a utilização de uma Lista de Materiais de Software (SBOM). (SBOM – lista de materiais de software). Allan Friedman, director de iniciativas de cibersegurança na Administração Nacional de Telecomunicações e Informação (NTIA) do Departamento de Comércio dos EUA, partilhou a importância de ser transparente sobre o funcionamento interno do código através de uma SBOM.

O que é a SBOM?

SBOM é um conjunto de metadados que descreve a árvore de dependência de um pacote de software. Inclui informações chave tais como fornecedor, número da versão e nome do componente. Detalhes básicos como estes são críticos quando se analisa o software para detectar vulnerabilidades, uma vez que se baseiam numa variedade de componentes, conforme detalhado no fluxograma abaixo (Figura 1).

image

Figura 1: Exemplo de elementos SBOM

Qual é o valor de uma SBOM?

A transparência ajuda os mercados a prosperar. Por exemplo, os ingredientes alimentares e os rótulos dão às pessoas o conhecimento de que necessitam para fazer escolhas inteligentes. Os rótulos não garantem que as pessoas irão comer de forma saudável, mas dão-lhes a informação para fazerem escolhas alimentares saudáveis. Da mesma forma, uma SBOM não resolverá automaticamente todos os problemas de segurança, mas capacita as equipas a resolvê-los mais rápida e facilmente.

Os SBOMs podem também falar-lhe de um componente de software. Por exemplo, se verificar que existem seis versões de um pacote numa SBOM, existe um elevado risco de que uma delas seja vulnerável.

As capacidades vão para além das vulnerabilidades até à redundância. Por exemplo, a questão de saber quantos projectos de código aberto dependem de um único componente. Isto é descrito como o “problema do cavaquinho”, ou o proprietário do projecto poderia simplesmente abandonar o passatempo e ocupar-se do cavaquinho e deixar todos os projectos dependentes.

Porque não estamos a fazer isto hoje?

Há muitas razões pelas quais as SBOMs não são prática corrente hoje em dia. Enquanto eles estão gradualmente a ganhar terreno, ainda há um problema de galinhas e ovos onde ninguém o pede e por isso não é fornecido.

Além disso, uma SBOM não é necessariamente fácil de criar em cadeias de abastecimento. Como novo conceito, a indústria debate-se com as melhores práticas e ferramentas à sua volta. Por exemplo, uma SBOM requer uma nomeação consistente, onde os fornecedores e mesmo os colegas de trabalho do mesmo grupo podem atribuir nomes diferentes ao mesmo componente.

Existem também preocupações de licenciamento e de fonte aberta.

Como construir uma SBOM

Existem alguns princípios orientadores para fazer SBOMs utilizando o processo NTIA. O mais importante é perceber que é preciso rastejar antes de se poder andar. É necessária uma SBOM de base para que as equipas se possam alinhar à sua volta. Os SBOMs criados devem ser legíveis por máquina para que possam ser facilmente automatizados e depois publicados num local conhecido ou descoberto para fácil acesso e análise.

Como implementar uma SBOM

Existem hoje três formatos para implementar uma SBOM:

  • SPDIX : Um esforço de base da Fundação Linux. O software é um padrão aberto para a comunicação de informação SBOM, incluindo componentes, licenças, direitos de autor e referências de segurança.
  • CycloneDX : concebido especificamente para contextos de segurança e análise de componentes da cadeia de abastecimento.
  • SWID Tags – Composto por ficheiros que registam informação única sobre um componente de software e ajudam nas iniciativas de gestão de inventário.

Exemplo SBOM

Uma grande prova de conceito foi no sector da saúde, aproveitando uma lista de materiais para encontrar vulnerabilidades e componentes exploráveis. Permitiu também que os vendedores fossem informados sobre questões de software com dispositivos médicos importantes.

Ferramentas

Embora haja muitas ferramentas disponíveis para fazer SBOM, a NTIA tem uma taxonomia de ferramentas para ajudar as equipas a escolher a correcta (Figura 2 abaixo).

image

Figura 2: Taxonomia das ferramentas SBOM

A taxonomia centra-se no SBOM:

  • Produção : É importante ter cuidado ao escolher o formato do seu SBOM e gerar artefactos, bem como analisar e editar as listas existentes.
  • Consumo : boas ferramentas permitem às equipas ler o conteúdo e comparar entre SBOMs para detectar diferenças.
  • Transformação : várias fontes de SBOM e outros dados podem ser combinados para auditoria.

A NTIA também encoraja a interoperabilidade entre instrumentos, para que juntos possam aumentar a sensibilização e aumentar a utilização.

Reconhecimento governamental

Tal como foi conseguido com dispositivos médicos (uma questão de vida ou morte), as SBOMs devem ser viáveis para o fazer para outras indústrias e aplicações, como indicado na Figura 3. A actual administração reconhece a importância da ciber-segurança e emitiu uma Ordem Executiva, que descreve as SBOMs e a sua proposta de valor na Secção 4.

image

Figura 3: NTIA SBOM Considerações

O futuro das SBOMs

Não só nos EUA mas globalmente, os governos e a indústria vêem os SBOMs como cada vez mais críticos para a segurança. Vemos um futuro onde os SBOMs são reconhecidos e alavancados.

Existe uma visão para que mais organizações possam aproveitar as SBOMs e ajudar a comunidade a refinar as ferramentas para satisfazer as necessidades mais amplas da indústria. Os SBOM não são a solução para todas as suas preocupações de segurança, mas as equipas reconhecem-nas como parte das decisões de segurança inteligentes.

Fonte: Blog Sonatype


Artigo Original