Comparatif des outils de conformité au CRA

À qui s'adresse cette page

Vous fabriquez un produit comportant des éléments numériques et le mettez sur le marché de l'UE. Le Cyber Resilience Act, règlement (UE) 2024/2847, s'applique à vous par étapes : ses obligations de signalement à partir du 11 septembre 2026, et ses principales dispositions à partir du 11 décembre 2027. Vous choisissez des outils pour les volets techniques de ce travail. Nous développons CRACI, tenez-en compte. Nous décrivons chaque outil d'après sa propre documentation et indiquons où un autre outil convient mieux.

Une règle traverse toute cette page. La conformité est une démarche que mène le fabricant, avec l'évaluation des risques, la documentation et l'évaluation de la conformité. Les outils produisent des preuves et automatisent une partie du travail. Aucun des outils ci-dessous ne rend un produit conforme à lui seul.

Ce que demande le CRA

Pour la chaîne d'approvisionnement logicielle, cinq exigences font l'essentiel du travail.

1. Une SBOM. Les fabricants recensent et documentent les composants du produit, « notamment en établissant une nomenclature des logiciels dans un format couramment utilisé et lisible par machine couvrant au minimum les dépendances de niveau supérieur des produits » (annexe I, partie II). L'annexe VII la place dans la documentation technique, qu'une autorité de surveillance du marché peut demander.
2. La gestion des vulnérabilités. Traiter et corriger les vulnérabilités sans délai, notamment au moyen de mises à jour de sécurité, effectuer des tests réguliers et appliquer une politique de divulgation coordonnée des vulnérabilités (annexe I, partie II).
3. Le signalement. Notifier les vulnérabilités activement exploitées et les incidents graves à votre CSIRT et à l'ENISA via la plateforme unique de signalement du CRA : une alerte précoce dans les 24 heures, une notification dans les 72 heures, et un rapport final au plus tard 14 jours après la mise à disposition d'un correctif ou d'une mesure d'atténuation pour une vulnérabilité, ou dans un délai d'un mois pour un incident grave (article 14).
4. Les preuves. Une documentation technique, une évaluation de la conformité et une déclaration UE de conformité (articles 28, 31 et 32, annexe VII), tenues à la disposition des autorités pendant au moins 10 ans après la mise sur le marché du produit ou pendant la période de support si elle est plus longue (article 13).
5. Une période de support. Une période qui reflète la durée pendant laquelle le produit est censé être utilisé, d'au moins cinq ans sauf si la durée d'utilisation prévue est plus courte, pendant laquelle les vulnérabilités sont gérées efficacement (article 13).

Comment choisir

• Pour quelle moitié du travail avez-vous besoin d'aide ? Les outils techniques produisent la SBOM, les enregistrements de vulnérabilités et les preuves de build. Les plateformes de gestion de la conformité associent les exigences à des contrôles, rédigent des politiques et suivent la démarche. La plupart des outils excellent dans l'une des deux moitiés : déterminez donc quel manque est le plus important.
• Construisez-vous le logiciel, ou l'intégrez-vous ? Si une grande partie du produit vous parvient sous forme binaire de fondeurs de puces et de fournisseurs, l'analyse binaire est le moyen d'en voir l'intérieur. Si vous le construisez vous-même, le build est la source de preuves la plus directe.
• D'où vient votre SBOM, et comment savez-vous qu'elle est complète ? Les scanners, l'interrogation des outils de build et l'enregistrement du build peuvent donner des réponses différentes pour une même release.
• Pouvez-vous trouver les releases concernées en quelques heures ? Une alerte précoce sous 24 heures dépend d'un inventaire par release auquel vous faites confiance.
• Avez-vous besoin d'un système de référence ? Avec de nombreux produits et fournisseurs, la gestion des SBOM avec VEX et le partage devient un travail à part entière.

En un coup d'œil

Deux tableaux : d'abord les outils SBOM, SCA et de gestion des SBOM, puis les outils conçus pour les firmwares et les appareils. Les lignes suivent les exigences ci-dessus. « Non précisé » signifie que les pages des fournisseurs que nous citons ne disent ni oui ni non.

SBOM, SCA et gestion des SBOM

Firmwares et appareils

CRACI

CRACI est un runner GitHub Actions. Pour les logiciels que vous construisez, il enregistre ce que chaque job a récupéré, paquets restaurés depuis les caches CI compris, et produit une SBOM CycloneDX ou SPDX avec un état de complétude par job et par cache. Il continue de réévaluer les SBOM de ce qui a été livré, prend en charge VEX, et soumet en votre nom les notifications prévues par le CRA lorsqu'une vulnérabilité activement exploitée doit être signalée. Pour Yocto, il enregistre ce que la sortie SPDX propre à Yocto laisse de côté. Aide pour : la génération de SBOM, la gestion des vulnérabilités, les notifications CRA, les preuves. Points d'attention : il n'analyse pas les binaires que vous n'avez pas construits, n'offre ni mise en correspondance des contrôles ni gestion des politiques, et prend en charge GitHub Actions aujourd'hui (GitLab CI et Jenkins figurent sur la roadmap). La conformité au CRA avec CRACI

Gestion des SBOM

Cybeats

Cybeats SBOM Studio se présente comme « le système de référence des SBOM ». Il stocke les SBOM de vos produits et de vos fournisseurs en SPDX 2.2 à 3.0.1 et CycloneDX 1.2 à 1.7, les valide avec un Quality Score avant l'import, compare chaque composant aux données de veille sur les vulnérabilités, émet des VEX et partage les SBOM avec les clients, y compris via la Transparency Exchange API. Son guide des réglementations présente le calendrier de 24 heures, 72 heures et 14 jours du CRA. Aide pour : la gestion des SBOM, la gestion des vulnérabilités, les preuves. Points d'attention : pour la génération, il renvoie vers des fournisseurs de sa Marketplace : la SBOM elle-même vient donc d'un autre outil. CRACI vs Cybeats et Alternatives à Cybeats

FOSSA

FOSSA a commencé par la conformité des licences et couvre désormais tout le cycle de vie des SBOM. Il génère des SBOM SPDX et CycloneDX, avec en option des déclarations VDR ou VEX, importe les SBOM des fournisseurs avec des politiques sur les éléments minimaux NTIA et FDA, les surveille pour détecter les vulnérabilités, et les partage via un SBOM Portal sur Enterprise. En septembre 2026, il propose un plan gratuit, et Business coûte $20 par projet et par mois, en facturation annuelle. Aide pour : la SBOM, le partage avec les autorités, les licences. Points d'attention : la CLI FOSSA analyse le projet via son outil de build ou par déduction à partir des sources, au lieu d'enregistrer le build. CRACI vs FOSSA

Anchore

Anchore Enterprise s'appuie sur les outils open source Syft et Grype. Il scanne les images de conteneurs, les systèmes de fichiers et les SBOM importées, rescanne les SBOM stockées sans l'artefact d'origine, applique des packs de politiques comme FedRAMP et NIST, et s'auto-héberge, y compris en environnement isolé (air-gapped). Ses contenus sur le CRA couvrent la gestion des SBOM, la surveillance à partir de sources dont CISA KEV, l'aide au respect des délais de 24 et 72 heures, les annotations VEX et les pistes d'audit. Aide pour : la SBOM, la gestion des vulnérabilités, les preuves. Points d'attention : ses SBOM décrivent ce qu'un scanner trouve dans une image ou un répertoire, et non ce que le build a récupéré puis laissé derrière lui. CRACI vs Anchore

Suites SCA

Black Duck

Black Duck SCA combine le scan des gestionnaires de paquets, par signature, par extrait de code et des binaires : il trouve ainsi l'open source que personne n'a déclaré, et sa KnowledgeBase suit plus de 2 750 licences. Binary Analysis examine les firmwares sans code source, Coverity fournit le SAST avec une option de vérificateurs alignés sur le CRA annoncée en juillet 2026, et Defensics réalise des tests de fuzzing. Black Duck soutient que le CRA nécessite plusieurs couches de tests, et pas seulement de la SCA. Aide pour : la SBOM, la gestion des vulnérabilités des composants et de votre propre code, les tests. Points d'attention : les tarifs sont sur devis, et chaque technique inspecte le code ou le résultat plutôt que le build. CRACI vs Black Duck

Sonatype

Sonatype Lifecycle applique des politiques open source à l'aide de données d'atteignabilité et de mise à niveau, et ouvre des Golden Pull Requests. Repository Firewall met en quarantaine les composants non conformes aux politiques avant qu'ils n'entrent dans vos dépôts. SBOM Manager importe, surveille et partage les SBOM avec un workflow VEX, et Sonatype le positionne comme son produit pour le CRA ; son guide présente aussi Nexus Repository comme site de distribution des mises à jour de sécurité. Aide pour : la gestion des vulnérabilités, la gestion des SBOM, le blocage des composants dangereux. Points d'attention : l'offre évolue (les nouveaux clients achètent Sonatype Guide), et Lifecycle analyse ce que le build a produit plutôt que ce qu'il a récupéré. CRACI vs Sonatype

Firmwares et appareils

ONEKEY

ONEKEY analyse les firmwares compilés « sans code source ni accès réseau ». Il génère une SBOM à partir du binaire, importe les SBOM des fournisseurs, recherche de probables zero-days tels que des identifiants codés en dur, et réanalyse les firmwares chaque jour. Son Compliance Wizard guide les équipes à travers le CRA, IEC 62443-4-2, ETSI EN 303 645 et la directive sur les équipements radioélectriques. Aide pour : la SBOM des firmwares que vous n'avez pas construits, la gestion des vulnérabilités, les contrôles guidés. Points d'attention : il travaille sur l'image après le build : il n'enregistre donc pas ce que le build a récupéré. CRACI vs ONEKEY et Alternatives à ONEKEY

Finite State

Finite State analyse les firmwares, les binaires, le code source et les SBOM des fournisseurs, avec la prise en charge de plus de 50 architectures de jeux d'instructions binaires, et les réunit dans un enregistrement unique par produit. Il classe les résultats selon l'atteignabilité et les données sur les exploits, enregistre les décisions VEX, et son workflow de conformité couvre la mise en correspondance des contrôles du CRA et des rapports prêts pour l'audit avec des artefacts SBOM et VEX. Aide pour : la SBOM sur l'ensemble des fournisseurs, le tri des vulnérabilités, les preuves. Points d'attention : il part des artefacts : contrôler ce que votre propre build pouvait joindre sort donc de son périmètre. CRACI vs Finite State et Alternatives à Finite State

Exein

Exein travaille sur l'appareil. Exein Runtime utilise eBPF pour surveiller et bloquer les comportements malveillants sur Linux embarqué, et la couche Yocto open source meta-exein intègre son agent Pulsar à votre image. Exein Analyzer scanne les firmwares avant la mise en production, ou votre SBOM lorsque le binaire n'est pas disponible, priorise à l'aide d'un score d'atteignabilité, et met les résultats en correspondance avec les exigences du CRA. Aide pour : la gestion des vulnérabilités sur le terrain, la SBOM des firmwares, la mise en correspondance avec le CRA. Points d'attention : la couche Yocto modifie ce qui s'exécute sur l'appareil ; elle n'exécute ni n'enregistre votre build. CRACI vs Exein

Plateformes de gestion de la conformité

Ces outils ne génèrent pas de SBOM et ne scannent pas de code. Ils travaillent sur le volet gouvernance : associer les exigences du CRA à des contrôles, rédiger des politiques, et suivre les échéances et les validations. Ils ont besoin de preuves techniques venues d'ailleurs.

Venvera

Venvera est une plateforme de conformité développée dans l'UE qui couvre le CRA aux côtés de NIS2, DORA, ISO 27001 et SOC 2. Pour le CRA, elle suit les délais de signalement de 24 et 72 heures, la gestion des vulnérabilités, la SBOM en tant qu'exigence à maintenir, la procédure d'évaluation de la conformité selon la classe de produit, ainsi que la documentation technique de l'annexe VII et la déclaration UE de conformité. Aide pour : la mise en correspondance des contrôles, les délais de signalement, le suivi de la démarche de conformité. Points d'attention : elle vérifie qu'une SBOM existe et qu'elle est tenue à jour ; la SBOM elle-même vient d'un autre outil.

ZeroRisk

ZeroRisk est une plateforme de conformité agentique couvrant le RGPD, ISO 27001, SOC 2, NIS2, DORA et le CRA. Pour le CRA, son agent associe les exigences à votre organisation, pré-remplit une évaluation de préparation, rédige les contrôles et politiques manquants, et surveille les fournisseurs présents dans vos produits, avec une nouvelle vérification toutes les 24 heures et une validation humaine de chaque conclusion. Aide pour : la préparation, les politiques, l'assurance fournisseurs. Points d'attention : sa page sur le CRA ne mentionne ni la génération de SBOM ni la surveillance des vulnérabilités de vos propres builds.

Signaler dans les délais

L'article 14 fait peser la notification sur le fabricant, et il s'applique depuis le 11 septembre 2026, y compris pour les produits déjà sur le marché. Ce que les outils peuvent faire, c'est raccourcir le délai entre « cette vulnérabilité est exploitée » et « nous savons quels produits et quelles releases la contiennent ». Cela dépend d'inventaires par release auxquels vous faites confiance, d'une surveillance continue et d'un lien entre chaque artefact livré et ses composants. Anchore et Cybeats décrivent les délais de signalement dans leurs contenus sur le CRA, Venvera suit les échéances, et l'analyse binaire d'ONEKEY, de Finite State ou d'Exein couvre le code des fournisseurs que vous ne pouvez pas reconstruire. L'API de CRACI renvoie les SBOM, les traces réseau et la provenance, et CRACI soumet l'alerte précoce, la notification et le rapport final au nom du fabricant.

La place de CRACI

CRACI est un runner GitHub Actions. Pour les logiciels que vous construisez, il enregistre ce que chaque job a récupéré, paquets restaurés depuis les caches CI compris, et produit une SBOM CycloneDX ou SPDX avec un état de complétude par job et par cache. Il applique une politique de trafic sortant au build, continue de réévaluer les SBOM de ce qui a été livré, prend en charge VEX, et exporte les SBOM en CycloneDX ou SPDX, vulnérabilités comprises, pour vos preuves pour le CRA. Lorsqu'une vulnérabilité activement exploitée doit être signalée, CRACI soumet en votre nom les notifications prévues par le CRA. Pour Yocto, il exécute BitBake sur des runners allant jusqu'à 32 vCPU et 96 Go de RAM et enregistre ce que la sortie SPDX propre à Yocto laisse de côté, comme les paquets de l'hôte et les package URLs des crates Rust. La vue d'inventaire de CRACI montre précisément quelles versions logicielles sont déployées dans quels produits, à l'échelle mondiale. CRACI automatise une part importante de la visibilité sur la chaîne d'approvisionnement logicielle et des preuves dont les entreprises ont besoin pour leur démarche plus large de conformité au CRA.

Il ne suffit pas à lui seul si l'essentiel de votre produit vous parvient de fournisseurs sous forme binaire, ou si vous avez besoin de contrôles guidés au regard de normes, de mise en correspondance des contrôles et de gestion des politiques, d'une protection sur l'appareil, ou de systèmes CI autres que GitHub Actions dès aujourd'hui (GitLab CI et Jenkins figurent sur la roadmap). Pour les builds qui vous appartiennent, CRACI couvre la SBOM, la surveillance et les notifications CRA dans un seul produit ; pour les firmwares que vous ne pouvez pas reconstruire, l'analyse binaire voit ce que votre build n'a jamais vu. Voir ce qu'est le CRA, la conformité au CRA et l'IoT industriel.

Outils de conformité au CRA : questions fréquentes

Ce que fait un logiciel de conformité au CRA, et ce qui reste du ressort du fabricant

Qu'est-ce qu'un logiciel de conformité au CRA ?

Un logiciel qui aide un fabricant à respecter le Cyber Resilience Act. Il en existe deux types : les outils techniques qui produisent la SBOM, les enregistrements de vulnérabilités et les preuves de build, et les plateformes de gestion de la conformité qui associent les exigences à des contrôles et suivent les délais de signalement, l'évaluation des risques et l'évaluation de la conformité. Aucun ne rend un produit conforme à lui seul.

Quelles obligations du CRA un outil peut-il automatiser ?

Surtout le volet gestion des vulnérabilités : générer la SBOM, la surveiller pour détecter de nouvelles vulnérabilités, trouver les releases concernées, enregistrer les décisions de tri et VEX, préparer et soumettre les notifications de l'article 14, et exporter les preuves pour la documentation technique. L'évaluation des risques, la conception sécurisée, l'évaluation de la conformité et la déclaration de conformité restent des décisions du fabricant.

Ai-je besoin d'un outil ou de plusieurs ?

Généralement de plusieurs. Un outil technique vous fournit la SBOM et les preuves sur les vulnérabilités ; une plateforme de gestion de la conformité ou un consultant couvre les contrôles, les politiques et la procédure d'évaluation de la conformité. Pour les firmwares que vos fournisseurs vous livrent sous forme binaire, l'analyse binaire apporte ce que votre propre build ne peut pas voir.

Quel est le délai de signalement prévu par le CRA ?

L'article 14 s'applique depuis le 11 septembre 2026 : une alerte précoce dans les 24 heures suivant la prise de connaissance d'une vulnérabilité activement exploitée, une notification dans les 72 heures et un rapport final au plus tard 14 jours après la mise à disposition d'un correctif ou d'une mesure d'atténuation. Il couvre les produits déjà sur le marché. Le reste du CRA s'applique à partir du 11 décembre 2027.

CRACI soumet-il les notifications prévues par le CRA ?

Oui. CRACI soumet l'alerte précoce, la notification et le rapport final au nom du fabricant. L'obligation de signalement reste celle du fabricant.

Un outil réalise-t-il l'évaluation de la conformité au CRA ?

Aucun outil logiciel ne la remplace. Le fabricant réalise l'évaluation, par contrôle interne ou, pour les produits importants et critiques, avec un organisme notifié ou un schéma de certification lorsque le CRA l'exige. Les outils fournissent les preuves sur lesquelles l'évaluation s'appuie.