SBOM: informações sobre componentes, formatos e manutenção
Sytance · Atualizado
Uma lista de materiais de software (SBOM) descreve os componentes de software que constituem uma aplicação ou sistema e as relações entre eles. Dá à equipa um ponto de partida para inventariar componentes, rever licenças e investigar vulnerabilidades. O seu valor depende da precisão com que descreve o software efetivamente fornecido.
O produto descrito por uma SBOM
Uma SBOM descreve uma versão específica de um produto, uma compilação ou um artefacto, como uma imagem de firmware ou um pacote de instalação. As entradas de componentes identificam as bibliotecas e outros elementos de software incluídos nesse âmbito. As respetivas versões, produtores, identificadores e relações ajudam a explicar o que foi incluído.
No exemplo fictício de um gateway industrial, o produto de destino é a versão de firmware. A aplicação de gestão e as bibliotecas incorporadas são componentes. Um serviço remoto de telemetria é uma dependência externa; descrevê-lo não significa que os pacotes do lado do servidor estejam incluídos no firmware.
O exemplo público utiliza componentes inventados para tornar a estrutura legível. Não é um inventário de componentes do Sytance nem de um gateway comercializado.
Identificadores de componentes
Dois pacotes com nomes semelhantes podem pertencer a ecossistemas de pacotes diferentes. O Package URL (purl) identifica um pacote através de campos como tipo, espaço de nomes, nome e versão. Um hash de ficheiro ajuda a identificar um ficheiro exato quando se conhece o algoritmo de hash e o ficheiro que foi sujeito a hash.
Utilize os metadados do pacote ou as informações do fornecedor para estabelecer os identificadores. Um purl construído com base num fornecedor presumido pode apontar para o pacote errado. Preserve a cadeia da versão original, pois uma compilação a jusante pode incluir a sua própria revisão de patches.
O SPDX e o CycloneDX representam ambos informações sobre componentes de software e as respetivas relações. Os campos disponíveis e o significado exato dependem da versão do formato. Escolha uma versão que as ferramentas de produção e receção consigam processar.
Precisão e cobertura do inventário
Um ficheiro pode ser JSON válido e, ainda assim, descrever a versão errada. Compare a SBOM com as entradas da compilação e o artefacto fornecido e, em seguida, investigue as discrepâncias. Uma lista de dependências do código-fonte pode incluir ferramentas de desenvolvimento que nunca foram fornecidas e omitir bibliotecas copiadas para a imagem.
- Alvo: o produto, a versão e o artefacto correspondem à versão fornecida.
- Identidade: é possível rastrear as versões e os identificadores dos componentes até às evidências.
- Relações: os percursos de dependência estão presentes e são significativos.
- Cobertura: os dados em falta dos fornecedores e as partes não analisadas são visíveis.
- Intercâmbio: a ferramenta recetora preserva os campos necessários para a utilização prevista.
Elementos mínimos da SBOM de 2026
A publicação conjunta 2026 SBOM Minimum Elements, da CISA e de agências parceiras, atualiza as orientações da NTIA de 2021. Aborda os metadados do documento, os dados dos componentes e as práticas de manutenção e partilha de SBOM. A publicação constitui uma orientação e declara que não cria novos requisitos.
Para uma entrega, indique a especificação, a versão do formato e os requisitos adicionais do cliente acordados. Um resultado de validação do esquema, por si só, não demonstra que estão completas as informações solicitadas pelo cliente.
Correspondências de vulnerabilidades e impacto no produto
Uma correspondência de vulnerabilidade relaciona um problema notificado com a identidade ou a versão de um componente. A pergunta seguinte é se o código afetado está presente e pode ser explorado neste produto. Verifique as opções de compilação, as modificações, os percursos de execução e as condições descritas no aviso.
Vulnerability Exploitability eXchange (VEX) comunica uma avaliação de uma vulnerabilidade específica para produtos identificados. Mantenha essa avaliação ligada à versão e à análise que a sustenta. A ausência de correspondências pode refletir uma cobertura limitada ou identificadores incompletos.
Registos das versões suportadas
Arquive o inventário original com a versão comercializada. Se novas informações corrigirem a SBOM sem alterar o software, emita uma revisão documental rastreável. Se o software mudar, crie um registo para a nova versão.
Quando um novo aviso identificar uma vulnerabilidade num componente, pesquise nos inventários de todas as versões suportadas. Os clientes podem ainda estar a utilizar uma versão anterior cujos componentes diferem dos do produto atual.