CRACI vs ONEKEY

A resposta curta

O ONEKEY é uma plataforma de cibersegurança e conformidade de produto para dispositivos ligados. Basta carregar uma imagem de firmware, e a plataforma analisa o binário para encontrar componentes, vulnerabilidades conhecidas, prováveis zero-days e lacunas de conformidade, sem precisar de código-fonte. O CRACI é um runner de GitHub Actions que regista o que cada build traz durante a execução e produz a SBOM a partir desse registo. O ONEKEY analisa o resultado; o CRACI guarda evidências do build. Complementam-se bem, e nenhum substitui o outro.

Visão geral

O que o ONEKEY faz bem

Análise de binários sem código-fonte. O ONEKEY analisa diretamente o firmware compilado. O seu site di-lo sem rodeios: "No source code or network access needed." Isto importa quando grande parte do que é distribuído num dispositivo vem de fabricantes de chips, fornecedores de módulos e subcontratados, e nunca vê os respetivos builds.

Conclusões para além de CVE conhecidos. Além de cruzar componentes com dados de vulnerabilidades, o ONEKEY executa uma análise automatizada de zero-days que procura no binário problemas como injeção de comandos, comunicação insegura e credenciais incorporadas no código.

SBOM a partir da imagem. O ONEKEY gera uma SBOM a partir do binário, permite importar SBOM de scanners de código-fonte ou de fornecedores e exporta CycloneDX e SPDX.

Orientação de conformidade. O ONEKEY Compliance Wizard guia as equipas pelos requisitos do Cyber Resilience Act, da IEC 62443-4-2, da ETSI EN 303 645 e da Radio Equipment Directive, e exporta os resultados para certificação por terceiros.

Monitorização e CI. A sua monitorização de firmware reanalisa diariamente o firmware carregado à medida que surgem novas vulnerabilidades. A documentação do ONEKEY mostra como carregar cada novo build a partir de GitHub, GitLab ou Jenkins e fazer falhar o pipeline quando surgem novas conclusões. O ONEKEY mantém também o unblob, um conjunto open source de extração de blobs binários.

Onde o CRACI é diferente

Uma análise de binários trabalha para trás, a partir da imagem final. O CRACI trabalha para a frente, a partir do build, porque é a máquina onde o build corre.

O build é a fonte da verdade

O seu workflow de firmware corre nos runners do CRACI com uma alteração de uma linha em runs-on. Enquanto um job corre, um proxy que reconhece pacotes regista o que ele transfere de origens de pacotes, e os pacotes restaurados de caches de CI continuam a constar do registo. Cada SBOM indica quão completa é, por job e por cache: Complete, Complete with connections, Incomplete, Unavailable ou Not recorded. Para Yocto, o CRACI executa BitBake em runners de até 32 vCPU e 96 GB de RAM. Num build lado a lado de core-image-sato, a SBOM do CRACI tinha todos os componentes do próprio resultado SPDX do Yocto, mais 88, como pacotes do host e GitHub Actions, e um URL de pacote para cada uma das 653 versões de crates Rust que o Yocto lista sem ele. As fontes que o BitBake obtém do mirror de código-fonte do Yocto são registadas na SBOM do job no CRACI.

Controlo sobre o que o build pode alcançar

Uma política de egress no runner decide a que hosts um job se pode ligar. É validada antes de o job arrancar, falha em modo fechado e envia um alerta em caso de violação. Para Yocto, acrescenta uma segunda camada ao próprio BB_ALLOWED_NETWORKS do BitBake.

Proveniência e o que foi distribuído

A API devolve SBOM, traços de rede e proveniência. O CRACI não assina a proveniência. Agrega vulnerabilidades de todos os builds e repositórios e continua a reavaliar as SBOM monitorizadas à medida que surgem avisos de segurança.

O que o CRACI não faz importa aqui tanto como o que faz. Não analisa binários, pelo que não lhe pode dizer o que está dentro de um blob de fornecedor que o seu build transfere; apenas que o build o obteve e de onde.

Um inventário do que está implementado e onde

A vista de inventário do CRACI mostra exatamente que versões de software estão implementadas em que produtos, a nível global. Quando surge uma nova vulnerabilidade, pode ver que produtos executam a versão afetada, em vez de o reconstituir a partir de notas de lançamento e folhas de cálculo.

Quando usar cada um e quando usar ambos

• Integra firmware que não constrói. ONEKEY. A análise de binários é a forma de ver lá dentro.
• Constrói a sua própria imagem Linux em GitHub Actions. O CRACI executa o build e regista as suas entradas. Acrescentar o ONEKEY dá-lhe uma segunda visão, independente, da imagem final.
• Um auditor pergunta como sabe que a SBOM corresponde ao produto. O registo do runner do CRACI responde ao que entrou neste build; a análise do ONEKEY responde ao que está nesta imagem. Em conjunto, verificam-se mutuamente.
• Precisa de verificações guiadas face à IEC 62443 ou à ETSI EN 303 645. O ONEKEY tem isso integrado. O CRACI exporta SBOM em CycloneDX ou SPDX, e a sua API devolve traços de rede e proveniência, para o seu processo mais amplo.

Para o CRA

O Cyber Resilience Act pede aos fabricantes que identifiquem e documentem os componentes dos seus produtos, incluindo uma SBOM, e que tratem as vulnerabilidades enquanto o produto tiver suporte. O reporte de vulnerabilidades ativamente exploradas aplica-se a partir de setembro de 2026. O ONEKEY ajuda ao analisar o firmware que a sua empresa coloca no mercado e ao guiá-la pelos requisitos. O CRACI ajuda ao produzir evidências por build do que entrou nesse firmware, com proveniência e monitorização contínua. O CRACI automatiza uma parte significativa da visibilidade da cadeia de abastecimento de software e das evidências de que os fabricantes precisam para o seu processo mais amplo de conformidade com o CRA; não torna um produto conforme por si só. Leia o que exige o CRA.

Adicionar o CRACI ao lado do ONEKEY

Mantenha o seu passo de carregamento para o ONEKEY. Mova o job de firmware para um runner do CRACI definindo runs-on: craci, e o mesmo workflow continua a correr em GitHub Actions enquanto o CRACI regista o build. O carregamento para o ONEKEY passa então a ser feito a partir de um build de que tem evidências. O exemplo de Yocto na documentação do CRACI mostra um workflow BitBake completo. O CRACI suporta hoje apenas GitHub Actions, pelo que os pipelines de GitLab ou Jenkins teriam de ser migrados para usar runners do CRACI. O GitLab CI e o Jenkins estão no roadmap. Veja como o CRACI funciona para IoT industrial e eletrónica de consumo.

A ponderar mais do que duas ferramentas? Alternativas ao ONEKEY compara nove opções lado a lado.