Comparar
Conformidade com o CRA: requisitos de SBOM e ferramentas
O Cyber Resilience Act torna obrigatória uma lista de materiais de software para produtos com elementos digitais. Veja o que o regulamento exige dela, o que acrescenta a diretriz alemã do BSI e como se comparam as ferramentas de conformidade com o CRA.
Atualizado a
Cada comparação indica o que o outro produto faz bem, em que o CRACI é diferente e quando faria sentido usar ambos. Para todas as categorias, consulte todas as comparações.
O que o CRA exige de uma SBOM
O Cyber Resilience Act, Regulamento (UE) 2024/2847, coloca a SBOM nos seus requisitos de tratamento de vulnerabilidades. Exige menos do que muitos supõem: um registo legível por máquina que inclua, pelo menos, as dependências de nível superior, mantido na documentação técnica e apresentado a uma autoridade quando solicitado. Eis o que diz o regulamento, pergunta a pergunta.
| Funcionalidade | O que diz o CRA | Onde |
|---|---|---|
| Uma SBOM é obrigatória? | Sim. Os fabricantes têm de identificar e documentar os componentes dos seus produtos, nomeadamente elaborando uma lista de materiais de software | Anexo I, parte II, ponto 1 |
| O que é uma SBOM? | Um registo formal com os detalhes e as relações na cadeia de abastecimento dos componentes incluídos nos elementos de software de um produto com elementos digitais | Artigo 3.º, ponto 39 |
| Que formato? | "Um formato de uso corrente e legível por máquina". A Comissão pode especificar o formato e os elementos através de atos de execução | Anexo I, parte II, ponto 1; artigo 13.º, n.º 24 |
| Até que profundidade? | "No mínimo, as dependências de nível superior dos produtos" | Anexo I, parte II, ponto 1 |
| Onde fica? | Na documentação técnica, como parte das informações sobre o tratamento de vulnerabilidades | Anexo VII, ponto 2, alínea b) |
| Tem de ser pública? | Não. Os fabricantes não deverão ser obrigados a tornar pública a SBOM. Se a partilhar com os utilizadores, as informações para o utilizador indicam onde a encontrar | Considerando 77; Anexo II, ponto 9 |
| Quem a pode pedir? | Uma autoridade de fiscalização do mercado, mediante pedido fundamentado, para verificar a conformidade. As autoridades podem também solicitar SBOM para uma avaliação de dependências à escala da UE | Anexo VII, ponto 8; artigo 13.º, n.º 25 |
| Durante quanto tempo se conserva? | A documentação técnica é conservada durante, pelo menos, 10 anos após a colocação do produto no mercado, ou durante o período de suporte, consoante o que for mais longo | Artigo 13.º, n.º 13 |
O regulamento aplica-se na íntegra a partir de 11 de dezembro de 2027, e as suas obrigações de reporte aplicam-se a partir de 11 de setembro de 2026. Para o resto do regulamento, consulte o que o CRA exige.
Para além do mínimo: BSI TR-03183-2
Até a Comissão especificar o formato através de um ato de execução, as orientações públicas mais detalhadas vêm do Serviço Federal Alemão para a Segurança da Informação (BSI). A sua diretriz técnica TR-03183-2, versão 2.1.0 de agosto de 2025, é uma orientação e não faz parte do regulamento, mas mostra para onde caminham as expectativas:
- Formato: JSON ou XML, válido segundo CycloneDX 1.6 ou superior, ou SPDX 3.0.1 ou superior.
- Profundidade: resolução recursiva das dependências de cada componente no âmbito de fornecimento, até ao primeiro componente fora dele, inclusive.
- Fonte da verdade: a SBOM tem de conter "a mesma informação disponível durante o processo de build", ou informação equivalente quando não existe processo de build.
A diretriz designa também os tipos de SBOM. Uma SBOM de build "é criada como parte do processo de build". Uma SBOM analisada "é criada após o processo de build, através da análise de artefactos como executáveis, pacotes, contentores e imagens de máquinas virtuais". Essa distinção é a principal diferença entre as ferramentas desta página.
Dependências de nível superior ou transitivas
As dependências de nível superior são o mínimo, não o objetivo. Uma vulnerabilidade num pacote transitivo continua a estar no seu produto, e o CRA exige que os fabricantes tratem e corrijam as vulnerabilidades dos componentes que distribuem. Uma SBOM que para no primeiro nível deixa esses pacotes de fora do seu tratamento de vulnerabilidades. A questão prática não é se deve registar as dependências transitivas, mas como ter a certeza de que o registo corresponde ao que foi distribuído. Consulte dependências transitivas para saber como as listar e corrigir as que são vulneráveis.
SBOM de build ou SBOM analisada
A maioria das ferramentas de SBOM gera uma SBOM analisada depois do build, ou gere SBOM produzidas por outras ferramentas. O CRACI regista uma SBOM de build enquanto o build é executado. Para uma comparação de geradores e gestores de SBOM, consulte gestão de SBOM e ferramentas de SBOM comparadas. Para ferramentas criadas em torno do CRA, consulte ferramentas de conformidade com o CRA comparadas.
Onde o CRACI se enquadra
O CRACI regista a SBOM enquanto o seu build de GitHub Actions é executado. Um proxy que reconhece pacotes no runner regista cada pacote que o job obteve, incluindo pacotes restaurados de caches de CI, pelo que a SBOM descreve o build que produziu o artefacto e não uma análise executada algures ali ao lado. A SBOM de cada job tem um estado de completude, e as exportações em CycloneDX e SPDX incluem as dependências transitivas e a licença declarada de cada componente.
Após o lançamento, o CRACI continua a reavaliar as SBOM monitorizadas à medida que surgem novas vulnerabilidades e submete as notificações do CRA (alerta precoce, notificação e relatório final) em seu nome. A API devolve SBOM, traços de rede e proveniência. O CRACI conserva os dados de build durante 180 dias por defeito, com retenção personalizada no plano Enterprise, pelo que deve exportar o que pertence à documentação técnica que conserva durante 10 anos. O CRACI automatiza uma parte significativa da visibilidade da cadeia de abastecimento e das evidências de que o seu processo do CRA precisa; a avaliação da conformidade e a documentação técnica continuam a ser responsabilidade do fabricante. Para todos os requisitos do CRA como um roteiro passo a passo, consulte o guia do CRA. Saiba mais sobre a geração de SBOM durante o build, ou marque uma demo para ver uma SBOM registada a partir de um dos seus builds.
O CRACI comparado com cada ferramenta
- CRACI face a Cybeats Um sistema de registo de SBOM face a SBOM registadas e monitorizadas.
- CRACI face a FOSSA Gestão de SBOM face a build, SBOM e monitorização num só produto.
- CRACI face a Anchore Análise de imagens face a registo e monitorização de builds.
- CRACI face a Black Duck Análise de código, snippets e binários face a evidências do build.
- CRACI face a Sonatype Controlo de repositórios e SCA face a evidências do build.
- CRACI face a ONEKEY Análise binária de firmware face a evidências recolhidas durante o build.
- CRACI face a Finite State Análise de binários e de SBOM de fornecedores face a um registo do build.
- CRACI face a Exein Segurança em runtime no dispositivo face a evidências a partir do build.
Lado a lado
Várias ferramentas numa só página, para quando está a escolher uma categoria e não um produto.
Perguntas frequentes sobre a SBOM do CRA
O CRA exige dependências transitivas na SBOM?
O regulamento fixa o mínimo em "no mínimo, as dependências de nível superior dos produtos" (Anexo I, parte II, ponto 1). As dependências transitivas não são mencionadas, mas um pacote transitivo vulnerável continua a estar no seu produto, e o CRA exige que trate as vulnerabilidades dos componentes que distribui. A diretriz alemã BSI TR-03183-2 vai mais longe e pede a resolução recursiva das dependências.
A SBOM do CRA tem de ser pública?
Não. O considerando 77 refere que os fabricantes não deverão ser obrigados a tornar pública a SBOM. Esta faz parte da documentação técnica, e uma autoridade de fiscalização do mercado pode solicitá-la mediante pedido fundamentado. Se optar por a partilhar com os utilizadores, as informações que acompanham o produto têm de indicar onde a encontrar (Anexo II, ponto 9).
Uma SBOM para o CRA deve ser em CycloneDX ou SPDX?
O CRA pede "um formato de uso corrente e legível por máquina" e não nomeia nenhum; a Comissão pode especificar o formato através de um ato de execução (artigo 13.º, n.º 24). O CycloneDX e o SPDX são as duas opções comuns. A BSI TR-03183-2 v2.1.0 aceita CycloneDX 1.6 ou superior e SPDX 3.0.1 ou superior, em JSON ou XML.
Durante quanto tempo tenho de conservar a SBOM?
A SBOM faz parte da documentação técnica, que os fabricantes mantêm à disposição das autoridades de fiscalização do mercado durante, pelo menos, 10 anos após a colocação do produto no mercado, ou durante o período de suporte, se for mais longo (artigo 13.º, n.º 13).
Quando se aplicam os requisitos de SBOM do CRA?
As obrigações de reporte do CRA aplicam-se a partir de 11 de setembro de 2026, e o regulamento aplica-se na íntegra, incluindo o requisito de SBOM do Anexo I, a partir de 11 de dezembro de 2027.
Outras categorias
Veja o CRACI no seu próprio pipeline
Marque uma demo e analisaremos consigo os seus builds, as suas SBOM e as suas evidências de conformidade.
Marcar demo