Comparatif
CRACI vs ReversingLabs Spectra Assure
Spectra Assure inspecte le paquet que vous vous apprêtez à livrer. CRACI enregistre le build qui l'a produit. L'un examine le résultat ; l'autre conserve les preuves du processus, et chacun repère ce que l'autre ne peut pas voir.
Mis à jour le
En bref
ReversingLabs Spectra Assure analyse des paquets logiciels compilés, sans code source, pour y trouver des malwares, des altérations, des secrets exposés, des comportements suspects et des vulnérabilités, et produit une SBOM à partir de ce qu'il trouve. CRACI est un runner GitHub Actions qui enregistre ce que chaque build récupère pendant son exécution, contrôle ce que le build peut atteindre et continue de surveiller ce qui a été livré. Spectra Assure est l'examen final du résultat ; CRACI est l'enregistrement du build. Tous deux traitent le risque de la chaîne d'approvisionnement logicielle, par les deux extrémités, et ils se complètent bien.
En un coup d'œil
| Fonctionnalité | CRACI | ReversingLabs |
|---|---|---|
| Enregistre ce que le build a récupéré | Observé par le runner pendant chaque job | Analyse le paquet une fois construit |
| Exécute vos builds CI | Les jobs s'exécutent sur des runners CRACI | Une étape CI scanne l'artefact fini |
| Politique de trafic sortant pendant le build | Vérifiée avant le job, bloque tout en cas d'échec | Hors de son périmètre |
| SBOM en CycloneDX et SPDX | Issue du build, avec un état de complétude | Issue du binaire, plus ML-BOM, CBOM, SaaSBOM |
| Analyse le binaire fini | Analyse binaire statique, sans code source | |
| Détection de malwares | 16 moteurs de détection plus renseignement sur les menaces | |
| Détection des altérations | Données de provenance via l'API ; pas de comparaison de binaires | Analyse différentielle entre versions |
| Fonctionne sur un logiciel que vous n'avez pas construit | Le build doit s'exécuter sur CRACI | Vérifie les logiciels tiers et commerciaux |
| Systèmes CI | GitHub Actions aujourd'hui ; GitLab CI et Jenkins sur la roadmap | GitHub Actions, GitLab CI, Jenkins, Azure DevOps, TeamCity |
| Tarifs | $0.002 par minute vCPU ($0.004 pour 2 vCPU), décompté à la seconde ; sans abonnement mensuel ni frais par SBOM | Community gratuit, Community+ $500 par mois, Essentials et Enterprise sur demande (en septembre 2026). |
- Inclus
- En partie
- Non inclus
Ce que Spectra Assure fait bien
Une analyse approfondie du paquet fini. Spectra Assure utilise l'analyse binaire statique pour traiter des paquets logiciels volumineux et complexes sans code source. Sa prise en charge des types de fichiers couvre plus de 70 formats d'archive, de nombreux types d'installateurs et plus de 200 packers d'exécutables, et chaque fichier reçoit une classification : goodware, suspect, malveillant ou inconnu.
Les malwares et les altérations. C'est le terrain de prédilection de ReversingLabs. Spectra Assure utilise 16 moteurs propriétaires de détection de malwares, adossés à une base de renseignement sur les menaces qui, selon ReversingLabs, couvre 400 milliards de fichiers. L'analyse différentielle intégrée compare les versions et signale les changements suspects et les indicateurs d'altération : c'est ainsi que vous repérez un changement de comportement inattendu dans une release que vous avez construite vous-même.
Des SBOM et plus encore. Le rapport SAFE associe une SBOM à une évaluation des risques. La CLI exporte en CycloneDX 1.6 et SPDX 3.0.1, et ReversingLabs génère aussi des vues ML-BOM, CBOM et SaaSBOM du même paquet.
Les logiciels que vous n'avez pas construits. Comme il fonctionne sur des binaires, Spectra Assure peut évaluer des logiciels commerciaux et tiers avant que vous ne les déployiez, et le Spectra Assure Community gratuit vérifie des paquets open source et des outils de développement largement utilisés.
L'intégration aux pipelines de release. La CLI rl-secure s'exécute sur site et en CI, et un Portal hébergé gère les projets et les versions. Les intégrations officielles couvrent GitHub Actions, GitLab CI, Jenkins, Azure DevOps, TeamCity et JFrog Artifactory.
Ce qui distingue CRACI
Un scan binaire remonte à partir du paquet fini. CRACI part du build, car c'est la machine sur laquelle le build s'exécute.
Le build est la source de vérité
Grâce à une modification d'une seule ligne, celle de runs-on, votre workflow s'exécute sur CRACI. Un proxy qui comprend les paquets enregistre ce que chaque job télécharge depuis les sources de paquets npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk et Git, 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. Cela inclut ce que le build a récupéré et utilisé sans le livrer, comme les outils de build et les dépendances de test, qu'un scan du résultat ne voit pas.
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 après le build peut trouver une charge malveillante dans le résultat ; une politique de trafic sortant peut empêcher une dépendance compromise d'atteindre un hôte non approuvé pendant le build.
Provenance et surveillance
L'API renvoie les SBOM, les traces réseau et la provenance. CRACI ne signe pas la provenance. Il continue de réévaluer les SBOM surveillées à mesure que paraissent les avis de sécurité.
Ce que CRACI ne fait pas compte tout autant. Il n'analyse pas les binaires, ne détecte pas les malwares et ne compare pas le comportement de deux releases. Si une étape de build injecte du code dans le résultat, l'enregistrement de CRACI montre ce que le build a récupéré et d'où, mais c'est un scan binaire qui inspecte le résultat.
Un inventaire de ce qui est déployé et où
La vue d'inventaire de CRACI montre précisément quelles versions logicielles sont déployées dans quels produits, à l'échelle mondiale. Lorsqu'une nouvelle vulnérabilité apparaît, vous voyez quels produits exécutent la version concernée, au lieu de reconstituer l'information à partir de notes de version et de tableurs.
Quand utiliser l'un, l'autre, ou les deux
- Vous déployez des logiciels commerciaux ou tiers. Spectra Assure. CRACI ne peut enregistrer que les builds qui s'exécutent sur lui.
- Vous avez besoin de prouver ce qui est entré dans chaque release. CRACI. L'enregistrement vient du runner, avec la complétude indiquée.
- Vous voulez un point de contrôle de release pour les malwares et les altérations. Spectra Assure. Exécutez-le sur l'artefact avant de publier.
- Vous voulez les deux vues d'une release. Construisez sur CRACI et exécutez le scan Spectra Assure comme une étape du même workflow. CRACI répond à « qu'est-ce qui est entré dans ce build ? » ; Spectra Assure répond à « qu'y a-t-il dans ce paquet ? ». Là où les deux divergent, vous avez quelque chose à examiner.
Pour le CRA
Le Cyber Resilience Act demande aux fabricants de documenter les composants de leurs produits, notamment au moyen d'une SBOM, et de gérer les vulnérabilités aussi longtemps qu'un produit est pris en charge. Le signalement des vulnérabilités activement exploitées s'applique à partir de septembre 2026. ReversingLabs cite le CRA parmi les réglementations que ses capacités SBOM soutiennent, et son analyse du paquet que vous mettez sur le marché constitue une preuve utile. CRACI y ajoute, pour chaque build, des preuves de ce qui est entré dans ce paquet, avec la provenance, une surveillance continue et l'export des SBOM en CycloneDX ou SPDX. 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 ; aucun des deux outils ne rend un produit conforme à lui seul. Lire ce qu'exige le CRA.
Ajouter CRACI en complément de Spectra Assure
Gardez votre étape de scan Spectra Assure. Faites passer le job de release 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. Les GitHub Actions de ReversingLabs sont des étapes de workflow ordinaires : le scan reste donc dans le même job ; si vous définissez une politique de trafic sortant, autorisez les hôtes dont le scanner a besoin. CRACI ne prend en charge que GitHub Actions aujourd'hui : les pipelines GitLab, Jenkins ou Azure DevOps devraient donc migrer pour utiliser les runners CRACI. GitLab CI et Jenkins figurent sur la roadmap. Découvrez comment CRACI fonctionne pour l'électronique grand public et le SaaS.
Exécutez un vrai build et comparez
Faites pointer un workflow GitHub Actions vers CRACI et comparez son enregistrement du build avec ce que vous apprend un scan du résultat.
Réserver une démo