SBOM no CRA: o ficheiro inicia o processo, não o conclui

O Regulamento Ciber-Resiliência exige que os fabricantes identifiquem e documentem as vulnerabilidades e os componentes dos produtos com elementos digitais, incluindo através da elaboração de uma lista de materiais de software (SBOM) num formato de uso corrente e legível por máquina, que cubra pelo menos as dependências de nível superior.

Gerar o ficheiro não conclui o trabalho. Uma SBOM torna-se operacionalmente útil quando a equipa consegue passar de um componente a uma versão real do produto, a uma vulnerabilidade, à decisão sobre o impacto, à correção e às provas de verificação.

O que o CRA estabelece sobre as SBOM

A parte II do anexo I exige que os fabricantes identifiquem e documentem as vulnerabilidades e os componentes do produto, incluindo através da elaboração de uma SBOM.

O anexo VII liga a SBOM à documentação técnica dos processos de tratamento de vulnerabilidades. Uma autoridade de fiscalização do mercado também pode solicitar a SBOM pertinente quando for necessária para verificar a conformidade com os requisitos essenciais de cibersegurança.

Uma distinção importante: o regulamento não estabelece que todos os fabricantes tenham de publicar a SBOM completa para todos os utilizadores. O anexo II exige informação sobre onde se pode aceder a uma SBOM se o fabricante decidir disponibilizá-la ao utilizador.

O formato do ficheiro é apenas a primeira decisão

CycloneDX e SPDX são formatos de SBOM amplamente utilizados. Escolher um formato não resolve a gestão do ciclo de vida.

Para cada artefacto SBOM, registe, pelo menos:

• produto;
• versão;
• momento da geração;
• ferramenta e processo de geração;
• âmbito da análise;
• versão do formato;
• local de armazenamento;
• identificador ou hash do artefacto;
• estado de validação.

Sem uma ligação à versão, poderá ser impossível determinar posteriormente se um componente foi efetivamente fornecido a um cliente.

O fluxo de trabalho que cria valor

componente → versão do componente → versão do produto → vulnerabilidade → avaliação do impacto → decisão → ação → correção → teste → prova → comunicação

Exemplo:

1. uma ferramenta identifica a biblioteca X na versão 4.8.1;
2. é divulgada uma vulnerabilidade em determinadas versões de X;
3. a equipa confirma se o código afetado está presente e é relevante no produto;
4. são registadas uma avaliação do impacto e uma decisão de prioridade;
5. a correção é ligada a uma alteração concreta e a uma versão do produto;
6. um teste verifica o resultado;
7. as provas de verificação são anexadas ao processo;
8. se os critérios do artigo 14 forem cumpridos, inicia-se o fluxo separado de notificação CRA.

Nem um registo CVE nem a própria SBOM decidem o impacto no produto pela equipa.

SBOM e fornecedores

Um componente pode provir de código-fonte aberto, de um fornecedor comercial ou de outra equipa interna. Por isso, um processo maduro liga a dependência a:

• fornecedor ou origem;
• estado de manutenção;
• fonte de informação sobre vulnerabilidades;
• pessoa responsável pela atualização;
• alternativa de substituição se o componente deixar de ter apoio.

Isso também é relevante para as decisões sobre o período de apoio. O CRA permite aos fabricantes considerar os períodos de apoio dos componentes integrados de terceiros que asseguram funções essenciais.

Não transforme o GRC noutra ferramenta de análise

O Pulsar não deve competir com ferramentas de análise da composição de software, de análise de dependências ou de geração de SBOM. Essas ferramentas identificam e descrevem componentes.

O GRC acrescenta valor quando utiliza o resultado para apoiar decisões controladas:

• associar um artefacto ao produto e à versão;
• ligar risco e ação;
• atribuir responsável e prazo;
• conservar a decisão;
• anexar provas de correção e de teste;
• disponibilizar o histórico durante a revisão.

Utilize o Pulsar para organizar riscos, ações, fornecedores, documentos, provas e relatórios relativos ao tratamento de componentes. Acorde o apoio aos formatos CycloneDX/SPDX no âmbito do seu serviço antes de planear uma importação de SBOM.

Verifique o seu processo atual

• Consegue identificar a SBOM de uma versão concreta?
• A sua geração é reproduzível?
• Cada componente crítico tem um responsável ou uma origem?
• É possível ligar uma vulnerabilidade a uma versão afetada do produto?
• Uma decisão de aceitação de risco tem aprovador e data de revisão?
• A correção tem provas de verificação?
• Existe uma regra clara para passar do tratamento de vulnerabilidades à avaliação da obrigação de notificação CRA?

Veja o Pulsar GRC num fluxo de provas

Orientações relacionadas

• Notificação CRA em 24/72 horas
• Documentação técnica CRA
• Períodos de apoio CRA

Método proposto: seguir um componente até à versão entregue

Imagine um fabricante que recebe um aviso sobre uma biblioteca de compressão. O componente aparece na SBOM de um produto, mas não em todas as variantes. A equipa precisa de saber onde se utiliza, se a condição da vulnerabilidade existe e que versões chegaram aos utilizadores. Este cenário hipotético testa o processo. A SBOM fornece inventário; não responde sozinha a todas essas perguntas.

Identifique componente, versão, fornecedor e referências disponíveis. Verifique se a ferramenta distingue componentes incluídos de ferramentas utilizadas apenas na compilação. Uma coincidência de nome pode ser falsa. Uma ausência pode refletir uma parte não analisada. Por isso conserve âmbito, entradas e limitações do gerador junto do artefacto.

Relacione depois o componente com a entrega através de versão, compilação ou identificador pertinente. Se a composição muda dinamicamente, descreva como se determina o conjunto relevante. A lista no repositório pode diferir do pacote fornecido. O processo deve rever essa diferença em vez de assumir que qualquer ficheiro gerado representa a mesma coisa.

Inventário, aplicabilidade e exploração têm critérios distintos

A SBOM permite localizar componentes. A avaliação de aplicabilidade considera versão, configuração e função. A avaliação de exploração utiliza outros factos e pode ter efeitos de notificação. Mantenha estados separados para evitar que uma correspondência num inventário se transforme automaticamente numa conclusão jurídica.

Registe quem avaliou e com que informação. Uma conclusão «não afetado» precisa de razão verificável: componente não distribuído, versão diferente ou condição técnica comprovada. «Não usamos» sem fonte não permite reconstruir a decisão. Quando faltam dados, preserve o estado pendente e a ação necessária, em vez de fechar o caso por ausência de resposta.

Uma revisão independente pode selecionar uma decisão que exigiu correção e outra que não resultou aplicável. Em ambas, outra pessoa deve compreender fundamento e limites com os artefactos disponíveis. O objetivo é detetar conclusões sem evidência, mantendo um esforço proporcional ao risco do produto.

Geração ligada à publicação

A organização pode propor uma regra de geração e validação para publicações pertinentes. A regra identifica ferramenta, versão, entradas e controlos. Conserve ligação à entrega. Se o ficheiro for gerado novamente mais tarde, distinga original e novo e explique diferenças. Regenerar não prova que a composição entregue anteriormente era idêntica.

Valide formato e utilidade. Um ficheiro tecnicamente válido pode ter versões imprecisas ou omitir componentes de firmware e pacotes fornecidos externamente. A revisão do âmbito precisa de acompanhar alterações na construção e distribuição. Uma validação que verifica apenas sintaxe não deteta todas as lacunas relevantes.

O critério proposto inclui abrir o ficheiro, associá-lo à versão e utilizá-lo numa pesquisa real. Conserve resultado e limitações. Se a geração falhar, a decisão sobre publicação considera risco e requisitos aplicáveis; não deve reduzir-se a ignorar um erro para terminar o pipeline.

Componentes externos e responsabilidade própria

Para um componente fornecido por terceiro, identifique informação necessária e o que efetivamente recebe. A solicitação pode incluir identificação, avisos e condições de manutenção. O fornecedor não elimina responsabilidade de avaliar o produto próprio. Conserve a resposta e a revisão efetuada, incluindo dados em falta.

Se não há inventário suficiente, registe efeito e tratamento. Pode ser preciso análise adicional, alteração de fornecedor ou condição contratual. Não invente componentes para preencher uma tabela. Uma incerteza assumida com ação é mais defensável do que uma lista aparentemente completa sem fonte.

Separe segurança e licenciamento. A licença de um componente não demonstra proteção. A ausência de vulnerabilidade conhecida não resolve todas as condições de distribuição. Os processos podem partilhar inventário, mas precisam de critérios e decisões diferentes.

Partilha externa com versão e propósito claros

Antes de fornecer uma SBOM, verifique destinatário, finalidade e obrigação ou acordo pertinente. Uma solicitação comercial e uma solicitação motivada de autoridade não são equivalentes. O procedimento identifica aprovador, versão, conteúdo e canal adequados. Não transforme a proteção de informação num bloqueio genérico a obrigações aplicáveis.

Conserve o que foi enviado e quando. Para respostas voluntárias, defina política consistente. Se houver dados internos desnecessários, a revisão determina o seu tratamento sem retirar informação exigida. O ficheiro partilhado deve continuar relacionado com o produto solicitado e com a versão aprovada.

Prova de funcionamento do processo

Selecione uma versão distribuída e peça localizar a sua SBOM. Escolha depois um componente e reconstrua avaliação, decisão e correção quando exista. Verifique se o ensaio corresponde ao artefacto corrigido. Se é possível fechar o caso usando inventário de outra versão, falta um controlo de rastreabilidade.

Uma ausência de componente também necessita de verificação

Se um aviso não encontra correspondência, verifique cobertura antes de concluir que o produto não é afetado. O componente pode estar incorporado num pacote externo ou ter identificador diferente. Utilize fontes de construção e fornecedor pertinentes. Registe limite do inventário e a pesquisa realizada. Ausência num ficheiro incompleto não equivale a ausência no produto.

O exercício pode incluir uma dependência conhecida para confirmar que o processo a encontra. Se falha, atribua correção de alcance ou identificação. Não altere silenciosamente o inventário para que o ensaio pareça bem sucedido. Preserve resultado e nova verificação. Isso permite mostrar como se corrigiu uma limitação.

Uma ferramenta diferente pode gerar mais informação, sem provar automaticamente precisão. Compare resultado com artefacto e necessidades de avaliação. A organização escolhe método e revê mudanças. A prova deve corresponder ao produto fornecido, não apenas ao formato preferido por quem construiu o pipeline.

O Pulsar conserva relações, ações e evidências fornecidas. Geração e análise técnica continuam nas ferramentas do fabricante. A IA pode resumir avaliação, mas uma pessoa confirma identificadores e fundamento. A capacidade útil é chegar de um componente a decisões sobre um produto real, não apenas aumentar o número de ficheiros armazenados.

Fontes

• Regulamento (UE) 2024/2847 — anexos I, II e VII
• ENISA — estado da adoção de SBOM em 2026

Fontes verificadas: 12 de setembro de 2026.

• Pulsar GRC — acesso, isolamento de dados e exportação (polaco)