Confronto
CRACI vs ONEKEY
ONEKEY esamina il firmware che Lei distribuisce. CRACI esamina la build che lo ha prodotto. Per la maggior parte dei produttori di dispositivi i due rispondono a domande diverse, ed entrambe le domande si pongono con il Cyber Resilience Act.
Aggiornato il
La risposta breve
ONEKEY è una piattaforma di cybersecurity e conformità di prodotto per dispositivi connessi. Lei carica un'immagine firmware e la piattaforma analizza il binario per individuare componenti, vulnerabilità note, probabili zero-day e lacune di conformità, senza bisogno del codice sorgente. CRACI è un runner GitHub Actions che registra ciò che ogni build scarica durante l'esecuzione e produce la SBOM da quel record. ONEKEY analizza l'output; CRACI conserva le evidenze della build. Si integrano bene e nessuno dei due sostituisce l'altro.
In sintesi
| Funzionalità | CRACI | ONEKEY |
|---|---|---|
| Registra ciò che la build firmware ha scaricato | Osservato dal runner durante ogni job | Analizza l'immagine dopo la build |
| Esegue le Sue build CI | I job girano sui runner CRACI | La Sua CI carica il firmware su ONEKEY |
| Analizza l'immagine binaria finita | Analisi automatizzata del firmware binario | |
| Funziona su firmware che Lei non ha compilato | La build deve girare su CRACI | Non servono codice sorgente né accesso alla rete |
| Analisi zero-day dei binari | Trova problemi come credenziali hardcoded | |
| SBOM in CycloneDX e SPDX | Dalla build, con uno stato di completezza | Dal binario, più importazione di SBOM |
| Policy di egress durante la build | Verificata prima del job, fail closed | Fuori dal suo ambito |
| Monitoraggio dopo la release | Rivaluta di continuo le SBOM monitorate | Rianalizza il firmware ogni giorno |
| Verifiche guidate rispetto agli standard | Esportazione SBOM e API, nessuna esportazione di report né wizard per gli standard | Compliance Wizard per CRA, IEC 62443 e altri |
| Sistemi CI | Oggi GitHub Actions; GitLab CI e Jenkins in roadmap | Esempi documentati per GitHub, GitLab e Jenkins |
- Incluso
- In parte
- Non incluso
Che cosa fa bene ONEKEY
Analisi dei binari senza codice sorgente. ONEKEY analizza direttamente il firmware compilato. Il suo sito lo dice chiaramente: "No source code or network access needed." Questo conta quando gran parte di ciò che viene distribuito su un dispositivo proviene da produttori di chip, fornitori di moduli e terzisti, e Lei non vede mai la loro build.
Risultati oltre le CVE note. Oltre a confrontare i componenti con i dati sulle vulnerabilità, ONEKEY esegue un'analisi zero-day automatizzata che cerca nel binario problemi come command injection, comunicazioni non sicure e credenziali hardcoded.
SBOM dall'immagine. ONEKEY genera una SBOM dal binario, consente di importare SBOM da scanner del sorgente o da fornitori ed esporta CycloneDX e SPDX.
Guida alla conformità. Il Compliance Wizard di ONEKEY accompagna i team attraverso i requisiti del Cyber Resilience Act, di IEC 62443-4-2, ETSI EN 303 645 e della Radio Equipment Directive, ed esporta i risultati per la certificazione di terze parti.
Monitoraggio e CI. Il monitoraggio del firmware rianalizza ogni giorno il firmware caricato man mano che compaiono nuove vulnerabilità. La documentazione di ONEKEY mostra come caricare ogni nuova build da GitHub, GitLab o Jenkins e far fallire la pipeline quando emergono nuovi risultati. ONEKEY mantiene anche unblob, una suite open source di estrazione per blob binari.
In che cosa CRACI è diverso
Una scansione dei binari lavora a ritroso dall'immagine finita. CRACI parte dalla build e procede in avanti, perché è la macchina su cui gira la build.
La build è la fonte di verità
Il Suo workflow firmware gira sui runner CRACI con la modifica di una sola riga in runs-on. Durante l'esecuzione di un job, un proxy che riconosce i pacchetti registra ciò che viene scaricato dalle sorgenti dei pacchetti, e i pacchetti ripristinati dalle cache CI vengono riportati nel record. Ogni SBOM dichiara quanto è completa, per job e per cache: Complete, Complete with connections, Incomplete, Unavailable o Not recorded. Per Yocto, CRACI esegue BitBake su runner fino a 32 vCPU e 96 GB di RAM. In una build affiancata di core-image-sato, la SBOM di CRACI conteneva ogni componente dell'output SPDX di Yocto, altri 88 come pacchetti host e GitHub Actions, e un package URL per ciascuna delle 653 versioni di crate Rust che Yocto elenca senza indicarlo. I sorgenti che BitBake scarica dal mirror dei sorgenti Yocto vengono registrati nella SBOM del job CRACI.
Controllo su ciò che la build può raggiungere
Una policy di egress sul runner decide a quali host un job può connettersi. Viene convalidata prima dell'avvio del job, opera in modalità fail closed e invia un avviso in caso di violazione. Per Yocto aggiunge un secondo livello a BB_ALLOWED_NETWORKS di BitBake.
Provenance e ciò che è stato distribuito
L'API restituisce SBOM, tracce di rete e provenance. CRACI non firma la provenance. Aggrega le vulnerabilità tra build e repository e continua a rivalutare le SBOM monitorate man mano che compaiono nuovi advisory.
Qui conta altrettanto ciò che CRACI non fa. Non analizza i binari, quindi non può dirLe che cosa c'è all'interno di un blob di un fornitore scaricato dalla Sua build: vede solo che la build lo ha scaricato e da dove.
Un inventario di che cosa è distribuito e dove
La vista inventario di CRACI mostra esattamente quali versioni del software sono distribuite in quali prodotti, a livello globale. Quando arriva una nuova vulnerabilità, può vedere quali prodotti eseguono la versione interessata invece di ricostruirlo da note di rilascio e fogli di calcolo.
Quando usare l'uno, l'altro o entrambi
- Integra firmware che non compila. ONEKEY. L'analisi dei binari è il modo per vedervi all'interno.
- Compila la Sua immagine Linux in GitHub Actions. CRACI esegue la build e ne registra gli input. Aggiungere ONEKEY Le offre una seconda vista indipendente dell'immagine finita.
- Un auditor chiede come fa a sapere che la SBOM corrisponde al prodotto. Il record del runner di CRACI risponde a "che cosa è entrato in questa build"; l'analisi di ONEKEY risponde a "che cosa c'è in questa immagine". Insieme si verificano a vicenda.
- Le servono verifiche guidate rispetto a IEC 62443 o ETSI EN 303 645. ONEKEY le ha integrate. CRACI esporta le SBOM in CycloneDX o SPDX, e la sua API restituisce tracce di rete e provenance, per il Suo processo più ampio.
Per il CRA
Il Cyber Resilience Act chiede ai fabbricanti di identificare e documentare i componenti dei loro prodotti, compresa una SBOM, e di gestire le vulnerabilità per tutto il periodo in cui il prodotto è supportato. La segnalazione delle vulnerabilità attivamente sfruttate si applica da settembre 2026. ONEKEY aiuta analizzando il firmware che Lei immette sul mercato e guidandoLa attraverso i requisiti. CRACI aiuta producendo evidenze per build di ciò che è entrato in quel firmware, con provenance e monitoraggio continuo. CRACI automatizza una parte significativa della visibilità e delle evidenze sulla software supply chain di cui i fabbricanti hanno bisogno nel loro più ampio processo di conformità al CRA; da solo non rende conforme un prodotto. Legga che cosa richiede il CRA.
Aggiungere CRACI accanto a ONEKEY
Mantenga lo step di caricamento su ONEKEY. Sposti il job firmware su un runner CRACI impostando runs-on: craci: lo stesso workflow continua a girare in GitHub Actions mentre CRACI registra la build. Il caricamento su ONEKEY avviene così da una build di cui ha le evidenze. L'esempio Yocto nella documentazione di CRACI mostra un workflow BitBake completo. Oggi CRACI supporta solo GitHub Actions, quindi le pipeline GitLab o Jenkins dovrebbero essere spostate per usare i runner CRACI. GitLab CI e Jenkins sono in roadmap. Veda come funziona CRACI per l'IoT industriale e l'elettronica di consumo.
Sta valutando più di due strumenti? Alternative a ONEKEY mette a confronto nove opzioni fianco a fianco.
Porti una build di firmware alla demo
Prenoti una demo: eseguiremo su CRACI una delle Sue build firmware GitHub Actions e vedremo insieme che cosa ha scaricato.
Prenota una demo