123% de CVE signalées en plus par jour en 2026 par rapport à l'an dernier.

Comparatif

CRACI vs Exein

Exein sécurise l'appareil : un agent qui s'exécute dessus et un analyseur de firmware avant la mise en production. CRACI sécurise le build : le runner sur lequel votre image Yocto est construite, et l'enregistrement de ce qui y est entré.

Mis à jour le

En bref

Exein conçoit des produits de sécurité pour les appareils embarqués et connectés. Exein Runtime surveille et bloque les menaces sur l'appareil lui-même, et Exein Analyzer scanne les firmwares à la recherche de vulnérabilités avant la mise en production. La couche Yocto d'Exein, meta-exein, place l'agent d'exécution dans votre image. CRACI est un runner GitHub Actions : votre build Yocto s'exécute dessus, et CRACI enregistre ce que le build a téléchargé et limite les destinations auxquelles il peut se connecter. Exein travaille sur l'appareil et le firmware ; CRACI travaille sur le build. La plupart des équipes qui ont besoin des deux utiliseront les deux.

En un coup d'œil

Fonctionnalité CRACI Exein
Exécute vos builds Yocto BitBake sur des runners allant jusqu'à 32 vCPU S'intègre à votre pipeline existant
Enregistre ce que le build a récupéré Observé par le runner pendant chaque job Analyse le firmware, ou une SBOM que vous fournissez
Politique de trafic sortant pendant le build Vérifiée avant le job, blocage total en cas d'échec Hors de son périmètre
Agent de sécurité sur l'appareil Exein Runtime, construit sur eBPF
Couche Yocto pour votre image CRACI exécute le build et n'ajoute rien à l'image meta-exein ajoute Pulsar à l'image
Analyse binaire de firmware Exein Analyzer
Priorisation par atteignabilité Score d'atteignabilité et filtrage par LLM
SBOM Issue du build, avec un état de complétude Générée par Exein Analyzer
Preuves pour le CRA SBOM en CycloneDX ou SPDX, enregistrements via l'API ; pas d'export de rapport Correspondance des preuves CRA dans Analyzer
  • Inclus
  • En partie
  • Non inclus

En quoi consiste l'intégration Yocto d'Exein

Les deux produits sont faciles à confondre, car tous deux mentionnent Yocto : autant être précis. meta-exein est une couche Yocto open source qui, selon Exein, « contains Pulsar and kernel recipes to add the Pulsar security framework to an image. » Vous ajoutez la couche à bblayers.conf, vous ajoutez pulsar à IMAGE_INSTALL et vous activez BTF, et votre image est livrée avec Pulsar, l'outil de sécurité d'exécution d'Exein fondé sur eBPF. La couche est testée sur les releases Yocto à partir de Kirkstone et est devenue une couche officielle Yocto Project Compatible en 2024. Exein a rejoint le Yocto Project en tant que Platinum Member en 2023.

Autrement dit, la couche d'Exein change ce qui s'exécute sur l'appareil. Elle n'exécute pas votre build et n'enregistre pas ce que le build a récupéré. Exein indique aussi qu'Exein Analyzer est « natively integrated into Yocto, Buildroot, and your CI/CD pipeline » afin de scanner chaque nouveau build : il s'agit d'une analyse de la sortie du build au sein de votre propre pipeline.

Ce qu'Exein fait bien

La page d'accueil de Exein
exein.io

La protection à l'exécution sur l'appareil. Exein Runtime est écrit en Rust et utilise eBPF pour surveiller et bloquer les comportements malveillants au niveau du noyau, « the moment it tries to run. » À l'échelle d'une flotte, il retrace les incidents et génère des rapports forensiques et de conformité à partir de la télémétrie d'exécution. Exein publie aussi en open source Pulsar, « a modular and blazing fast runtime security tool for the IoT, powered by eBPF ».

L'analyse du firmware avant la mise en production. Exein Analyzer inspecte directement le firmware final, ou ingère votre SBOM lorsque le binaire n'est pas disponible. Exein indique couvrir Linux, RTOS, Docker, UEFI, Android et d'autres, et utiliser un score d'atteignabilité et un filtrage par LLM pour placer en tête les CVE exploitables.

La remédiation et la correspondance avec le CRA. Exein décrit une remédiation pilotée par l'IA qui s'exécute dans les pipelines Yocto et CI/CD, et fait correspondre les résultats aux exigences du Cyber Resilience Act.

Ce qui distingue CRACI

Il exécute le build

Les builds Yocto sont longs et lourds. CRACI exécute BitBake depuis votre workflow GitHub Actions sur des runners allant jusqu'à 32 vCPU et 96 Go de RAM, définis avec cracicorp/setup@v1 et size: "32". Les jobs s'exécutent dans des machines virtuelles isolées, et les exécutions apparaissent toujours dans GitHub.

Il enregistre ce que le build a récupéré

Pendant l'exécution d'un job, CRACI observe le trafic vers les hôtes de paquets et de sources et le conserve comme preuve de build, avec un état de complétude par job et par cache. Pour Yocto, c'est un compte rendu indépendant de ce qui est passé par le réseau, y compris ce que la SBOM SPDX de la classe create-spdx de Yocto laisse de côté : lors d'un build comparatif de core-image-sato, la SBOM de CRACI contenait chaque composant de celle de Yocto, 88 de plus, comme les paquets de l'hôte et les GitHub Actions, et une package URL pour chacune des 653 versions de crates Rust que Yocto liste sans en fournir. Les sources que BitBake récupère depuis le miroir de sources Yocto sont enregistrées dans la SBOM du job CRACI.

Il contrôle les connexions du build

BitBake peut restreindre son fetcher avec BB_ALLOWED_NETWORKS. CRACI ajoute une politique de trafic sortant sur le runner, validée avant le démarrage du job et qui bloque tout en cas d'échec : un script ou un outil qui contourne le fetcher ne peut donc toujours pas joindre un hôte que vous n'avez pas autorisé. CRACI vous alerte en cas de violation.

Il surveille ce qui a été livré

L'API renvoie les SBOM, les traces réseau et la provenance. CRACI 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.

CRACI n'installe rien sur l'appareil et n'analyse pas les binaires. Si vous avez besoin d'une protection à l'exécution ou d'un scan d'une image finie, c'est le terrain d'Exein.

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 voulez détecter et bloquer les menaces sur les appareils déployés sur le terrain. Exein Runtime. CRACI n'a aucun composant sur l'appareil.
  • Vos builds Yocto s'exécutent sur un serveur sous un bureau, ou prennent des heures sur de petits runners CI. CRACI les exécute depuis GitHub Actions et conserve un enregistrement de chacun.
  • Vous livrez une image Yocto avec meta-exein. Construisez-la sur CRACI. La couche se construit comme n'importe quelle autre, et CRACI enregistre ce que le build a récupéré.
  • Vous devez montrer d'où vient la SBOM. L'enregistrement du runner CRACI relie la SBOM à un build précis. Le scan de la sortie par Exein Analyzer offre un second regard utile.

Pour le CRA

Le Cyber Resilience Act demande aux fabricants de documenter les composants de leurs produits, notamment au moyen d'une SBOM, de gérer les vulnérabilités pendant toute la période de support et, à partir de septembre 2026, de signaler les vulnérabilités activement exploitées. Exein aide du côté de l'appareil, avec l'analyse du firmware avant la mise en production, la correspondance des preuves CRA et la télémétrie d'exécution venue du terrain. CRACI aide du côté du build, avec des preuves par build de ce qui est entré dans le firmware, la provenance, une surveillance continue et l'export des SBOM en CycloneDX ou SPDX. 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 à un workflow Yocto

Gardez vos couches, y compris meta-exein, et votre étape Exein Analyzer. Définissez runs-on: craci sur le job de build et choisissez une taille de runner. L'exemple Yocto de la documentation CRACI construit core-image-sato avec le miroir de sources officiel de Yocto et un réglage BB_ALLOWED_NETWORKS correspondant. CRACI ne prend en charge que GitHub Actions aujourd'hui, avec GitLab CI et Jenkins sur la roadmap. Découvrez comment CRACI fonctionne pour l'IoT industriel et l'électronique grand public.

Venez à la démo avec un build Yocto

Réservez une démo : nous exécuterons l'un de vos builds BitBake sur un runner CRACI et passerons en revue ce qu'il a récupéré.

Réserver une démo