CRACI vs NetRise

En bref

NetRise est une entreprise d'analyse binaire. Son produit Turbine analyse les firmwares, les images de conteneur et les binaires applicatifs pour produire une SBOM à partir du code compilé et y détecter les risques, notamment les vulnérabilités, les secrets exposés, les erreurs de configuration et la cryptographie. Dragos a annoncé le 21 septembre 2026 avoir acquis NetRise. CRACI est un runner GitHub Actions qui enregistre ce que chaque build récupère pendant son exécution, produit la SBOM à partir de cet enregistrement et la surveille après la release. NetRise analyse le résultat, y compris les logiciels que vous n'avez pas construits ; CRACI conserve les preuves des builds que vous exécutez. Pour un PSIRT, les deux couvrent des terrains différents.

En un coup d'œil

Ce que NetRise fait bien

Des SBOM issues du code compilé. NetRise Turbine produit « a complete, binary-derived SBOM from the software itself », y compris les dépendances liées statiquement et embarquées. Il couvre les firmwares, les images de conteneur et les binaires applicatifs, jusqu'aux noyaux, RTOS, pilotes et firmwares situés sous la couche applicative. C'est le moyen de voir à l'intérieur des logiciels de fondeurs, de fournisseurs de modules et d'autres éditeurs dont vous ne voyez jamais les builds.

Des risques qu'un scan de CVE ne montre pas. Turbine signale les secrets, les clés publiques et privées, les certificats et les erreurs de configuration livrés dans l'artefact, ainsi que les problèmes de licence et un inventaire cryptographique pour la préparation post-quantique. NetRise ZeroLens recherche les faiblesses des logiciels compilés avant qu'elles ne soient exploitées.

La priorisation. Turbine vérifie si un chemin d'exécution traçable relie un point d'entrée actif à un composant vulnérable, et affiche des signaux d'exploitabilité tels que le statut CISA KEV. NetRise indique que la plateforme scanne en continu la NVD, le catalogue CISA KEV, les groupes d'acteurs malveillants et les botnets pour éclairer l'exploitabilité.

Les SBOM des fournisseurs et les intégrations. NetRise prend en charge l'import, l'enrichissement, la normalisation et l'export de SPDX et CycloneDX, ce qui permet de combiner des SBOM de plusieurs sources. Il propose une API GraphQL pour la CI/CD et cite des intégrations avec Jira, ServiceNow, Splunk, Armis, Brinqa, Nucleus Security, GitHub et Google Cloud.

La provenance de l'open source. NetRise Provenance examine l'origine, les mainteneurs et la santé des dépôts des composants open source, et bloque les paquets malveillants ou contraires à la politique là où les développeurs les récupèrent, y compris dans la CI/CD et les assistants de code IA.

Désormais chez Dragos. L'annonce de Dragos indique que NetRise apporte de la visibilité sur les firmwares et les logiciels exécutés sur les appareils de technologie opérationnelle, et que la direction de NetRise l'intégrera à la Dragos Platform tout en continuant de servir les clients existants. Aucune condition financière n'a été communiquée.

Ce qui distingue CRACI

Une analyse binaire remonte à partir de ce qui a été livré. CRACI part du build, car le build s'exécute sur CRACI.

Le build est la source de vérité

Votre workflow s'exécute sur les runners de CRACI grâce à une modification d'une seule ligne, celle de runs-on. Pendant l'exécution d'un job, un proxy qui comprend les paquets enregistre ce qu'il télécharge depuis les sources de paquets, et les paquets restaurés depuis les caches CI sont reportés. Chaque SBOM indique son niveau de complétude, par job et par cache : Complete, Complete with connections, Incomplete, Unavailable ou Not recorded. Pour Yocto, CRACI exécute BitBake sur des runners allant jusqu'à 32 vCPU et 96 GB de RAM. Dans un build comparatif de core-image-sato, la SBOM de CRACI contenait tous les composants de la sortie SPDX de Yocto, 88 de plus tels que des paquets de l'hôte et des GitHub Actions, et une package URL pour chacune des 653 versions de crates Rust que Yocto liste sans en donner.

Le contrôle de ce que le build peut atteindre

Une politique de trafic sortant au niveau du runner décide à quels hôtes un job peut se connecter. Elle est validée avant le démarrage du job, bloque tout en cas d'échec et envoie une alerte en cas de violation. Un scan du résultat ne peut pas changer ce que le build a pu atteindre.

D'une CVE aux produits concernés

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 à mesure que paraissent les avis de sécurité. L'historique des builds montre quels builds contenaient une dépendance vulnérable, directe ou transitive : vous connaissez ainsi la période pendant laquelle vous étiez concerné, et la vue d'inventaire montre précisément quelles versions logicielles sont déployées dans quels produits. Les équipes sécurité trient les résultats et envoient chacun à l'équipe chargée de la correction, VEX est pris en charge, et des policy gates peuvent bloquer un build qui contient une CVE précise. L'API renvoie les SBOM, les traces réseau et la provenance.

Ce que CRACI ne fait pas compte tout autant. Il n'analyse pas les binaires : il ne peut donc pas voir à l'intérieur d'un firmware que vous n'avez pas construit ni d'un blob fournisseur que votre build télécharge, seulement constater que le build l'a récupéré et d'où. Vous pouvez ajouter les SBOM des fournisseurs pour que leurs composants soient surveillés, mais sans SBOM, il vous faut un outil d'analyse binaire tel que NetRise. CRACI ne propose pas d'analyse d'atteignabilité et ne recherche ni secrets ni erreurs de configuration dans le résultat.

Ce qu'un PSIRT attend de chacun

Une équipe de réponse aux incidents de sécurité produit doit savoir ce qui est livré dans chaque produit, firmwares tiers compris, trouver les produits concernés lorsqu'une vulnérabilité apparaît, continuer de surveiller après la release, trier les résultats et indiquer quels produits ne sont pas concernés, souvent avec VEX.

• Les firmwares et binaires tiers que vous recevez. NetRise. L'analyse binaire est le seul moyen de voir à l'intérieur lorsque le fournisseur n'envoie pas de SBOM.
• Les firmwares et logiciels que vous construisez dans GitHub Actions. CRACI enregistre chaque build pendant son exécution et conserve l'historique des builds qui contenaient un composant.
• Prioriser une longue liste de résultats. Les signaux d'atteignabilité et d'exploitabilité de NetRise. CRACI montre qu'un paquet vulnérable était dans le build, pas si votre code l'appelle.
• Envoyer un résultat à l'équipe chargée de la correction. Le tri et le routage de CRACI portent sur les builds qu'il enregistre ; NetRise se connecte à Jira et ServiceNow.

Voir CRACI pour les équipes PSIRT et le comparatif des outils PSIRT.

Quand utiliser l'un, l'autre, ou les deux

• L'essentiel de ce que vous livrez vient de fournisseurs. NetRise. Il analyse les logiciels que vous achetez comme ceux que vous construisez.
• Vous construisez votre propre image Linux ou vos applications dans GitHub Actions. CRACI exécute le build et enregistre ses entrées. Analyser la même image dans NetRise donne une seconde vue, indépendante, de ce qui a été livré.
• Vous exploitez des parcs de technologie opérationnelle. NetRise, désormais au sein de Dragos, vise les firmwares et logiciels exécutés sur ces appareils. CRACI s'adresse aux équipes qui construisent le logiciel.
• Vous voulez limiter ce que les builds peuvent télécharger. CRACI. Ce contrôle n'existe que là où le build s'exécute.

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 d'assistance et, depuis le 11 septembre 2026, de signaler les vulnérabilités activement exploitées. NetRise répond au CRA avec des SBOM de builds de release issues de l'artefact compilé, la gestion des vulnérabilités et la vérification des correctifs d'une version à l'autre, et des sorties de reporting pour les preuves de conformité. CRACI produit, pour chaque build, des preuves de ce qui est entré dans les logiciels que vous construisez, les surveille et soumet les notifications CRA en votre nom. 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 en complément de NetRise

Inutile de retirer quoi que ce soit de NetRise. Faites passer le job de build sur un runner CRACI en indiquant runs-on: craci, et le même workflow continue de s'exécuter dans GitHub Actions pendant que CRACI enregistre le build. L'exemple Yocto de la documentation CRACI présente un workflow BitBake complet. 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.

Vous comparez plus de deux outils ? Alternatives à NetRise compare sept options côte à côte.