Manutenção da SBOM entre versões do produto
Sytance · Atualizado
Uma SBOM tem de se manter ligada à versão de software que descreve. Uma atualização de software pode alterar os componentes, enquanto uma correção da SBOM pode apenas corrigir informações sobre uma versão inalterada. O registo de ambas as versões permite identificar o que os clientes receberam e que inventário o descreve com exatidão.
O software descrito por cada inventário
Escolha um ponto repetível do processo de compilação ou lançamento para gerar a SBOM. Preserve a revisão do código-fonte, as dependências resolvidas, a configuração da compilação e a identidade do artefacto final necessárias para reproduzir ou investigar o inventário.
O guia do CycloneDX distingue inventários gerados a partir do código-fonte, durante uma compilação e em funcionamento. Estas fases podem incluir software diferente. Indicar a fase permite ao destinatário saber se a SBOM descreve dependências declaradas, um resultado da compilação ou software instalado.
Para um gateway, combine informações da compilação da aplicação, da imagem base e dos componentes de firmware fornecidos. Mantenha a relação com a SBOM de cada fornecedor. Um serviço na nuvem utilizado pelo gateway pode necessitar de um inventário separado, com a sua própria cadência de lançamento.
Alterações de componentes entre versões
Uma comparação entre versões mostra que componentes foram adicionados, removidos, atualizados ou recompilados, bem como as alterações aos percursos de dependência. A contagem de componentes, por si só, pode não revelar uma substituição: uma biblioteca pode ser removida e outra adicionada sem alterar o total.
Utilize identidades normalizadas para a comparação e preserve a versão e os identificadores originais. Se uma ferramenta começar a reconhecer pacotes antes desconhecidos, distinga uma melhor visibilidade de uma alteração efetiva do software.
- Componentes adicionados ou removidos e os respetivos percursos de dependência ascendentes.
- Alterações de versão, patches a jusante e hashes de artefactos alterados.
- Alterações às declarações de licença ou aos produtores dos componentes.
- Novas lacunas, identificadores corrigidos e revisões de SBOM dos fornecedores.
Verificações antes do lançamento
Valide o ficheiro segundo a versão do formato e, em seguida, examine o seu significado. Confirme que todas as referências são resolvidas, que o produto raiz corresponde à versão pretendida e que o destinatário consegue aceder a quaisquer SBOM de componentes associadas.
Execute verificações de vulnerabilidades e licenças na versão candidata e registe os resultados para essa versão. Um problema novo de alta prioridade exige uma decisão sobre o tratamento. Uma exceção antiga deve ser revista se tiverem mudado a versão do componente ou os pressupostos operacionais.
Arquive em conjunto o artefacto aceite, a SBOM, as referências da compilação e o resultado da revisão. Se forem utilizadas assinaturas, verifique a assinatura e confirme que pertence ao emissor esperado.
Correções a uma SBOM existente
As orientações conjuntas sobre SBOM de 2026 pedem uma SBOM para cada versão ou atualização de software e uma SBOM revista quando são corrigidos erros ou se conhecem novos detalhes dos componentes. Também distinguem as informações desconhecidas das informações deliberadamente omitidas.
Por exemplo, um fornecedor corrige o produtor de um componente, mantendo-se inalterados os bytes do firmware. Preserve a identidade do firmware, emita uma nova revisão da SBOM, explique a correção e mantenha o documento anterior. Assim, os destinatários conseguem distinguir uma correção de dados de uma atualização de software.
Publique uma atualização através do canal de distribuição acordado. Uma página de destino estável pode indicar a revisão atual, enquanto os ficheiros imutáveis preservam o histórico. Confirme que os destinatários conseguem identificar que revisão substitui uma anterior.
Novas vulnerabilidades em versões suportadas
Quando surge um aviso, pesquise as identidades dos componentes em todas as versões suportadas. Analise as compilações efetivas e a utilização do produto antes de determinar o impacto. Mantenha o inventário de componentes separado da avaliação de vulnerabilidades para poder reavaliar a mesma SBOM à medida que surjam novas informações.
Se a versão 1.0 do gateway incluir uma biblioteca afetada e a versão 1.1 a remover, a nova versão não altera a composição dos dispositivos 1.0 já instalados. A equipa continua a necessitar de uma resposta para esses dispositivos e de um registo exato das versões abrangidas por um aviso ou declaração VEX.
Acorde quem mantém as atualizações dos fornecedores, quem avalia o impacto, quem aprova uma resposta e quem a comunica. Defina o calendário de revisão segundo as obrigações de suporte do produto e a gravidade das novas informações, em vez de depender apenas do próximo lançamento previsto.
Conservação de registos e transição de responsabilidades
No fim do suporte, preserve o mapeamento entre versões e SBOM e as decisões necessárias para explicar fornecimentos anteriores. Restrinja os registos sensíveis quando apropriado, permitindo simultaneamente que os destinatários autorizados obtenham as informações que lhes foram prometidas.
Na transição de responsabilidades, um novo responsável pela manutenção tem de conseguir encontrar o inventário de uma versão do produto, localizar um componente e consultar a avaliação de impacto mais recente. Analisar uma versão suportada ajuda a identificar registos em falta ou permissões de acesso inadequadas.