0
0
Com a Ordem Executiva 14028 , começou um grande impulso regulatório para obrigar a produção de uma lista de materiais de software (SBOM). À medida que essa nova palavra da moda se espalha, você pensaria que era uma cura milagrosa para proteger a cadeia de suprimentos de software . Conceitualmente, faz sentido – saber o que está em um produto é uma expectativa razoável. No entanto, é importante entender o que exatamente é um SBOM e se ele pode ou não ser objetivamente útil como ferramenta de segurança.
Entendendo os SBOMs
SBOMs devem ser algo como um rótulo nutricional na parte de trás de um item de mercearia listando todos os ingredientes que foram usados para fazer o produto. Embora atualmente não exista um padrão SBOM oficial, alguns formatos de diretrizes surgiram como principais candidatos. De longe, o mais popular é o Software Data Package Exchange ( SPDX ), patrocinado pela Linux Foundation.
O SPDX, como a maioria dos outros formatos, tenta fornecer uma maneira comum de representar informações básicas sobre os ingredientes que entram na produção de software: nomes, versões, hashes, ecossistemas, dados auxiliares como falhas conhecidas e informações de licença e ativos externos relevantes . No entanto, o software não é tão simples quanto uma caixa de cereal, e não há equivalente à Food and Drug Administration que impõe a conformidade com as diretrizes recomendadas.
Tudo é opcional, portanto, nada é necessário
Uma das maiores e mais óbvias lacunas no SPDX e em outros padrões é que, como o ecossistema de código aberto em geral, é um conjunto de comunidades construídas em diretrizes gerais, não em padrões verificados. As comunidades de código aberto são amplas e extensas, com colaboradores de todo o mundo. Muitas vezes, gerenciadores de pacotes e ambientes de hospedagem são projetados por comitês separados, cada um operando isoladamente. Embora os mandatos SBOM representem uma tentativa inicial de unificar esses muitos silos de informações, eles sofrem algumas das limitações fundamentais da aplicação retroativa de um padrão.
Em primeiro lugar, as rachaduras começam a aparecer quando consideramos o que o SPDX realmente oferece. Como se vê, quase todos os campos do padrão são opcionais. Embora essa opcionalidade de campos seja claramente um artefato de quão diferentes são os muitos ecossistemas de software que o formato tenta cobrir, um SBOM perde seu valor como uma fonte real de verdade se não houver necessidade de hashes criptográficos ou outras informações que nos permitiriam associar positivamente a biblioteca às informações apresentadas no documento SBOM.
SBOMs perdem a marca na proveniência
Além de incompletas, muitas das entradas não podem ser representadas adequadamente nos formatos atuais, principalmente de locais como repositórios de sistemas de controle de versão. Enquanto alguns frameworks emergentes como o SLSA tentam aplicar noções de proveniência, nenhum formato atinge o alvo. Devemos incorporar dados de proveniência precisos no formato SBOM para garantir que tenhamos uma visão razoável do que está dentro do software que estamos consumindo. Isso deve incluir o seguinte, no mínimo:
- Informações de identidade do autor: Tanto os mantenedores quanto os contribuidores são uma parte crítica da cadeia de fornecimento de software. Eles detêm as chaves proverbiais do reino e escolhem como o software que consumimos a jusante é lançado. Mesmo que dados completos não possam ser capturados, podemos absolutamente fazer melhor do que o que é fornecido hoje, que não é nada.
- Ferramentas de desenvolvimento: Isso inclui ferramentas de construção, infraestrutura de CI/CD e ferramentas usadas durante o desenvolvimento de software upstream. Qual é a vantagem de proteger sua infraestrutura de desenvolvimento interna se um comprometimento em qualquer biblioteca que você usa ainda pode causar um comprometimento interno?
- Controles e proteções: Se um dos objetivos é o gerenciamento de riscos de terceiros, devemos perguntar: Como é a postura de segurança da equipe de desenvolvimento? A proteção de ramal está sendo usada? Que tipo de processos de revisão são aplicados?
- Atestado de artefato: absolutamente devemos ser capazes de vincular uma entrada em um documento SBOM a um artefato real. Isso deve incluir um artefato de construção real, como um pacote compilado, bem como artefatos continuamente desenvolvidos, como ramificações marcadas em um sistema de controle de versão.
Realisticamente, devemos construir uma compreensão de cada um desses elementos para compreender o que se passa no software que estamos utilizando antes mesmo de considerar como um SBOM pode ser operacionalizado.
Não podemos confiar em um simples instantâneo no tempo
Por fim, o maior desafio com a ampla adoção do SBOM é que o formato estático só fornece a verdade naquele momento. Para serem significativos, os SBOMs devem ter a capacidade de serem entregues e acessados continuamente.
Considere, por exemplo, que você receberia um SBOM de fornecedor de seu provedor de armazenamento em nuvem. Este SBOM não seria apenas um documento contendo dezenas de milhares de peças individuais de software, mas também conteria muitos múltiplos de versões desses pacotes de software. Agora, considere que, no momento em que você receber essa informação, ela provavelmente já estará desatualizada. Isso ocorre porque as grandes empresas geralmente enviam centenas ou milhares de compilações por dia. No momento em que você processou, consumiu e raciocinou sobre um SBOM para qualquer grande fornecedor, os dados já estão obsoletos.
As versões serão alteradas, novos pacotes serão adicionados e alguns pacotes podem ter sido removidos. As melhores práticas de desenvolvimento modernas significam que as compilações e entregas devem ser contínuas, o que leva a uma iteração mais rápida e a ciclos de lançamento mais rápidos. Isso também significa que a entrega de um único SBOM não tem sentido. O que isso realmente implica é que há um forte requisito de automação escalável em torno de SBOMs para que eles forneçam valor real.
A intenção por trás dos SBOMs é pavimentar o caminho para uma melhor visibilidade, tanto interna quanto externamente. No entanto, não se engane pensando que eles protegerão sua cadeia de suprimentos de software. Precisamos de mais do que um instantâneo incompleto a tempo de ter um impacto real.
FONTE: DARK READING