Comparatif
CRACI vs ONEKEY
ONEKEY examine le firmware que vous livrez. CRACI examine le build qui l'a produit. Pour la plupart des fabricants d'appareils, les deux répondent à des questions différentes, et ces deux questions se posent au titre du Cyber Resilience Act.
Mis à jour le
En bref
ONEKEY est une plateforme de cybersécurité produit et de conformité pour les appareils connectés. Vous envoyez une image de firmware, et elle analyse le binaire pour trouver les composants, les vulnérabilités connues, les zero-days probables et les écarts de conformité, sans avoir besoin du code source. CRACI est un runner GitHub Actions qui enregistre ce que chaque build récupère pendant son exécution et produit la SBOM à partir de cet enregistrement. ONEKEY analyse le résultat ; CRACI conserve les preuves issues du build. Ils se complètent bien, et aucun ne remplace l'autre.
En un coup d'œil
| Fonctionnalité | CRACI | ONEKEY |
|---|---|---|
| Enregistre ce que le build de firmware a récupéré | Observé par le runner pendant chaque job | Analyse l'image une fois construite |
| Exécute vos builds CI | Les jobs s'exécutent sur des runners CRACI | Votre CI envoie le firmware à ONEKEY |
| Analyse l'image binaire finie | Analyse binaire automatisée du firmware | |
| Fonctionne sur un firmware que vous n'avez pas construit | Le build doit s'exécuter sur CRACI | Ni code source ni accès réseau nécessaires |
| Analyse zero-day des binaires | Trouve par exemple des identifiants codés en dur | |
| SBOM en CycloneDX et SPDX | Issue du build, avec un état de complétude | Issue du binaire, plus import de SBOM |
| Politique de trafic sortant pendant le build | Vérifiée avant le job, bloque tout en cas d'échec | Hors de son périmètre |
| Surveillance après la release | Réévalue en continu les SBOM surveillées | Réanalyse le firmware chaque jour |
| Vérifications guidées par rapport aux normes | Export de SBOM et API, pas d'export de rapport ni d'assistant normes | Compliance Wizard pour le CRA, IEC 62443 et d'autres |
| Systèmes CI | GitHub Actions aujourd'hui ; GitLab CI et Jenkins sur la roadmap | Exemples documentés pour GitHub, GitLab et Jenkins |
- Inclus
- En partie
- Non inclus
Ce que ONEKEY fait bien
L'analyse binaire sans code source. ONEKEY analyse directement le firmware compilé. Son site le dit clairement : « No source code or network access needed. » C'est important lorsqu'une grande partie de ce qui est livré sur un appareil vient de fondeurs, de fournisseurs de modules et de sous-traitants dont vous ne voyez jamais le build.
Des résultats au-delà des CVE connues. En plus de confronter les composants aux données de vulnérabilité, ONEKEY exécute une analyse zero-day automatisée qui recherche dans le binaire des problèmes tels que l'injection de commandes, les communications non sécurisées et les identifiants codés en dur.
Des SBOM issues de l'image. ONEKEY génère une SBOM à partir du binaire, vous permet d'importer des SBOM de scanners de code source ou de fournisseurs, et exporte en CycloneDX et SPDX.
L'accompagnement à la conformité. Le Compliance Wizard de ONEKEY guide les équipes à travers les exigences du Cyber Resilience Act, d'IEC 62443-4-2, d'ETSI EN 303 645 et de la Radio Equipment Directive, et exporte les résultats pour une certification par un tiers.
La surveillance et la CI. Sa surveillance réanalyse chaque jour le firmware envoyé à mesure que de nouvelles vulnérabilités apparaissent. La documentation de ONEKEY montre comment envoyer chaque nouveau build depuis GitHub, GitLab ou Jenkins et faire échouer le pipeline lorsque de nouveaux résultats apparaissent. ONEKEY maintient aussi unblob, une suite open source d'extraction de blobs binaires.
Ce qui distingue CRACI
Un scan binaire remonte à partir de l'image finie. CRACI part du build, car c'est la machine sur laquelle le build s'exécute.
Le build est la source de vérité
Votre workflow de firmware s'exécute sur les runners de CRACI grâce à une modification d'une seule ligne, celle de runs-on. Pendant l'exécution d'un job, un proxy qui comprend les paquets enregistre ce qu'il télécharge depuis les sources de paquets, et les paquets restaurés depuis les caches CI sont reportés. Chaque SBOM indique son niveau de complétude, par job et par cache : Complete, Complete with connections, Incomplete, Unavailable ou Not recorded. Pour Yocto, CRACI exécute BitBake sur des runners allant jusqu'à 32 vCPU et 96 GB de RAM. Dans un build comparatif de core-image-sato, la SBOM de CRACI contenait tous les composants de la sortie SPDX de Yocto, 88 de plus tels que des paquets de l'hôte et des GitHub Actions, et une package URL pour chacune des 653 versions de crates Rust que Yocto liste sans en donner. Les sources que BitBake récupère depuis le miroir de sources Yocto sont enregistrées dans la SBOM du job CRACI.
Le contrôle de ce que le build peut atteindre
Une politique de trafic sortant au niveau du runner décide à quels hôtes un job peut se connecter. Elle est validée avant le démarrage du job, bloque tout en cas d'échec et envoie une alerte en cas de violation. Pour Yocto, elle ajoute une seconde couche au BB_ALLOWED_NETWORKS de BitBake.
La provenance et ce qui a été livré
L'API renvoie les SBOM, les traces réseau et la provenance. CRACI ne signe pas la provenance. Il agrège les vulnérabilités de l'ensemble des builds et des dépôts et continue de réévaluer les SBOM surveillées à mesure que paraissent les avis de sécurité.
Ce que CRACI ne fait pas compte tout autant ici. Il n'analyse pas les binaires : il ne peut donc pas vous dire ce que contient un blob fournisseur que votre build télécharge, seulement que le build l'a récupéré et d'où.
Un inventaire de ce qui est déployé et où
La vue d'inventaire de CRACI montre précisément quelles versions logicielles sont déployées dans quels produits, à l'échelle mondiale. Lorsqu'une nouvelle vulnérabilité apparaît, vous voyez quels produits exécutent la version concernée, au lieu de reconstituer l'information à partir de notes de version et de tableurs.
Quand utiliser l'un, l'autre, ou les deux
- Vous intégrez un firmware que vous ne construisez pas. ONEKEY. L'analyse binaire est le moyen de voir à l'intérieur.
- Vous construisez votre propre image Linux dans GitHub Actions. CRACI exécute le build et enregistre ses entrées. Ajouter ONEKEY vous donne une seconde vue, indépendante, de l'image finie.
- Un auditeur demande comment vous savez que la SBOM correspond au produit. L'enregistrement du runner CRACI répond à « qu'est-ce qui est entré dans ce build ? » ; l'analyse de ONEKEY répond à « qu'y a-t-il dans cette image ? ». Ensemble, ils se recoupent.
- Vous avez besoin de vérifications guidées par rapport à IEC 62443 ou ETSI EN 303 645. ONEKEY les intègre. CRACI exporte les SBOM en CycloneDX ou SPDX, et son API renvoie les traces réseau et la provenance, pour votre démarche plus large.
Pour le CRA
Le Cyber Resilience Act demande aux fabricants de recenser et de documenter les composants de leurs produits, notamment au moyen d'une SBOM, et de gérer les vulnérabilités aussi longtemps que le produit est pris en charge. Le signalement des vulnérabilités activement exploitées s'applique à partir de septembre 2026. ONEKEY aide en analysant le firmware que vous mettez sur le marché et en vous guidant à travers les exigences. CRACI aide en produisant, pour chaque build, des preuves de ce qui est entré dans ce firmware, avec la provenance et une surveillance continue. CRACI automatise une part importante de la visibilité sur la chaîne d'approvisionnement logicielle et des preuves dont les fabricants ont besoin pour leur démarche plus large de conformité au CRA ; il ne rend pas un produit conforme à lui seul. Lire ce qu'exige le CRA.
Ajouter CRACI en complément de ONEKEY
Gardez votre étape d'envoi à ONEKEY. Faites passer le job de firmware sur un runner CRACI en indiquant runs-on: craci, et le même workflow continue de s'exécuter dans GitHub Actions pendant que CRACI enregistre le build. L'envoi à ONEKEY se fait alors depuis un build dont vous détenez les preuves. L'exemple Yocto de la documentation CRACI présente un workflow BitBake complet. CRACI ne prend en charge que GitHub Actions aujourd'hui : les pipelines GitLab ou Jenkins devraient donc migrer pour utiliser les runners CRACI. GitLab CI et Jenkins figurent sur la roadmap. Découvrez comment CRACI fonctionne pour l'IoT industriel et l'électronique grand public.
Vous comparez plus de deux outils ? Alternatives à ONEKEY compare neuf options côte à côte.
Apportez un build de firmware à la démo
Réservez une démo : nous exécuterons l'un de vos builds de firmware GitHub Actions sur CRACI et passerons en revue ce qu'il a récupéré.
Réserver une démo