Alternatives à Cybellum

Nous développons CRACI, tenez-en compte ; nous décrivons chaque option à partir de sa propre documentation et indiquons quand un autre outil convient mieux.

Pourquoi les équipes regardent au-delà de Cybellum

Cybellum est une plateforme de sécurité produit destinée aux fabricants d'appareils des secteurs automobile, médical et industriel. Ses Cyber Digital Twins « peuvent être extraits des fichiers binaires de n'importe quel produit ou composant », et la plateforme les fusionne avec le code source et les SBOM « aux formats SPDX, CycloneDX ou CSV de CPE ». Elle surveille les versions et les branches en post-production, trie avec un assistant IA, montre « quels produits ou composants sont concernés par une nouvelle vulnérabilité ou réglementation », offre à un PSIRT « un espace de travail pour créer et gérer des investigations », et partage les statuts « via des rapports VEX/CSAF ». Des modèles réglementaires couvrent la FDA PMA, l'ISO 21434 et le CRA européen. LG Electronics en a acquis une participation majoritaire en 2021.

Les équipes comparent tout de même des alternatives, généralement pour l'une de ces raisons :

• L'essentiel du logiciel est le leur. Analyser un binaire revient à remonter depuis le résultat. Une équipe qui construit ses propres logiciels et images peut plutôt enregistrer ce qui y est entré.
• Un besoin plus ciblé. Certaines équipes n'ont besoin que de l'analyse de firmware, que d'un système de référence des SBOM, ou que de la réception des avis et du traitement des dossiers, plutôt que d'une plateforme complète de sécurité produit.
• L'adéquation au secteur. Les modèles de Cybellum penchent vers la réglementation automobile et médicale ; certaines équipes veulent un outil conçu autour d'un seul secteur, ou au contraire d'aucun.
• Tarifs et hébergement. Cybellum ne publie aucun prix, et certaines équipes veulent une base open source qu'elles exploitent elles-mêmes.

Ce qu'un PSIRT doit examiner

• Un inventaire de ce qui est livré : s'il provient du binaire, des SBOM qu'on vous fournit ou du build.
• Les produits et versions concernés : à quelle vitesse l'outil répond à « où livrons-nous ce composant ? ».
• La surveillance après la release, et les flux de vulnérabilités qu'il suit.
• Le tri : signaux d'exploitabilité, VEX, et transmission de chaque résultat à l'équipe chargée de la correction.
• Les avis et le reporting : ce que vous pouvez publier à l'intention de vos clients, et les preuves qu'exige le Cyber Resilience Act.
• La couverture CI, les options d'hébergement et l'évolution des tarifs avec l'usage.

Pour le processus lui-même, voir ce que fait un PSIRT et le comparatif des outils PSIRT.

Les options

1. CRACI (notre produit)

CRACI est un runner GitHub Actions qui produit la SBOM pendant l'exécution du build. Il s'adresse aux équipes qui construisent leurs propres logiciels et firmwares. Un proxy qui comprend les paquets enregistre ce que chaque job récupère depuis les hôtes de paquets et de code source, y compris les paquets restaurés depuis les caches CI, et chaque SBOM indique sa complétude par job et par cache. Les builds Yocto s'exécutent sur des runners allant jusqu'à 32 vCPU et 96 Go de RAM : lors d'un build de core-image-sato comparé côte à côte, la SBOM de CRACI contenait chaque composant de la SBOM propre à Yocto, plus 88 que celle-ci avait manqués, comme des paquets de l'hôte et des GitHub Actions, ainsi qu'une package URL pour chacune des 653 versions de crates Rust que Yocto liste sans en avoir.

Pour un PSIRT, CRACI conserve chaque build passé avec sa SBOM : vous voyez quels builds contenaient une dépendance vulnérable et pendant combien de temps, et sa vue d'inventaire montre quelles versions logicielles sont déployées dans quels produits. Il réévalue en continu les SBOM surveillées, prend en charge VEX, et permet aux équipes sécurité de trier les résultats et de transmettre chacun à l'équipe chargée de la correction. Vous pouvez ajouter les SBOM de vos fournisseurs, afin que les composants achetés soient surveillés aux côtés de vos propres builds. Comme CRACI exécute le job, il applique aussi une politique de trafic sortant qui bloque tout en cas d'échec.

Idéal pour : les fabricants qui construisent leurs propres logiciels et images sur GitHub Actions et veulent réunir au même endroit le build, la SBOM et le suivi des vulnérabilités. À envisager si : vous pouvez vous passer de l'analyse de binaires, de la détection de zero-days, de l'atteignabilité et des vérifications guidées par rapport aux normes, dont CRACI ne dispose pas ; il ne peut pas voir à l'intérieur d'un firmware que vous n'avez pas construit. Il prend en charge GitHub Actions uniquement, avec GitLab CI et Jenkins sur la roadmap. CRACI vs Cybellum

2. ONEKEY

ONEKEY analyse le firmware compilé « sans code source ni accès réseau nécessaires ». Il génère une SBOM à partir du binaire, importe les SBOM des fournisseurs, exporte en CycloneDX et SPDX, recherche de probables zero-days comme des identifiants codés en dur, et réanalyse le firmware chaque jour. Son Compliance Wizard guide les équipes à travers le CRA, l'IEC 62443-4-2, l'ETSI EN 303 645 et la Radio Equipment Directive.

Idéal pour : les fabricants d'appareils qui vérifient des images de firmware qu'ils n'ont pas construites, avec des vérifications guidées par rapport aux normes. À envisager si : vous voulez l'analyse d'images sans les modèles réglementaires automobiles et médicaux. CRACI vs ONEKEY

3. Finite State

Finite State analyse le firmware, 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 réunit le tout dans un seul dossier produit. Il classe les résultats selon l'atteignabilité, les données d'exploitation et le contexte produit, enregistre les décisions VEX, et son workflow de conformité couvre la correspondance avec les contrôles du CRA et des rapports prêts pour l'audit, avec artefacts SBOM et VEX. Il intègre des vérifications dans GitHub Actions, GitLab CI et Jenkins.

Idéal pour : les fabricants d'objets connectés qui doivent analyser le firmware de nombreux fournisseurs, avec moins de bruit lié aux résultats non atteignables. À envisager si : l'atteignabilité est le signal selon lequel votre PSIRT trie. CRACI vs Finite State

4. NetRise

NetRise Turbine analyse le code compilé « pour créer des SBOM précises et révéler les risques au sein du logiciel qui s'exécute réellement » sur les appareils, et priorise les vulnérabilités selon l'atteignabilité et l'exploitabilité. NetRise Provenance examine l'origine, les mainteneurs et la santé des dépôts des composants open source. Dragos a acquis NetRise le 21 septembre 2026 et le positionne pour les parcs de technologies opérationnelles (OT).

Idéal pour : les équipes de sécurité produit, de risque tiers et de réponse aux incidents, en particulier dans l'industrie et les infrastructures critiques, qui doivent savoir ce qui s'exécute sur les appareils. À envisager si : un achat sur devis vous convient ; NetRise ne publie aucun prix et fait partie de Dragos depuis septembre 2026.

5. Cybeats

Cybeats SBOM Studio est un système de référence qui ingère, gère, surveille et partage des SBOM entre produits et fournisseurs. Il évalue la qualité des SBOM à l'import et partage SBOM et VEX avec les clients. Pour la génération de SBOM et l'analyse de la composition des binaires, Cybeats renvoie vers les fournisseurs de sa Marketplace, et son module RAVEN raisonne sur l'atteignabilité et rédige du VEX.

Idéal pour : les fabricants des secteurs médical, industriel et télécoms qui mènent un programme SBOM couvrant de nombreux produits et fournisseurs. À envisager si : vous disposez déjà d'un moyen de générer des SBOM ; SBOM Studio gère des SBOM générées par un autre outil. CRACI vs Cybeats

6. Medcrypt

Medcrypt se concentre sur les fabricants de dispositifs médicaux. Son produit Helm prend en charge la gestion des SBOM et des vulnérabilités : vous « importez ou créez manuellement des SBOM (CycloneDX ou SPDX) », ou vous connectez Helm à votre pipeline via son API, sa GitHub Action ou son intégration Azure DevOps. Helm s'appuie sur l'EPSS, le CISA KEV, ExploitDB et Metasploit pour classer les vulnérabilités, les réévalue à l'arrivée des données de correctifs, et exporte des SBOM, des VDR et du VEX. Medcrypt propose aussi des services comme la revue de modélisation des menaces et un accompagnement pour les soumissions à la FDA.

Idéal pour : les fabricants de dispositifs médicaux qui préparent des soumissions pré-commercialisation à la FDA et assurent la gestion des vulnérabilités post-commercialisation. À envisager si : vos produits ne sont pas des dispositifs médicaux, ou s'il vous faut une analyse de binaires, que Medcrypt ne décrit pas.

7. DefectDojo

DefectDojo est une plateforme open source de gestion des vulnérabilités qui ingère les résultats de « plus de 500 intégrations », les dédoublonne et suit leur remédiation. Son PSIRT Advisory Engine, inclus dans DefectDojo Pro, reçoit les avis de la CISA, de la NVD, de l'EUVD et de plus d'une douzaine d'autres flux, les confronte à vos données SBOM, les note avec CVSS, EPSS et KEV, regroupe les correspondances en dossiers dotés de responsables, et génère des avis PDF à votre image. Pro s'exécute dans le cloud ou en auto-hébergement.

Idéal pour : les PSIRT qui veulent la réception des avis, le traitement des dossiers et le suivi des SLA sur une base open source de gestion des vulnérabilités. À envisager si : vous avez déjà des SBOM à confronter ; DefectDojo ne les génère pas et n'analyse pas les binaires. La Community Edition est gratuite ; Pro coûte $100 par mois plus 15 cents par résultat (en octobre 2026).

8. Exein

Exein travaille sur l'appareil et sur le firmware. Exein Runtime utilise eBPF pour surveiller et bloquer les comportements malveillants sous Linux embarqué, et la couche Yocto open source meta-exein intègre son agent Pulsar dans votre image. Exein Analyzer inspecte le firmware avant la release, ou votre SBOM lorsque le binaire n'est pas disponible, classe les résultats avec un score d'atteignabilité et un filtrage par LLM, et les met en correspondance avec les exigences du CRA.

Idéal pour : les fabricants sous Linux embarqué qui veulent une protection sur le terrain en plus de l'analyse de firmware. À envisager si : livrer un agent sur l'appareil ne vous pose pas de problème. CRACI vs Exein

9. Timesys Vigiles

Vigiles, désormais commercialisé par Lynx Software Technologies, transforme les métadonnées d'un build Yocto ou Buildroot en SBOM et les confronte à une base de CVE soigneusement maintenue. Les équipes indiquent si chaque CVE est concernée, corrigée, reportée ou non exploitable, Vigiles conserve ces décisions par release, et il exporte des SBOM ainsi que du VEX et des rapports de vulnérabilités.

Idéal pour : les équipes Linux embarqué qui veulent moins de bruit lié aux CVE sur leurs images Yocto et Buildroot. À envisager si : vos produits ne sont pas construits sur Linux embarqué. CRACI vs Timesys Vigiles

Côte à côte

« Medcrypt Helm » désigne le produit de gestion des SBOM et des vulnérabilités de Medcrypt, « NetRise » désigne NetRise Turbine, et « Cybeats » désigne SBOM Studio. Timesys Vigiles est décrit plus haut et ne figure pas dans le tableau. « Non précisé » signifie que la fonctionnalité n'est pas décrite dans la documentation du fournisseur, et non qu'elle est absente.

Pour le Cyber Resilience Act

Cybellum, ONEKEY, Finite State, DefectDojo et Exein décrivent tous une prise en charge du CRA. Ses obligations de signalement s'appliquent depuis le 11 septembre 2026, et ses principales dispositions s'appliquent à partir du 11 décembre 2027. Une alerte précoce sous 24 heures suppose de savoir rapidement quelles releases contiennent un composant affecté. Pour les logiciels que vous construisez, CRACI conserve l'historique des builds avec la SBOM de chacun : vous voyez quels builds contenaient une dépendance vulnérable. Son API renvoie les SBOM, les traces réseau et la provenance, les SBOM s'exportent en CycloneDX ou SPDX, et CRACI soumet les notifications CRA en votre nom.

Aucun outil de cette page ne rend à lui seul un fabricant conforme. Voir ce qu'exige le CRA et le comparatif des outils de conformité au CRA.

Quand rester avec Cybellum

• Une grande partie de votre firmware vous parvient de vos fournisseurs sous forme de binaires, et vous devez voir à l'intérieur.
• Vous voulez fusionner binaires, code source et SBOM fournisseurs en une SBOM validée par produit et par version.
• Votre PSIRT mène ses investigations dans un espace de travail unique et partage les statuts sous forme de rapports VEX ou CSAF.
• Vous vous appuyez sur des modèles pour la FDA PMA, l'ISO 21434 ou le CRA européen, ou devez fonctionner dans votre propre datacenter.

Pour en savoir plus, consultez CRACI pour les équipes PSIRT, le comparatif des outils de sécurité embarquée et les alternatives à Finite State.

Alternatives à Cybellum : FAQ

Des réponses courtes aux questions que se posent les équipes lorsqu'elles comparent

Quelle est la meilleure alternative à Cybellum ?

Tout dépend de ce dont votre PSIRT a le plus besoin. Pour l'analyse de binaires de firmware, regardez ONEKEY, Finite State ou NetRise. Pour un système de référence des SBOM couvrant produits et fournisseurs, regardez Cybeats. Pour les dispositifs médicaux et les soumissions à la FDA, regardez Medcrypt. Pour la réception des avis et le traitement des dossiers sur une base open source de gestion des vulnérabilités, regardez DefectDojo et son PSIRT Advisory Engine. Pour une protection sur l'appareil également, regardez Exein. Si vous construisez vos propres logiciels dans GitHub Actions, CRACI enregistre la SBOM de chaque build et la surveille pour détecter les vulnérabilités.

CRACI peut-il analyser des binaires de firmware comme Cybellum ?

Non. CRACI n'analyse pas les binaires ni les images de firmware, et il ne recherche pas de zero-days. Il enregistre ce que vos propres builds récupèrent pendant leur exécution sur les runners GitHub Actions de CRACI, builds Yocto compris, et produit la SBOM à partir de cet enregistrement. Pour un firmware que vous recevez sous forme de binaire, vous pouvez ajouter la SBOM du fournisseur à CRACI afin que ses composants soient surveillés, mais sans SBOM il vous faut un outil d'analyse de binaires.

Lequel de ces outils indique à un PSIRT quels produits une nouvelle CVE affecte ?

La plupart d'entre eux, à partir de données différentes. Cybellum, ONEKEY, Finite State et NetRise partent de l'analyse des binaires que vous livrez. Cybeats, Medcrypt Helm et DefectDojo s'appuient sur les SBOM que vous leur fournissez. CRACI part d'un enregistrement de ce que chaque build a récupéré : l'historique des builds montre quels builds contenaient une dépendance vulnérable, directe ou transitive, et sa vue d'inventaire montre quelles versions logicielles sont déployées dans quels produits.

Existe-t-il une alternative gratuite à Cybellum ?

La Community Edition de DefectDojo est gratuite et open source, et elle agrège et dédoublonne les résultats d'autres scanners. Son PSIRT Advisory Engine, qui confronte les avis à vos données SBOM et les regroupe en dossiers, fait partie de DefectDojo Pro. Aucune des deux éditions n'analyse les binaires de firmware.

Une SBOM générée au build vaut-elle mieux qu'une SBOM issue de l'analyse de binaires ?

Pour les logiciels que vous construisez, une SBOM générée au build enregistre ce qui y est entré au lieu de le déduire du résultat, ce qui est difficile pour du code compilé comme le Rust et le C. L'analyse de binaires reste la seule option pour le firmware que vous n'avez pas construit. Lors d'un build core-image-sato comparé côte à côte, la SBOM de CRACI contenait chaque composant de la SBOM propre à Yocto, plus 88 que celle-ci avait manqués, ainsi qu'une package URL pour chacune des 653 versions de crates Rust que Yocto liste sans en avoir.