Les outils PSIRT comparés

En bref

• Firmware reçu de fournisseurs sous forme de binaires : ONEKEY, Finite State, NetRise ou Cybellum. L'analyse binaire est le moyen de voir à l'intérieur d'un code dont vous n'exécutez jamais le build.
• Dispositifs automobiles, médicaux ou industriels avec modèles réglementaires : Cybellum, avec des modèles pour FDA PMA, ISO 21434 et le CRA de l'UE.
• Dispositifs médicaux et soumissions à la FDA : Medcrypt, avec Helm pour les SBOM et les vulnérabilités.
• De nombreux scanners dans une seule file, avec un workflow d'avis PSIRT : DefectDojo, open source avec une édition Pro.
• Un système de référence pour les SBOM de nombreux fournisseurs : Cybeats SBOM Studio.
• Images Yocto ou Buildroot avec des données CVE sélectionnées : Timesys Vigiles.
• Une protection sur l'appareil également : Exein.
• Un espace gratuit et auto-hébergé pour surveiller les SBOM : OWASP Dependency-Track.
• Les logiciels que vous construisez dans GitHub Actions : CRACI, qui enregistre la SBOM de chaque build, conserve chaque build passé et surveille ce qui a été livré.

À qui s'adresse cette page

Vous dirigez ou mettez en place une fonction de sécurité produit, et vous choisissez les outils qui la soutiennent. Si vous définissez encore le rôle, commencez par ce que fait un PSIRT. Nous développons CRACI : tenez-en compte. Chaque affirmation sur un autre produit provient de son site ou de sa documentation, consultés en octobre 2026, et la plupart des éditeurs présentés ici disposent d'une page CRACI vs X plus détaillée.

Ce qu'un outil PSIRT doit faire

Le travail suit le cycle de vie de la gestion des vulnérabilités, et un PSIRT a besoin d'aide à chaque étape :

1. Savoir ce qui est livré. Une SBOM par version de produit, y compris les dépendances transitives et les composants de fournisseurs. Tout le reste dépend de sa complétude.
2. Repérer les nouvelles vulnérabilités. Une surveillance continue qui rapproche les nouveaux avis de chaque version publiée, pas seulement de la prochaine.
3. Trouver les produits concernés. Quels produits, versions et builds contiennent le composant, et depuis combien de temps.
4. Trier et attribuer. Décider de ce qui compte et l'envoyer à l'équipe chargée de la correction.
5. Dire ce qui n'est pas concerné. VEX enregistre quels produits une vulnérabilité touche et pourquoi les autres ne sont pas concernés.
6. Recevoir les signalements et informer. Un canal pour les chercheurs extérieurs, un suivi des dossiers et des avis de sécurité, souvent au format lisible par machine CSAF.

Aucun outil ci-dessous ne couvre les six étapes de la même façon. La plupart sont les plus solides sur les deux ou trois premières, et ils diffèrent surtout par l'origine de leur inventaire.

Comment choisir

• Construisez-vous le logiciel, ou le recevez-vous ? Si une grande partie du produit arrive de fondeurs et de fournisseurs sous forme de binaires, l'analyse binaire est le moyen de voir à l'intérieur. Si vous le construisez vous-même, le build est la source la plus directe de l'inventaire.
• Le produit est-il réglementé ? Les dispositifs médicaux, les véhicules et les équipements industriels s'accompagnent de formats de soumission et de normes. Certains outils fournissent des modèles pour cela ; d'autres le laissent à votre propre processus.
• Combien de scanners utilisez-vous déjà ? Si les résultats proviennent de nombreux outils, un agrégateur qui les dédoublonne peut compter davantage qu'une source de résultats supplémentaire.
• Par où arrivent les signalements extérieurs ? Les soumissions de chercheurs nécessitent généralement leur propre canal (voir ci-dessous), quel que soit l'outil d'inventaire choisi.
• Doit-il être auto-hébergé ? DefectDojo, Dependency-Track et Medcrypt Enterprise peuvent fonctionner sur votre propre infrastructure, et Cybellum dans votre propre datacenter.

En un coup d'œil

Deux tableaux : d'abord les outils conçus autour du firmware et des appareils, puis les plateformes de gestion des vulnérabilités et de SBOM. « Non précisé » signifie que les pages des éditeurs que nous citons ne se prononcent pas. La réception des signalements, la gestion des dossiers et la publication d'avis sont traitées dans le texte ci-dessous plutôt que dans les tableaux.

Firmware et appareils

Plateformes de gestion des vulnérabilités et de SBOM

CRACI

CRACI est un runner GitHub Actions. Vous définissez runs-on sur craci et, pendant l'exécution de chaque job, un proxy qui comprend les paquets enregistre ce qu'il récupère, y compris les paquets restaurés depuis les caches CI et les dépendances qu'aucun lockfile ne liste. La SBOM, en CycloneDX ou SPDX, porte un état de complétude par job et par cache. CRACI conserve chaque build passé avec sa SBOM : lorsqu'un avis de sécurité paraît, vous voyez quels builds contenaient la dépendance vulnérable, directe ou transitive, et pendant combien de temps, dans la limite de votre durée de conservation. Sa vue d'inventaire montre précisément quelles versions logicielles sont déployées dans quels produits, à l'échelle mondiale.

Après le build, CRACI réévalue en continu les SBOM surveillées, permet aux équipes sécurité de trier les résultats et d'envoyer chacun à l'équipe chargée de la correction, et prend en charge VEX. Les policy gates peuvent bloquer un build qui contient une CVE précise, et une politique de trafic sortant limite ce que le build peut atteindre. Vous pouvez ajouter des SBOM de fournisseurs : les composants achetés sont ainsi surveillés aux côtés de vos propres builds. Pour les vulnérabilités activement exploitées, CRACI soumet en votre nom les notifications prévues par le CRA. Pour Yocto, un build comparatif de core-image-sato a donné une SBOM comportant tous les composants de la SBOM de Yocto, plus 88 qu'elle avait omis. Le tarif ne porte que sur les minutes de build : $0.004 par minute pour 2 vCPU, décompté à la seconde, sans abonnement mensuel ni frais par SBOM. Idéal pour : les PSIRT dont les produits sont construits dans GitHub Actions. Attention : il n'analyse pas les binaires, si bien que le firmware que vous n'avez pas construit nécessite une SBOM de l'éditeur ou un outil d'analyse binaire ; il n'a ni analyse d'atteignabilité ni export de rapport ; et il prend en charge GitHub Actions aujourd'hui, GitLab CI et Jenkins figurant sur la roadmap. Consultez CRACI pour les équipes PSIRT.

Plateformes pour le firmware et les appareils

Cybellum

Cybellum est une plateforme de sécurité produit pour les fabricants d'appareils des marchés automobile, médical et industriel, détenue majoritairement par LG Electronics depuis 2021. Ses Cyber Digital Twins sont construits à partir de binaires de firmware, et elle les fusionne avec le code source et les SBOM de fournisseurs en SPDX, CycloneDX ou CPE CSV. Elle surveille les versions post-production, trie avec un assistant IA, le VM CoPilot, propose un espace de travail pour créer et gérer des investigations avec des tickets, et partage l'état des vulnérabilités via des rapports VEX et CSAF. Ses modèles réglementaires couvrent FDA PMA, ISO 21434, le CRA de l'UE et plus de 50 normes. Elle fonctionne dans des clouds publics ou dans votre propre datacenter. Idéal pour : les fabricants d'appareils qui veulent l'analyse binaire et les preuves réglementaires sur une seule plateforme. Attention : le tarif n'est pas publié, et elle travaille à partir d'artefacts au lieu d'exécuter votre build. CRACI vs Cybellum et Alternatives à Cybellum

ONEKEY

ONEKEY analyse le firmware compilé sans avoir besoin du code source ni d'un accès réseau. Il génère une SBOM à partir du binaire, importe les SBOM de fournisseurs, recherche de probables zero-days tels que des identifiants codés en dur et réanalyse le firmware chaque jour. Son Compliance Wizard guide les équipes à travers le CRA, IEC 62443-4-2, ETSI EN 303 645 et la Radio Equipment Directive. Idéal pour : les équipes qui intègrent beaucoup de firmware de fournisseurs. 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 le firmware, les binaires, le code source et les SBOM de fournisseurs, avec la prise en charge de plus de 50 architectures de jeux d'instructions binaires, et les réunit dans un seul registre des logiciels livrés, avec une surveillance après mise sur le marché. Il classe les résultats selon l'atteignabilité et le renseignement sur les exploits, enregistre les décisions VEX et met les contrôles en correspondance avec les exigences du CRA et de la FDA. Idéal pour : les PSIRT qui doivent prioriser une longue liste de résultats issus de nombreux fournisseurs. Attention : il part d'artefacts : contrôler ce que votre propre build pouvait atteindre sort donc de son périmètre. CRACI vs Finite State et Alternatives à Finite State

NetRise

NetRise Turbine produit une SBOM complète, dérivée du binaire, à partir du logiciel lui-même, y compris le code lié statiquement et embarqué, pour les logiciels que vous construisez, achetez et exploitez. Il importe des SBOM SPDX et CycloneDX, vérifie en continu la NVD, CISA KEV et les données sur les acteurs de la menace, classe les résultats selon l'atteignabilité des chemins d'exécution, signale les secrets, les clés et les erreurs de configuration à l'intérieur de l'artefact, et se connecte à Jira et ServiceNow. Dragos a annoncé le 21 septembre 2026 avoir acquis NetRise. Idéal pour : les technologies opérationnelles et les parcs d'appareils dont les logiciels proviennent de nombreux éditeurs. Attention : ses pages ne décrivent ni VEX, ni la gestion de dossiers, ni la publication d'avis, et le tarif n'est pas publié. CRACI vs NetRise et Alternatives à NetRise

Exein

Exein agit sur l'appareil comme avant la release. Exein Runtime utilise eBPF pour surveiller et bloquer les comportements malveillants sur Linux embarqué, et la couche Yocto open source meta-exein place son agent Pulsar dans votre image. Exein Analyzer scanne le firmware, ou votre SBOM lorsque le binaire n'est pas disponible, priorise avec un score d'atteignabilité et met les résultats en correspondance avec les exigences du CRA. Idéal pour : les produits Linux embarqués qui ont besoin d'une protection sur le terrain. Attention : la couche Yocto change ce qui s'exécute sur l'appareil ; elle n'exécute ni n'enregistre votre build. CRACI vs Exein

Timesys Vigiles

Vigiles, désormais vendu par Lynx Software Technologies, transforme les métadonnées d'un build Yocto, Buildroot ou OpenWrt en SBOM et les rapproche d'une base de données CVE sélectionnée. Des filtres de configuration du noyau et d'U-Boot retirent les CVE de fonctionnalités que vous ne construisez pas, les décisions de tri (concerné, corrigé, différé, non exploitable) sont conservées par release, les entrées CISA KEV sont mises en évidence, et il exporte des SBOM, du VEX et des rapports de vulnérabilités. Idéal pour : les équipes Linux embarqué qui veulent moins de bruit sur les CVE. Attention : sa SBOM reflète ce que les métadonnées de BitBake disent entrer dans l'image, pas tout ce que le build a récupéré. CRACI vs Timesys Vigiles

Plateformes de gestion des vulnérabilités et de SBOM

DefectDojo

DefectDojo est un projet OWASP Flagship avec une édition commerciale Pro. La Community Edition gratuite dédoublonne les résultats des scanners que vous utilisez déjà, plus de 500 outils pris en charge selon son propre décompte, dans une seule file avec responsables, SLA et tickets Jira. Pro ajoute l'import de SBOM en CycloneDX et SPDX, l'export CycloneDX VEX et un PSIRT Advisory Engine qui reçoit les avis de plus de 20 flux, les rapproche des données SBOM, les regroupe en dossiers avec responsables et publie des avis PDF à votre marque. Sa version de septembre 2026 a ajouté l'export d'avis CSAF 2.0 et VEX et une interface de signalement au titre de l'article 14 du CRA. Pro commence à $100 par mois plus $0.15 par résultat traité. Idéal pour : les PSIRT qui veulent une base open source et un workflow d'avis. Attention : il ne génère pas lui-même de SBOM : l'inventaire n'est donc complet que dans la mesure de ce que vous téléversez. CRACI vs DefectDojo et Alternatives à DefectDojo

Medcrypt

Medcrypt aide les fabricants de dispositifs médicaux à faire accepter leur dossier de cybersécurité par la FDA, avec une équipe qui compte d'anciens examinateurs de la FDA. Son produit Helm importe des SBOM CycloneDX ou SPDX par API, GitHub Action ou Azure DevOps, les surveille en continu, classe les résultats avec EPSS, CISA KEV et des données d'exploitation, et exporte des rapports CycloneDX VEX et VDR. MSI, qui inclut Helm, coûte $35,000 par gamme de produits et par an, et son adhésion MedISAO apporte un programme de divulgation coordonnée des vulnérabilités. Idéal pour : les fabricants de dispositifs médicaux qui préparent ou maintiennent des soumissions à la FDA. Attention : il ingère des SBOM plutôt qu'il n'en produit (un outil de génération est disponible sur demande), et sa page de tarifs indique que la FDA est ce que la plateforme couvre aujourd'hui. CRACI vs Medcrypt

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, évalue leur qualité avant l'import, rapproche en continu chaque composant du renseignement sur les vulnérabilités, émet du VEX et partage les SBOM avec les clients, y compris via la Transparency Exchange API. Idéal pour : les équipes de sécurité produit des ICS, des dispositifs médicaux, des télécoms et de l'automobile qui mènent un programme SBOM avec de nombreux fournisseurs. Attention : pour la génération, il renvoie vers les éditeurs de sa Marketplace : la SBOM elle-même vient donc d'un autre outil. CRACI vs Cybeats et Alternatives à Cybeats

L'option open source : Dependency-Track

OWASP Dependency-Track est une plateforme Apache 2.0 qui suit les composants de chaque version de chaque application, récupère les données de vulnérabilité de sources telles que la NVD et les GitHub Advisories, applique des politiques de sécurité, de licences et opérationnelles, et consomme et produit du CycloneDX VEX. Les pipelines téléversent les SBOM via son API. Il est gratuit, et vous l'hébergez et l'exploitez vous-même. Idéal pour : les équipes qui veulent une plateforme d'analyse transparente et auto-hébergée. Attention : il ne génère pas de SBOM : ses résultats dépendent donc du générateur que vous exécutez en amont. CRACI vs Dependency-Track et Alternatives à Dependency-Track

Réception des signalements, dossiers et avis

Les tableaux ci-dessus s'arrêtent au tri et à VEX. Le reste du travail d'un PSIRT, recevoir les signalements et informer, est couvert de façon inégale :

• Signalements de chercheurs extérieurs. Ils arrivent généralement via un programme de divulgation des vulnérabilités. De nombreuses entreprises en gèrent un sur une plateforme telle que HackerOne Response ou Bugcrowd VDP, qui offrent aux chercheurs un canal pour soumettre leurs signalements et aident à les trier. D'autres publient elles-mêmes une politique et un contact de sécurité. Notre guide de la divulgation coordonnée des vulnérabilités couvre la politique, security.txt et les délais.
• Gestion des dossiers. Cybellum dispose d'un espace de travail pour les investigations avec des tickets. DefectDojo Pro regroupe les avis rapprochés en dossiers avec responsables et suivi des SLA. Ni l'un ni l'autre n'indique héberger les soumissions de chercheurs.
• Avis de sécurité. DefectDojo Pro publie des avis PDF à votre marque et exporte du CSAF 2.0. Cybellum partage l'état des vulnérabilités via des rapports VEX et CSAF. L'adhésion MedISAO de Medcrypt inclut un programme de divulgation coordonnée des vulnérabilités.

La place de CRACI

La première question de tout dossier PSIRT est de savoir quels produits et quelles versions contiennent le composant vulnérable. L'analyse binaire y répond à partir de ce qui a été livré, les plateformes SBOM à partir des SBOM que vous leur fournissez, et les agrégateurs à partir de ce que signalent d'autres scanners. CRACI y répond à partir d'un enregistrement de ce que vos propres builds ont réellement récupéré, conservé pour chaque build passé. Pour les logiciels que vous construisez dans GitHub Actions, cela couvre l'inventaire, la surveillance, le tri et VEX dans un seul produit : un gestionnaire de SBOM distinct tel que Dependency-Track ou Cybeats n'est donc pas nécessaire pour ces builds.

D'autres outils l'emportent ailleurs. L'analyse binaire de Cybellum, ONEKEY, Finite State ou NetRise voit à l'intérieur du firmware que vous n'avez pas construit. Cybellum et Medcrypt apportent des modèles réglementaires et une expertise des soumissions. DefectDojo agrège les résultats de centaines de scanners et publie des avis. Finite State, NetRise et Exein classent les résultats par atteignabilité, ce que CRACI ne propose pas. Lisez ce que fait un PSIRT et CRACI pour les équipes PSIRT, ou comparez les outils de conformité au CRA et les outils SBOM.

Outils PSIRT : questions fréquentes

Qu'est-ce qu'un outil PSIRT ?

Un logiciel qui aide une équipe de réponse aux incidents de sécurité produit à faire son travail : savoir quels composants sont livrés dans chaque version de produit, repérer lorsqu'une nouvelle vulnérabilité les touche, la trier, attribuer la correction, enregistrer quels produits ne sont pas concernés, et informer les clients et les autorités. Peu de produits couvrent tout cela. La plupart des PSIRT associent un outil d'inventaire et de surveillance à un canal pour les signalements extérieurs et à un moyen de publier des avis de sécurité.

Quel outil PSIRT convient le mieux au firmware reçu sous forme de binaires ?

Un outil d'analyse binaire. Cybellum, ONEKEY, Finite State et NetRise construisent une SBOM à partir du firmware compilé lui-même : ils peuvent donc voir à l'intérieur du code de fournisseurs dont vous n'exécutez jamais le build. Exein Analyzer scanne aussi le firmware avant la release. CRACI n'analyse pas les binaires ; pour le firmware de fournisseurs, il peut surveiller la SBOM de l'éditeur si celui-ci en fournit une.

Quel outil PSIRT convient aux logiciels que nous construisons nous-mêmes ?

Si vos builds s'exécutent dans GitHub Actions, CRACI enregistre la SBOM de chaque build pendant son exécution, conserve chaque build passé avec sa SBOM, réévalue les SBOM surveillées à mesure que paraissent les avis de sécurité, et montre quels builds contenaient une dépendance vulnérable et quelles versions logicielles sont déployées dans quels produits. GitLab CI et Jenkins figurent sur sa roadmap. Pour les images Yocto, Timesys Vigiles construit une SBOM à partir des métadonnées BitBake au lieu d'enregistrer le build.

Existe-t-il un outil PSIRT gratuit ou open source ?

Deux des outils présentés ici ont des éditions gratuites. DefectDojo Community Edition est gratuit sous licence BSD 3-Clause et dédoublonne les résultats de centaines de scanners dans une seule file ; son PSIRT Advisory Engine, l'import de SBOM et l'export CSAF font partie de DefectDojo Pro. OWASP Dependency-Track est gratuit sous Apache 2.0 et surveille les SBOM que vous téléversez. Vous hébergez et exploitez les deux vous-même.

Les outils PSIRT reçoivent-ils les signalements de chercheurs extérieurs ?

Les signalements de chercheurs arrivent généralement via un programme de divulgation des vulnérabilités, souvent géré sur une plateforme telle que HackerOne ou Bugcrowd, ou via un contact de sécurité publié. DefectDojo Pro reçoit des avis issus de flux publics, et Cybellum propose un espace de travail pour les investigations, mais ni l'un ni l'autre n'indique héberger les soumissions de chercheurs.

Quels outils publient des avis CSAF ?

DefectDojo Pro a ajouté en septembre 2026 l'export d'avis CSAF 2.0 et VEX, et publie des avis PDF à votre marque. Cybellum partage l'état des vulnérabilités via des rapports VEX et CSAF. Les autres éditeurs de cette page ne décrivent pas de publication d'avis CSAF sur les pages que nous citons.

Le CRA impose-t-il un outil PSIRT ?

Aucun outil n'est imposé. Le Cyber Resilience Act demande aux fabricants de traiter les vulnérabilités pendant la période d'assistance, de tenir une politique de divulgation coordonnée des vulnérabilités et un contact pour les signalements et, depuis le 11 septembre 2026, de signaler les vulnérabilités activement exploitées dans les délais de 24 heures, 72 heures et 14 jours. CRACI soumet ces notifications au nom du fabricant, et DefectDojo Pro dispose d'une interface de signalement au titre de l'article 14 du CRA. L'obligation reste celle du fabricant.