Um SBOM é um guia detalhado do que está dentro do software. Ajuda tanto os fornecedores como os compradores a controlar os componentes, para melhorar a segurança da cadeia de abastecimento.
Por Josh Fruhlinger
Um SBOM é um registo formal e estruturado que não só detalha os componentes de um produto de software, mas também descreve a sua relação com a cadeia de fornecimento: que pacotes e bibliotecas foram para a aplicação e a sua relação com outros projetos, o que é particularmente importante quando se fala de código reutilizado e de código aberto.
Tomemos o exemplo de um carro e a descrição de materiais de todos os componentes que o fazem funcionar. A cadeia de fornecimento de veículos é muito complexa, e embora possa ter sido montada pela Toyota ou pela General Motors, por exemplo, muitos dos seus componentes foram fabricados por terceiros em todo o mundo. Esta lista diz-lhe de onde vem cada parte e o conhecimento não é apenas uma curiosidade interessante. Se uma determinada produção tiver sido recolhida, os fabricantes precisam de uma forma rápida de saber onde encontrar uma peça de substituição ou onde esse componente em particular foi parar.
Escrever software não é exatamente como construir um carro, mas com o uso crescente de bibliotecas de código aberto de terceiros para criar aplicações distribuídas em contentores, os dois processos têm mais em comum do que se possa pensar. É por isso que os SBOMs estão a tornar-se cada vez mais comuns.
Tanto os criadores como os utilizadores podem utilizar um SBOM para compreender o que está incluído exatamente no software que distribuem e utilizam. Isto tem uma série de implicações importantes, especialmente para a segurança.
Porque é necessário um SBOM?
Os dias de bases de código de software proprietário já lá vão há muito tempo. As aplicações modernas são frequentemente construídas com base numa extensa reutilização de código, utilizando frequentemente bibliotecas de código aberto. Estas aplicações são também cada vez mais divididas em pequenos componentes autónomos de funcionalidade, conhecidos como contentores, geridos por plataformas de orquestração, tais como a Kubernetes, que funcionam localmente ou na cloud.
Globalmente, estas mudanças têm sido uma bênção para o desenvolvimento de software e têm aumentado a produtividade dos desenvolvedores e reduzido os custos. Mas, em muitos aspetos, têm sido um pesadelo de segurança. Confiando fortemente no código de terceiros, com cujo funcionamento interno podem não estar completamente familiarizados, os criadores criaram uma cadeia de fornecimento de componentes tão complexa como os utilizados pelos fabricantes físicos. E porque uma aplicação é apenas tão segura como o seu componente menos seguro, o software criado desta forma tem vulnerabilidades únicas com as quais a indústria está a lutar.
Os últimos anos têm sido marcados por uma série de ataques à cadeia de fornecimento de software. Por exemplo, no final de 2020, os cibercriminosos afiliados aos serviços secretos russos conseguiram colocar backdoors numa plataforma de monitorização da rede SolarWinds, uma solução que também é utilizada por outros produtos de segurança. E, no final de 2021, foi descoberta uma grave vulnerabilidade no Apache Log4j, uma biblioteca Java utilizada para registar eventos do sistema.
Estas crises de segurança ilustram o papel que um SBOM pode desempenhar na paisagem de hoje. Com a versão certa, sabe exatamente que pacotes foram implantados e, mais especificamente, que versão, permitindo-lhe atualizar conforme necessário para se manter seguro.
Ordem executiva da lista técnica do software
O ataque ao SolarWinds, em particular, suscitou alarmes no governo dos EUA, uma vez que muitas das suas agências federais tinham implementado a componente comprometida. É por isso que uma importante ordem executiva de cibersegurança emitida em maio incluía diretivas sobre o SBOM. Efetivamente, o Departamento de Comércio foi encarregado de publicar uma linha de base de elementos mínimos para SBOMs, que se tornaria então num requisito para qualquer vendedor que vendesse ao governo federal.
Embora a ordem se aplique especificamente àqueles que têm relações diretas com os federais, a natureza expansiva dos EUA e as muitas empresas que querem trabalhar com o sector público terão efeitos colaterais também no sector privado, pelo que os SBOM serão democratizados como um elemento de valor acrescentado.
O que deve ser incluído num SBOM?
Em resposta à ordem executiva, em julho de 2021, a Administração Nacional de Telecomunicações e Informação (NTIA) publicou os requisitos mínimos para uma lista de materiais de software. Estes incluem sete campos que qualquer SBOM deve ter, tais como nome do fornecedor, nome do componente, versão do componente, outros identificadores únicos, relação de dependência, autor de dados SBOM e carimbo da hora, ou seja, registo da data e hora do conjunto de dados SBOM.
Além disso, o SBOM deve estar num dos três formatos normalizados (SPDX, CycloneDX ou SWD), deve ser gerado um novo com cada nova versão do software e explicar onde é provável que tais reações existam, mas são desconhecidas para a organização produtora do SBOM.
Como gerar um SBOM
Na maioria dos casos, os SBOMs são gerados automaticamente utilizando ferramentas de análise de composição de software (SCA). As ferramentas SCA são frequentemente utilizadas dentro de gasodutos DevSecOps e têm frequentemente funções para além da criação de SBOM.
As ferramentas SCA verificam os diretórios de códigos em busca de pacotes e comparam-nos com bases de dados em linha para comparação com bibliotecas conhecidas. Existem também alternativas a isto, por exemplo, existem algumas ferramentas que simplesmente criarão um SBOM como parte do processo de criação de software.