Alternatives à NetRise

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 NetRise

NetRise Turbine produit une SBOM complète issue du logiciel lui-même et dérivée du binaire pour les firmwares, les images de conteneur et les binaires d'application, y compris les dépendances liées statiquement et embarquées. Il signale les secrets, les clés, les certificats, les erreurs de configuration et les problèmes de licence présents dans l'artefact, classe les vulnérabilités selon qu'un chemin d'exécution les atteint ou non, et importe et exporte SPDX et CycloneDX. NetRise Provenance vérifie l'origine et la santé des composants open source, et ZeroLens recherche les faiblesses dans les logiciels compilés. Le 21 septembre 2026, Dragos a annoncé avoir acquis NetRise et prévoit de l'intégrer à la Dragos Platform.

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

• L'acquisition. Dragos intègre NetRise à sa plateforme destinée aux opérateurs d'infrastructures critiques. Les fabricants d'appareils hors de ce marché peuvent préférer un éditeur dont la roadmap leur est destinée.
• L'essentiel du logiciel est le leur. Analyser un binaire revient à remonter depuis la sortie. Une équipe qui construit ses propres images peut plutôt enregistrer ce qui y est entré.
• Un workflow PSIRT. Le site de NetRise ne décrit ni VEX, ni avis de sécurité, ni investigations PSIRT. Certaines équipes veulent les trouver dans le même outil que l'analyse.
• Tarifs. NetRise ne publie aucun prix.

Ce qu'un PSIRT doit examiner

Un PSIRT répond de chaque produit que l'entreprise livre. L'outil qui le soutient doit l'aider sur les points suivants :

• Un inventaire de ce qui est livré, y compris le firmware tiers que vous n'avez jamais construit.
• La façon dont la SBOM est produite, et si l'outil vous indique quand elle est incomplète.
• Trouver rapidement les produits et les releases affectés lorsqu'une vulnérabilité apparaît.
• La surveillance après la release, à mesure que de nouveaux avis de sécurité paraissent pour des composants déjà livrés.
• Le tri, la priorisation et VEX, pour pouvoir dire quels produits ne sont pas affectés.
• La couverture CI, les options d'hébergement et la façon dont le prix évolue.

Les options

1. CRACI (notre produit)

CRACI est un runner GitHub Actions qui produit la SBOM pendant que le build s'exécute. Il s'adresse aux équipes qui construisent leur propre firmware et leurs propres logiciels. Un proxy qui comprend les paquets enregistre ce que chaque job récupère depuis les hôtes de paquets et de sources, 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 : dans un build de core-image-sato comparé côte à côte, la SBOM de CRACI contenait tous les composants de la SBOM de Yocto, plus 88 qu'elle avait manqués, comme des paquets de l'hôte et des GitHub Actions, et un package URL pour chacune des 653 versions de crates Rust que Yocto liste sans en avoir.

CRACI réévalue en continu les SBOM surveillées, montre quels builds contenaient une dépendance vulnérable et quelles versions logicielles sont déployées sur quels produits, prend en charge VEX et permet aux équipes de sécurité de trier les résultats et d'envoyer chacun à l'équipe responsable du correctif. Vous pouvez ajouter des SBOM de fournisseurs, afin que les composants achetés soient surveillés à côté 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 d'appareils et les équipes logicielles qui construisent sur GitHub Actions et veulent le build, la SBOM et le suivi des vulnérabilités au même endroit. À envisager si : vous pouvez vous passer de l'analyse de binaires, de l'atteignabilité et de la détection de secrets dans la sortie, que CRACI ne propose pas ; il ne peut pas voir à l'intérieur d'un firmware que vous n'avez pas construit. Il ne prend en charge que GitHub Actions, avec GitLab CI et Jenkins sur la roadmap. Consultez CRACI pour les équipes PSIRT et CRACI face à NetRise.

2. ONEKEY

ONEKEY analyse le firmware compilé sans avoir besoin de code source ni d'accès réseau. Il génère une SBOM à partir du binaire, importe les SBOM des fournisseurs, exporte en CycloneDX et SPDX, recherche des zero-days probables 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 contrôles guidés par rapport aux normes. À envisager si : vous voulez des résultats au-delà des CVE connues auprès d'un éditeur centré sur les produits connectés. CRACI face à ONEKEY

3. Finite State

Finite State analyse les firmwares, les binaires, le code source et les SBOM des fournisseurs, prend en charge plus de 50 architectures de jeux d'instructions binaires et réunit le tout dans une seule fiche produit. Il classe les résultats selon l'atteignabilité, les renseignements sur les exploits et le contexte produit, enregistre les décisions VEX, et son workflow de conformité couvre la cartographie des contrôles CRA et des rapports prêts pour l'audit avec des artefacts SBOM et VEX. Il intègre des contrôles dans GitHub Actions, GitLab CI et Jenkins.

Idéal pour : les fabricants d'appareils connectés qui doivent analyser le firmware de nombreux fournisseurs, avec les décisions VEX au même endroit. À envisager si : vous voulez une seule plateforme pour les sources, les binaires et les SBOM des fournisseurs. CRACI face à Finite State

4. Cybellum

La Product Security Platform de Cybellum crée des SBOM en combinant les données de scanners de binaires, le code source et des sources de SBOM externes aux formats SPDX, CycloneDX ou CSV de CPE. Sa gestion des vulnérabilités trie et priorise les résultats, et elle peut créer des rapports VEX. Pour le travail PSIRT, elle trouve les produits ou composants affectés par une nouvelle vulnérabilité, partage l'état des vulnérabilités via des rapports VEX/CSAF et fournit un espace de travail pour créer et gérer des investigations. Elle couvre aussi la conformité aux exigences de la FDA, à l'ISO 21434 et au CRA.

Idéal pour : les fabricants de l'automobile, du médical et de l'industrie qui veulent les SBOM, la gestion des vulnérabilités et les investigations PSIRT sur une seule plateforme. À envisager si : le workflow PSIRT compte plus pour vous qu'un scanner de binaires autonome. Cybellum ne publie aucun prix.

5. ReversingLabs Spectra Assure

Spectra Assure analyse les paquets logiciels compilés sans code source pour y trouver malwares, altérations, secrets exposés et vulnérabilités, et produit des SBOM CycloneDX et SPDX à partir de ce qu'il trouve. L'analyse différentielle compare les versions et signale les changements suspects entre les releases. La CLI rl-secure s'exécute sur site et dans la CI.

Idéal pour : un contrôle de release contre les malwares et les altérations sur le paquet que vous livrez, ou sur un logiciel commercial avant de le déployer. À envisager si : votre cible principale est le firmware d'appareils plutôt que les paquets logiciels. Community est gratuit et Community+ coûte $500 par mois (en septembre 2026). CRACI face à ReversingLabs

6. Exein

Exein agit sur l'appareil et sur le firmware. 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 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 reposant sur des LLM, et les rattache aux exigences du CRA.

Idéal pour : les fabricants de systèmes Linux embarqués 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 face à Exein

7. Cybeats

Cybeats SBOM Studio est un système de référence qui ingère, gère, surveille et partage les SBOM de l'ensemble des produits et des fournisseurs. Il note 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 composition binaire, Cybeats renvoie vers les éditeurs de sa Marketplace, et son module RAVEN raisonne sur l'atteignabilité et rédige des VEX.

Idéal pour : les fabricants des secteurs médical, industriel et télécoms qui mènent un programme SBOM sur de nombreux produits et fournisseurs. À envisager si : vous avez besoin de l'analyse elle-même ; SBOM Studio gère des SBOM générées par un autre outil. CRACI face à Cybeats

Côte à côte

« NetRise » désigne NetRise Turbine, « Cybellum » désigne la Cybellum Product Security Platform, « ReversingLabs » désigne Spectra Assure, et « Cybeats » désigne SBOM Studio. Les tarifs de ReversingLabs datent de septembre 2026. « Non précisé » signifie que la fonctionnalité n'est pas décrite dans la documentation de l'éditeur, et non qu'elle est absente.

Pour le Cyber Resilience Act

NetRise, ONEKEY, Finite State, Cybellum et Exein traitent tous du CRA. Ses obligations de déclaration s'appliquent depuis le 11 septembre 2026, et ses principales dispositions s'appliquent à partir du 11 décembre 2027. Une alerte précoce à 24 heures suppose de savoir rapidement quelles releases contiennent un composant affecté. Pour le logiciel que vous construisez, CRACI conserve l'historique des builds avec la SBOM de chacun, ce qui vous permet de voir 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. Consultez ce qu'exige le CRA et le comparatif des outils PSIRT.

Quand rester sur NetRise

• Vous avez besoin de SBOM pour les firmwares et les binaires que vous achetez comme pour ceux que vous construisez, y compris le code lié statiquement.
• Vous voulez que les secrets, les clés, les certificats et les erreurs de configuration de l'artefact soient signalés à côté des CVE.
• Vous comptez sur l'atteignabilité par chemin d'exécution pour réduire la liste des résultats.
• Vous exploitez des technologies opérationnelles et voulez une visibilité sur le firmware au sein de la Dragos Platform.

Pour en savoir plus, consultez les builds Yocto sur CRACI, les alternatives à ONEKEY et les alternatives à Finite State.

Alternatives à NetRise : FAQ

Des réponses courtes aux questions que se posent les équipes qui comparent

Quelle est la meilleure alternative à NetRise ?

Tout dépend de l'usage que vous en faites. Pour l'analyse de firmware avec des résultats au-delà des CVE connues et des contrôles de conformité guidés, regardez ONEKEY. Pour réunir firmwares, binaires, code source et SBOM de fournisseurs dans une seule fiche produit avec l'atteignabilité, regardez Finite State. Pour les investigations PSIRT et les rapports VEX ou CSAF en plus de l'analyse de binaires, regardez Cybellum. Pour vérifier l'absence de malware et d'altération sur un paquet de release, regardez ReversingLabs Spectra Assure. Pour une protection sur l'appareil, regardez Exein. Pour gérer les SBOM de nombreux fournisseurs, regardez Cybeats. Si vous construisez vos propres logiciels dans GitHub Actions, CRACI enregistre la SBOM de chaque build et la surveille pour y détecter les vulnérabilités.

NetRise est-il toujours vendu après son acquisition par Dragos ?

Dragos a annoncé l'acquisition de NetRise et de runZero le 21 septembre 2026, sans en préciser les conditions financières. Dragos indique que la direction de NetRise l'intégrera à la Dragos Platform tout en continuant à servir les clients existants, et netrise.io présentait toujours Turbine, Provenance et ZeroLens en octobre 2026. Demandez à NetRise ou à Dragos comment il sera vendu à l'avenir.

CRACI peut-il analyser le firmware comme NetRise ?

Non. CRACI n'analyse ni les binaires ni les images de firmware, ne fait pas d'analyse d'atteignabilité et ne recherche ni secrets ni erreurs de configuration dans la sortie. Il enregistre ce que vos propres builds récupèrent pendant qu'ils s'exécutent sur les runners GitHub Actions de CRACI, y compris les builds Yocto, et produit la SBOM à partir de cet enregistrement. Pour un firmware que vous recevez sous forme 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.

Lesquels de ces outils aident un PSIRT à trouver les produits affectés ?

Cybellum décrit un espace de travail PSIRT qui trouve les produits ou composants affectés par une nouvelle vulnérabilité. Finite State et Cybeats tiennent un registre couvrant produits et fournisseurs. CRACI 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 sur quels produits. Les outils d'analyse de binaires tels que NetRise et ONEKEY vous disent ce que contient un firmware que vous n'avez pas construit.

Une SBOM de build est-elle meilleure qu'une SBOM issue de l'analyse de binaires ?

Pour un logiciel que vous construisez, une SBOM de build enregistre ce qui est entré au lieu de le déduire de la sortie, ce qui est difficile pour du code compilé, par exemple en Rust ou en C. L'analyse de binaires reste la seule option pour un firmware que vous n'avez pas construit. Dans un build core-image-sato comparé côte à côte, la SBOM de CRACI contenait tous les composants de la SBOM de Yocto, plus 88 qu'elle avait manqués, et un package URL pour chacune des 653 versions de crates Rust que Yocto liste sans en avoir.