CRACI vs Xygeni

En bref

Xygeni est une plateforme de sécurité applicative basée à Valladolid, en Espagne. Elle se décrit comme « one AI-powered platform that detects, prioritizes, and remediates vulnerabilities and malware end-to-end ». Ses modules couvrent le SAST, le SCA avec atteignabilité et détection de malwares, les secrets, l'IaC, les conteneurs, la sécurité CI/CD, la sécurité du build avec des attestations SLSA et in-toto, la détection d'anomalies, le DAST, la sécurité des API et une couche ASPM. Elle publie ses prix et propose un plan gratuit. Elle n'exécute pas de builds : elle se branche sur les systèmes CI que vous utilisez déjà.

CRACI vise le même budget de chaîne d'approvisionnement sous un autre angle. C'est le runner pour GitHub Actions : il enregistre les paquets que chaque job a réellement récupérés, applique une politique de trafic sortant pendant l'exécution du job et continue de surveiller ce qui a été livré. Xygeni est bien plus large sur l'AppSec ; CRACI va plus loin sur le build et ce qui en est sorti.

En un coup d'œil

« Non précisé » signifie que nous n'avons pas pu le confirmer sur les pages publiques de Xygeni.

Ce que Xygeni fait bien

• L'étendue dans une seule plateforme. SAST avec autofix par IA, SCA avec atteignabilité et pull requests de mise à niveau automatiques, détection de secrets avec révocation automatique, scan d'IaC et d'images de conteneur et, sur Enterprise, DAST, sécurité des API et ASPM avec ingestion de données tierces.
• Les malwares dans l'open source. Xygeni indique analyser chaque jour des milliers de paquets open source nouveaux ou mis à jour, utilise un moteur assisté par ML pour détecter les malwares inconnus, met en quarantaine les paquets suspects et peut les bloquer avec un pare-feu de dépendances. Cela va au-delà du rapprochement des CVE.
• La sécurité CI/CD. Xygeni recherche les erreurs de configuration dans les scripts de build et les pipelines, traite l'OWASP Top 10 CI/CD Risks, vérifie des paramètres tels que la protection des branches et l'authentification multifacteur, et signale les commandes dangereuses dans les pipelines, comme les reverse shells et les téléchargements de malwares.
• Les attestations de build. Build Security ajoute une ligne à un pipeline pour rassembler des preuves à chaque étape du build et générer une provenance SLSA et des attestations in-toto, avec des signatures keyless. Les attestations peuvent porter des scans de vulnérabilités, des SBOM en SPDX ou CycloneDX et des résultats de tests, et les artefacts altérés peuvent être bloqués avant la livraison.
• La détection d'anomalies. Des capteurs pour GitHub, GitLab, Jenkins et Azure surveillent les modifications non autorisées du code, des dépendances, des pipelines et de la configuration de build, et alertent en temps réel.
• Une large couverture CI et des prix publiés. Xygeni cite des intégrations avec GitHub, GitLab, Jenkins, Azure Pipelines, Bitbucket, CircleCI et Travis CI, et propose un déploiement sur site sur Enterprise.

Ce qui distingue CRACI

Enregistré à partir du build, pas lu dans des descripteurs

La documentation de Xygeni indique que ses analyseurs traitent les descripteurs de dépendances pour en extraire les dépendances directes et indirectes et résoudre leurs versions. C'est la méthode habituelle pour construire une SBOM à partir d'un dépôt. CRACI voit au contraire le trafic qui entre dans chaque build : un proxy qui comprend les paquets enregistre chaque paquet récupéré par le job depuis les sources npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk et Git, ainsi que les presets de téléchargement. Les paquets restaurés depuis les caches CI restent dans l'enregistrement.

C'est ainsi que CRACI enregistre les dépendances cachées que les outils fondés sur les lockfiles manquent : le code téléchargé par les hooks d'installation npm, les scripts de build Rust qui récupèrent des éléments au moment du build et les couches d'image de base d'un build de conteneur. Chaque SBOM porte un état de complétude par job et par cache (Complete, Complete with connections, Incomplete, Unavailable ou Not recorded) : lorsque l'enregistrement présente une lacune, il le dit.

Le contrôle pendant l'exécution du build

Les vérifications CI/CD de Xygeni examinent la configuration des pipelines et les commandes qu'ils contiennent. CRACI limite ce que le build peut atteindre. Les politiques de trafic sortant fonctionnent en refus par défaut ou en autorisation par défaut, avec 24 presets de sources logicielles intégrés, des sources personnalisées typées pour npm, PyPI, apt, apk, le proxy Go, Nix, Cargo, les registres OCI et Git, et des règles TLS, TCP, UDP et ICMP explicites. Elles sont validées avant le démarrage du job et bloquent tout en cas d'échec. Comme une politique de refus par défaut n'autorise que ce dont le build a besoin, un paquet compromis qui tente d'envoyer vos secrets vers un hôte inconnu est bloqué, même lors d'une attaque jamais vue, et CRACI vous signale la violation.

Provenance et surveillance à partir d'un seul enregistrement

Xygeni signe des attestations depuis une étape ajoutée au pipeline que vous exécutez. L'enregistrement de CRACI vient du runner sur lequel le job s'est exécuté : l'API renvoie les SBOM, les traces réseau et la provenance. CRACI ne signe pas la provenance et ne revendique aucun niveau SLSA. CRACI continue de réévaluer les SBOM de ce que vous avez livré à mesure que de nouvelles vulnérabilités sont publiées, et montre chaque build passé qui contenait une dépendance vulnérable : vous savez ainsi combien de temps vous avez été exposé.

Le runner fait partie du produit

Comme CRACI est le runner, les preuves viennent avec la capacité de calcul : les exécutions apparaissent toujours dans GitHub, et CRACI exécute les builds environ deux fois plus vite que les runners hébergés par GitHub, grâce à un matériel plus rapide, des temps d'attente plus courts et le cache. CRACI ne facture que les minutes de build, $0.002 par minute vCPU ($0.004 pour un runner 2 vCPU par défaut), décompté à la seconde, sans abonnement mensuel ni frais par SBOM. Consultez les tarifs de CRACI.

Lequel choisir

Xygeni convient mieux si

• Vous voulez une seule plateforme AppSec pour le SAST, le SCA, les secrets, l'IaC, les conteneurs et la configuration des pipelines.
• Vous voulez que les paquets open source malveillants soient détectés et bloqués avant qu'un avis de sécurité n'existe.
• Vous construisez sur GitLab, Jenkins, Azure Pipelines, Bitbucket, CircleCI ou Travis CI.
• Vous avez besoin d'attestations SLSA et in-toto, ou d'un déploiement sur site.
• Une petite équipe veut démarrer sur un plan gratuit avec des prix publiés.

CRACI convient mieux si

• Vous construisez sur GitHub Actions et voulez le runner, la politique de trafic sortant et l'enregistrement des dépendances au même endroit.
• Vous avez besoin d'une SBOM de ce que chaque build a réellement récupéré, avec un état de complétude à présenter à un auditeur.
• Vous voulez la surveillance de ce qui a été livré et l'historique des builds à partir du même enregistrement.

Ce à quoi vous renoncez en passant les preuves de build sur CRACI

Pour les logiciels que vous construisez sur GitHub Actions, CRACI prend le relais de l'export de SBOM de Xygeni : l'enregistrement, les données de provenance et la surveillance viennent du runner. Disons clairement ce que cela coûte : CRACI ne propose pas d'analyse d'atteignabilité, ne détecte pas les nouveaux paquets malveillants par leur comportement ou leur réputation (il signale les releases malveillantes connues une fois qu'un avis de sécurité avec une CVE est publié), n'ouvre pas de pull requests de mise à niveau, ne signe pas la provenance, ne revendique aucun niveau SLSA, n'a pas de détection d'anomalies sur la gestion de code source et n'exécute aujourd'hui que GitHub Actions, avec GitLab CI et Jenkins sur la roadmap.

Le SAST, les secrets, l'IaC et les vérifications de posture CI/CD de Xygeni couvrent un terrain que CRACI ne touche pas, par choix de conception : ils peuvent donc rester en place. CRACI remplace le runner, pas GitHub Actions : une étape de scan s'exécute donc sur un runner CRACI comme n'importe quelle autre étape.

Pour le Cyber Resilience Act

Le Cyber Resilience Act est l'un des cadres qui demandent une SBOM et un processus de gestion des vulnérabilités. Xygeni cite des vérifications de conformité de la chaîne d'approvisionnement logicielle par rapport à CIS et OpenSSF sur son plan Business. CRACI automatise une part importante de la visibilité sur la chaîne d'approvisionnement et des preuves dont une démarche CRA a besoin : SBOM de build exportées en CycloneDX ou SPDX, suivi des vulnérabilités et provenance via l'API. Voir les preuves pour le CRA. Aucun des deux outils ne rend un produit conforme à lui seul.

Pour d'autres plateformes de ce domaine, voir CRACI vs Cycode, CRACI vs OX Security, CRACI vs Wiz et les outils de sécurité de la chaîne d'approvisionnement logicielle.

Xygeni : vos questions, nos réponses

Qu'est-ce que Xygeni ?

Xygeni est une plateforme de sécurité applicative basée à Valladolid, en Espagne. Elle associe ses propres scanners (SAST, SCA avec atteignabilité et détection de malwares, secrets, IaC, conteneurs, sécurité CI/CD et, en option, DAST et sécurité des API) à une couche ASPM, ainsi qu'à la sécurité du build avec des attestations SLSA et in-toto et à la détection d'anomalies sur la gestion de code source et les systèmes CI.

Combien coûte Xygeni ?

En septembre 2026, la page de tarifs de Xygeni affiche un plan gratuit avec SAST, SCA, secrets et un plugin d'IDE dans la limite de 10 dépôts, 200 scans par mois et 5 contributeurs. Team commence à environ $3,828 (€3,300) par an et Business à environ $6,844 (€5,900) par an, chacun incluant 10 contributeurs, et Enterprise est sur devis. Un contributeur est toute personne ayant commité dans un dépôt scanné au cours des 90 derniers jours. Build Security et Anomalies Detection sont des options Enterprise.

Xygeni fournit-il des runners CI ?

Non. Xygeni s'intègre aux systèmes CI que vous exploitez, tels que GitHub, GitLab, Jenkins, Azure Pipelines, Bitbucket, CircleCI et Travis CI, et ajoute ses scanners et son étape d'attestation à vos pipelines. CRACI est le runner : les jobs GitHub Actions s'exécutent sur CRACI, qui enregistre ce que chaque job a récupéré et contrôle ce qu'il peut atteindre.

Quelle est la différence entre Xygeni et CRACI ?

Xygeni est une plateforme AppSec étendue qui scanne le code, les dépendances, les secrets, l'IaC et la configuration des pipelines sur de nombreux systèmes CI. CRACI est un runner GitHub Actions qui enregistre les paquets que chaque build a réellement récupérés, applique une politique de trafic sortant pendant son exécution et continue de surveiller ce qui a été livré. Xygeni est bien plus large ; CRACI enregistre le build lui-même.

CRACI peut-il remplacer Xygeni ?

Pour les preuves de build des logiciels que vous construisez sur GitHub Actions, oui : la SBOM enregistrée, la provenance et la surveillance des vulnérabilités de CRACI couvrent cette tâche. CRACI ne remplace pas le SAST, les secrets, l'IaC, les vérifications de posture CI/CD, la détection de malwares ni l'analyse d'atteignabilité de Xygeni, et il n'exécute aujourd'hui que GitHub Actions, avec GitLab CI et Jenkins sur la roadmap.