O que o regulamento pede
Anexo I, parte II, ponto 1, do Regulamento (UE) 2024/2847: os fabricantes devem “identificar e documentar vulnerabilidades e componentes existentes nos produtos com elementos digitais, nomeadamente elaborando uma lista de materiais do software num formato de uso corrente e legível por máquina que abranja, pelo menos, as dependências de nível superior dos produtos”. Isto aplica-se a partir de 11 de dezembro de 2027 (artigo 71.º).
- O SBOM faz parte da documentação técnica, com os processos de tratamento de vulnerabilidades (anexo VII, ponto 2, alínea b)).
- Você o entrega a uma autoridade de fiscalização do mercado mediante pedido fundamentado (anexo VII, ponto 8). Não tem de o tornar público (considerando 77).
- Se decidir disponibilizá-lo aos usuários, as informações ao usuário dizem onde (anexo II, ponto 9).
- A Comissão pode fixar o seu formato e elementos por um ato de execução (artigo 13.º, n.º 24). CycloneDX e SPDX são formatos de uso corrente.
O que esta página escreve
Um arquivo JSON CycloneDX 1.6 com o seu produto como componente principal, cada pacote com a sua versão exata e package URL (purl), e as dependências de nível superior do produto quando o arquivo de bloqueio diz quais são. Lê:
- npm package-lock.json (lockfileVersion 2 ou 3), Yarn yarn.lock (Yarn 1, 2 e posteriores) e pnpm-lock.yaml (lockfileVersion 9.0); os pacotes só de desenvolvimento ficam de fora quando o arquivo diz quais são;
- Python requirements.txt com cada pacote fixado (name==version), como o pip freeze ou o pip-compile o escrevem;
- Rust Cargo.lock, versão 3 ou 4, e Go go.mod, com os módulos indiretos;
- a árvore de dependências Maven escrita por mvn dependency:tree -DoutputFile, e o gradle.lockfile do Gradle; os pacotes de escopo de teste ficam de fora;
- PHP Composer composer.lock, sem packages-dev, e NuGet packages.lock.json.
Um arquivo que não segue o seu formato não é lido, com a linha e o motivo, em vez de ser adivinhado. Um pacote de uma origem que não é o registro público é listado sem package URL, para que o arquivo nunca aponte para um pacote que você não usou.
Já tem um SBOM de outra ferramenta? Abra-o como arquivo JSON CycloneDX, ou como arquivo JSON SPDX como o que o gráfico de dependências do GitHub exporta (Export SBOM), para verificar os seus componentes no OSV.dev e no catálogo KEV. É lido só para a verificação: para fazer um novo SBOM, abra os arquivos de bloqueio. Quando nenhum arquivo de bloqueio fixa uma versão, o arquivo do GitHub dá um intervalo como ^4.17.0: esses componentes são listados como não verificados, por isso abra o arquivo de bloqueio para verificá-los.
Vulnerabilidades exploradas conhecidas
A verificação marca cada vulnerabilidade encontrada no OSV.dev cujo número CVE está no catálogo Known Exploited Vulnerabilities (KEV) da Cybersecurity and Infrastructure Security Agency (CISA) dos EUA, com a data em que a CISA a acrescentou. A CISA lista uma vulnerabilidade quando há provas confiáveis de que foi explorada. Desde 11 de setembro de 2026, o artigo 14.º do CRA pede que notifique uma vulnerabilidade ativamente explorada contida no seu produto (artigo 3.º, ponto 42) no prazo de 24 horas após tomar conhecimento dela. Uma entrada no KEV não decide isso para o seu produto, mas é onde olhar primeiro; a página prazos de notificação conta as horas.
O que não cobre
O SBOM lista o que os arquivos de bloqueio listam. Código que copiou para o produto, pacotes do sistema operacional, firmware e bibliotecas noutras linguagens não estão neles: acrescente-os você mesmo ao arquivo. A verificação de vulnerabilidades usa o OSV.dev, que lista só vulnerabilidades publicadas; não substitui a avaliação de vulnerabilidades que o anexo I, parte II, pede.
Para os restantes arquivos do CRA, o kit de documentos CRA escreve a documentação técnica e a declaração de conformidade UE. A verificação CRA diz a classe do seu produto.