Ferramentas de conformidade com o CRA comparadas

A quem se destina esta página

Fabrica um produto com elementos digitais e coloca-o no mercado da UE. O Cyber Resilience Act, Regulamento (UE) 2024/2847, aplica-se-lhe por fases: as obrigações de reporte a partir de 11 de setembro de 2026 e as principais disposições a partir de 11 de dezembro de 2027. Está a escolher ferramentas para as partes técnicas desse trabalho. Somos nós que desenvolvemos o CRACI, por isso tenha isso em conta. Descrevemos cada ferramenta a partir da sua própria documentação e dizemos onde outra ferramenta se adequa melhor.

Há uma regra que atravessa esta página. A conformidade é um processo conduzido pelo fabricante, com avaliação de riscos, documentação e avaliação da conformidade. As ferramentas produzem evidências e automatizam partes do trabalho. Nenhuma das ferramentas abaixo torna um produto conforme por si só.

O que o CRA exige

Para a cadeia de abastecimento de software, cinco requisitos são os que mais pesam.

1. Uma SBOM. Os fabricantes identificam e documentam os componentes do produto, elaborando uma lista de materiais de software "num formato de uso corrente e legível por máquina, que abranja, no mínimo, as dependências de nível superior dos produtos" (Anexo I, parte II). O Anexo VII coloca-a na documentação técnica, que uma autoridade de fiscalização do mercado pode solicitar.
2. Tratamento de vulnerabilidades. Tratar e corrigir as vulnerabilidades sem demora, incluindo através de atualizações de segurança, testar regularmente e manter uma política de divulgação coordenada de vulnerabilidades (Anexo I, parte II).
3. Reporte. Notificar as vulnerabilidades ativamente exploradas e os incidentes graves ao seu CSIRT e à ENISA através da CRA Single Reporting Platform: um alerta precoce no prazo de 24 horas, uma notificação no prazo de 72 horas e um relatório final, o mais tardar, 14 dias após estar disponível uma correção ou mitigação para uma vulnerabilidade, ou no prazo de um mês para um incidente grave (artigo 14.º).
4. Evidências. Documentação técnica, uma avaliação da conformidade e uma declaração UE de conformidade (artigos 28.º, 31.º e 32.º, Anexo VII), mantidas à disposição das autoridades 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.º).
5. Um período de suporte. Um período que reflita o tempo de utilização previsto do produto, de, pelo menos, cinco anos, salvo se a utilização prevista for mais curta, durante o qual as vulnerabilidades são tratadas de forma eficaz (artigo 13.º).

Como escolher

• Em que metade do trabalho precisa de ajuda? As ferramentas técnicas produzem a SBOM, os registos de vulnerabilidades e as evidências de build. As plataformas de gestão da conformidade fazem o mapeamento dos requisitos para controlos, redigem políticas e acompanham o processo. A maioria das ferramentas é forte numa das metades, por isso decida qual é a maior lacuna.
• Compila o software ou integra-o? Se grande parte do produto chega de fabricantes de chips e fornecedores como binários, a análise de binários é a forma de ver lá dentro. Se o compila por si, o build é a fonte de evidências mais direta.
• De onde vem a sua SBOM e como sabe que está completa? Os scanners, as consultas a ferramentas de build e o registo do build podem dar respostas diferentes para a mesma versão.
• Consegue encontrar as versões afetadas em poucas horas? Um alerta precoce em 24 horas depende de um inventário por versão em que confie.
• Precisa de um sistema de registo? Com muitos produtos e fornecedores, a gestão de SBOM com VEX e partilha torna-se uma função em si mesma.

Visão geral

Duas tabelas: primeiro, ferramentas de SBOM, SCA e gestão de SBOM; depois, ferramentas criadas para firmware e dispositivos. As linhas seguem os requisitos acima. "Não indicado" significa que as páginas de fornecedores que citamos não dizem nem que sim nem que não.

SBOM, SCA e gestão de SBOM

Firmware e dispositivos

CRACI

O CRACI é um runner de GitHub Actions. Para o software que compila, regista o que cada job obteve, incluindo pacotes restaurados de caches de CI, e produz uma SBOM CycloneDX ou SPDX com um estado de completude por job e por cache. Continua a reavaliar as SBOM do que foi distribuído, suporta VEX e submete as notificações do CRA em seu nome quando uma vulnerabilidade ativamente explorada tem de ser comunicada. Para Yocto, regista o que a própria saída SPDX do Yocto deixa de fora. Ajuda com: geração de SBOM, tratamento de vulnerabilidades, notificações do CRA, evidências. A ter em conta: não analisa binários que não compilou, não tem mapeamento de controlos nem gestão de políticas, e suporta hoje GitHub Actions (GitLab CI e Jenkins estão no roadmap). Conformidade com o CRA com o CRACI

Gestão de SBOM

Cybeats

O Cybeats SBOM Studio apresenta-se como "o sistema de registo de SBOM." Guarda SBOM dos seus produtos e fornecedores em SPDX 2.2 a 3.0.1 e CycloneDX 1.2 a 1.7, valida-as com um Quality Score antes da importação, cruza cada componente com informação sobre vulnerabilidades, emite VEX e partilha SBOM com clientes, incluindo através da Transparency Exchange API. O seu guia de regulamentos apresenta o calendário do CRA de 24 horas, 72 horas e 14 dias. Ajuda com: gestão de SBOM, tratamento de vulnerabilidades, evidências. A ter em conta: para a geração, remete para fornecedores do seu Marketplace, pelo que a própria SBOM vem de outra ferramenta. CRACI vs Cybeats e alternativas ao Cybeats

FOSSA

O FOSSA começou pela conformidade de licenças e cobre hoje o ciclo de vida da SBOM. Gera SBOM SPDX e CycloneDX, opcionalmente com declarações VDR ou VEX, importa SBOM de fornecedores com políticas para os elementos mínimos da NTIA e da FDA, monitoriza-as face a vulnerabilidades e partilha-as através de um SBOM Portal no plano Enterprise. Em setembro de 2026, tem um plano gratuito, e o Business custa $20 por projeto por mês, faturados anualmente. Ajuda com: SBOM, partilha com autoridades, licenças. A ter em conta: a FOSSA CLI analisa o projeto através da sua ferramenta de build ou faz inferências a partir do código-fonte, em vez de registar o build. CRACI vs FOSSA

Anchore

O Anchore Enterprise assenta nos projetos open source Syft e Grype. Analisa imagens de contentor, sistemas de ficheiros e SBOM importadas, volta a analisar SBOM guardadas sem o artefacto original, aplica pacotes de políticas como FedRAMP e NIST e funciona em alojamento próprio, incluindo air-gapped. O seu material sobre o CRA cobre a gestão de SBOM, a monitorização face a fontes que incluem o CISA KEV, o apoio às janelas de 24 e 72 horas, anotações VEX e trilhos de auditoria. Ajuda com: SBOM, tratamento de vulnerabilidades, evidências. A ter em conta: as SBOM do Anchore descrevem o que um scanner encontra numa imagem ou diretório, não o que o build obteve e deixou para trás. CRACI vs Anchore

Suites de SCA

Black Duck

O Black Duck SCA combina análise de gestores de pacotes, de assinaturas, de snippets e de binários, pelo que encontra open source que ninguém declarou, e a sua KnowledgeBase acompanha mais de 2.750 licenças. O Binary Analysis examina firmware sem código-fonte, o Coverity fornece SAST com uma opção de verificadores alinhados com o CRA anunciada em julho de 2026, e o Defensics faz testes de fuzzing. O Black Duck defende que o CRA precisa de camadas de testes, e não apenas de SCA. Ajuda com: SBOM, tratamento de vulnerabilidades em componentes e no seu próprio código, testes. A ter em conta: o preço é sob orçamento, e todas as técnicas inspecionam o código ou o resultado, não o build. CRACI vs Black Duck

Sonatype

O Sonatype Lifecycle aplica políticas de open source com dados de alcançabilidade e de atualização e abre Golden Pull Requests. O Repository Firewall coloca em quarentena os componentes que não cumprem a política antes de entrarem nos seus repositórios. O SBOM Manager importa, monitoriza e partilha SBOM com um fluxo de trabalho VEX, e a Sonatype posiciona-o como o seu produto para o CRA; o seu guia aponta também o Nexus Repository como site de atualizações de segurança. Ajuda com: tratamento de vulnerabilidades, gestão de SBOM, manter de fora os componentes nocivos. A ter em conta: a oferta está a mudar (os novos clientes compram o Sonatype Guide), e o Lifecycle analisa o que o build produziu e não o que obteve. CRACI vs Sonatype

Firmware e dispositivos

ONEKEY

O ONEKEY analisa firmware compilado "sem necessidade de código-fonte nem de acesso à rede." Gera uma SBOM a partir do binário, importa SBOM de fornecedores, procura prováveis zero-days, como credenciais fixas no código, e volta a analisar o firmware diariamente. O seu Compliance Wizard guia as equipas pelo CRA, pela IEC 62443-4-2, pela ETSI EN 303 645 e pela Radio Equipment Directive. Ajuda com: SBOM para firmware que não compilou, tratamento de vulnerabilidades, verificações guiadas. A ter em conta: trabalha sobre a imagem depois do build, pelo que não regista o que o build obteve. CRACI vs ONEKEY e alternativas ao ONEKEY

Finite State

O Finite State analisa firmware, binários, código-fonte e SBOM de fornecedores, com suporte para mais de 50 arquiteturas de conjuntos de instruções binárias, e reúne-os num único registo de produto. Ordena as conclusões por alcançabilidade e informação sobre exploits, regista decisões VEX, e o seu fluxo de conformidade cobre o mapeamento de controlos do CRA e relatórios prontos para auditoria com artefactos SBOM e VEX. Ajuda com: SBOM entre fornecedores, triagem de vulnerabilidades, evidências. A ter em conta: parte de artefactos, pelo que controlar o que o seu próprio build podia alcançar está fora do seu âmbito. CRACI vs Finite State e alternativas ao Finite State

Exein

O Exein trabalha no dispositivo. O Exein Runtime usa eBPF para monitorizar e bloquear comportamentos maliciosos em Linux embebido, e a camada Yocto open source meta-exein coloca o agente Pulsar do Exein na sua imagem. O Exein Analyzer analisa o firmware antes do lançamento, ou a sua SBOM quando o binário não está disponível, prioriza com pontuação de alcançabilidade e faz o mapeamento das conclusões para os requisitos do CRA. Ajuda com: tratamento de vulnerabilidades no terreno, SBOM de firmware, mapeamento para o CRA. A ter em conta: a camada Yocto muda o que corre no dispositivo; não executa nem regista o seu build. CRACI vs Exein

Plataformas de gestão da conformidade

Estas ferramentas não geram SBOM nem analisam código. Trabalham na metade da governação: fazem o mapeamento dos requisitos do CRA para controlos, redigem políticas e acompanham prazos e aprovações. Precisam de evidências técnicas de outras fontes.

Venvera

O Venvera é uma plataforma de conformidade criada na UE que cobre o CRA a par da NIS2, do DORA, da ISO 27001 e do SOC 2. Para o CRA, acompanha os prazos de reporte de 24 e 72 horas, o tratamento de vulnerabilidades, a SBOM como requisito mantido, o percurso de avaliação da conformidade por classe de produto, e a documentação técnica do Anexo VII e a declaração UE de conformidade. Ajuda com: mapeamento de controlos, prazos de reporte, acompanhamento do processo de conformidade. A ter em conta: acompanha se uma SBOM existe e é mantida; a própria SBOM vem de outra ferramenta.

ZeroRisk

O ZeroRisk é uma plataforma agêntica de conformidade que cobre o RGPD, a ISO 27001, o SOC 2, a NIS2, o DORA e o CRA. Para o CRA, o seu agente faz o mapeamento dos requisitos para a sua organização, pré-preenche uma avaliação de prontidão, redige controlos e políticas em falta e monitoriza os fornecedores presentes nos seus produtos, com nova verificação a cada 24 horas e aprovação humana em cada conclusão. Ajuda com: prontidão, políticas, garantia de fornecedores. A ter em conta: a sua página sobre o CRA não menciona a geração de SBOM nem a monitorização de vulnerabilidades dos seus próprios builds.

Reportar dentro dos prazos

O artigo 14.º atribui a notificação ao fabricante e aplica-se desde 11 de setembro de 2026, incluindo a produtos já no mercado. O que as ferramentas podem fazer é encurtar o tempo entre "esta vulnerabilidade está a ser explorada" e "sabemos que produtos e versões a contêm". Isso depende de inventários por versão em que confie, de monitorização contínua e de uma ligação entre cada artefacto distribuído e os seus componentes. O Anchore e o Cybeats descrevem as janelas de reporte no seu material sobre o CRA, o Venvera acompanha os prazos, e a análise de binários do ONEKEY, do Finite State ou do Exein cobre código de fornecedores que não pode recompilar. A API do CRACI devolve SBOM, traços de rede e proveniência, e o CRACI submete o alerta precoce, a notificação e o relatório final em nome do fabricante.

Como o CRACI se enquadra

O CRACI é um runner de GitHub Actions. Para o software que compila, regista o que cada job obteve, incluindo pacotes restaurados de caches de CI, e produz uma SBOM CycloneDX ou SPDX com um estado de completude por job e por cache. Aplica uma política de egress ao build, continua a reavaliar as SBOM do que foi distribuído, suporta VEX e exporta SBOM em CycloneDX ou SPDX, incluindo vulnerabilidades, para as suas evidências para o CRA. Quando uma vulnerabilidade ativamente explorada tem de ser comunicada, o CRACI submete as notificações do CRA em seu nome. Para Yocto, executa o BitBake em runners de até 32 vCPU e 96 GB de RAM e regista o que a própria saída SPDX do Yocto deixa de fora, como pacotes do host e package URLs de crates Rust. A vista de inventário do CRACI mostra exatamente que versões de software estão implementadas em que produtos, a nível global. O CRACI automatiza uma parte significativa da visibilidade da cadeia de abastecimento de software e das evidências de que as empresas precisam para o seu processo mais amplo de conformidade com o CRA.

Não é suficiente por si só se a maior parte do seu produto vem de fornecedores como binários, ou se precisa de verificações guiadas face a normas, mapeamento de controlos e gestão de políticas, proteção no dispositivo, ou hoje de sistemas de CI que não o GitHub Actions (GitLab CI e Jenkins estão no roadmap). Para os builds que são seus, o CRACI cobre a SBOM, a monitorização e as notificações do CRA num só produto; para firmware que não pode recompilar, a análise de binários vê o que o seu build nunca viu. Consulte o que é o CRA, a conformidade com o CRA e a IoT industrial.

Ferramentas de conformidade com o CRA: perguntas frequentes

O que faz o software de conformidade com o CRA e o que fica a cargo do fabricante

O que é software de conformidade com o CRA?

Software que ajuda um fabricante a cumprir o Cyber Resilience Act. Existe em dois tipos: ferramentas técnicas que produzem a SBOM, os registos de vulnerabilidades e as evidências de build, e plataformas de gestão da conformidade que fazem o mapeamento dos requisitos para controlos e acompanham os prazos de reporte, a avaliação de riscos e a avaliação da conformidade. Nenhum torna um produto conforme por si só.

Que obrigações do CRA pode uma ferramenta automatizar?

Sobretudo o lado do tratamento de vulnerabilidades: gerar a SBOM, monitorizá-la face a novas vulnerabilidades, encontrar as versões afetadas, registar decisões de triagem e VEX, preparar e submeter as notificações do artigo 14.º e exportar evidências para a documentação técnica. A avaliação de riscos, a conceção segura, a avaliação da conformidade e a declaração de conformidade continuam a ser decisões do fabricante.

Preciso de uma ferramenta ou de várias?

Normalmente, de mais do que uma. Uma ferramenta técnica dá-lhe a SBOM e as evidências de vulnerabilidades; uma plataforma de gestão da conformidade ou um consultor cobre os controlos, as políticas e o percurso de conformidade. Para firmware que recebe de fornecedores como binários, a análise de binários acrescenta o que o seu próprio build não consegue ver.

Qual é o prazo para o reporte do CRA?

O artigo 14.º aplica-se desde 11 de setembro de 2026: um alerta precoce no prazo de 24 horas após tomar conhecimento de uma vulnerabilidade ativamente explorada, uma notificação no prazo de 72 horas e um relatório final, o mais tardar, 14 dias após estar disponível uma correção ou mitigação. Abrange produtos já no mercado. O resto do CRA aplica-se a partir de 11 de dezembro de 2027.

O CRACI submete as notificações do CRA?

Sim. O CRACI submete o alerta precoce, a notificação e o relatório final em nome do fabricante. A obrigação de reporte continua a ser do fabricante.

Alguma ferramenta realiza a avaliação da conformidade do CRA?

Nenhuma ferramenta de software a substitui. É o fabricante que realiza a avaliação, por controlo interno ou, para produtos importantes e críticos, com um organismo notificado ou um esquema de certificação quando o CRA o exige. As ferramentas fornecem as evidências que a avaliação utiliza.