CRACI vs Cycode

La réponse courte

Cycode se présente comme une plateforme agentique de sécurité du développement, issue de la gestion de la posture de sécurité applicative (ASPM). Elle vend la sécurité du code (SAST, SCA, scan des conteneurs et de l'IaC), la sécurité de la chaîne d'approvisionnement logicielle (sécurité CI/CD, protection du build à l'exécution, détection des fuites de code, SBOM, secrets), la gestion de la posture avec plus de 100 connecteurs, et la gouvernance de l'IA dans le développement. Sa brique de protection du build à l'exécution, Cimon, est un agent eBPF qui s'exécute dans vos jobs CI.

CRACI vise le même budget de sécurité de la chaîne d'approvisionnement, et avec Cimon le recoupement est réel : les deux observent les builds, les deux peuvent restreindre le trafic sortant du build, et les deux produisent une SBOM à partir du build. Cimon signe aussi la provenance ; CRACI, non. La différence tient à l'endroit où tout cela se trouve. Cycode ajoute un agent à la CI que vous utilisez déjà, sur de nombreux systèmes. CRACI est le runner de GitHub Actions : l'enregistrement et la politique accompagnent donc chaque job, et CRACI les prolonge jusqu'à la surveillance et aux preuves pour le CRA. Le périmètre de Cycode est bien plus large ; CRACI va plus loin sur le build et sur ce qui a été livré.

En un coup d'œil

Les points forts de Cycode

Une large couverture du SDLC

• Sécurité du code : SAST et AI SAST, SCA avec analyse d'atteignabilité et conformité des licences, scan des conteneurs et sécurité de l'infrastructure as code.
• Secrets et fuites : Cycode recherche les secrets exposés dans le code source, les pipelines et des outils comme Jira, Slack et Confluence, et détecte les fuites de code.
• Sécurité CI/CD : elle surveille les politiques de sécurité, les configurations et la gouvernance CI/CD, et applique des politiques pour aider les équipes à respecter des référentiels comme le NIST SSDF.
• Gestion de la posture : le Context Intelligence Graph trace les vulnérabilités à travers le code, les configurations des outils, l'infrastructure cloud et la responsabilité des équipes, et ConnectorX intègre les résultats d'autres scanners.
• SBOM : Cycode génère des SBOM en SPDX ou CycloneDX, et son plan Posture Management mentionne l'import de SBOM.

Cimon, l'agent de protection du build à l'exécution

Cycode décrit Cimon comme une protection à l'exécution, une SBOM observée à l'exécution et une provenance SLSA en une seule étape GitHub Actions ou Azure Pipelines. Il surveille l'exécution des processus, le trafic réseau sortant et les accès aux fichiers au niveau du noyau avec eBPF. En mode détection, il observe sans bloquer ; une fois le comportement normal d'un pipeline établi, il l'impose, et la GitHub Action accepte une liste d'hôtes et d'IP autorisés. Cimon signe la provenance selon la spécification SLSA Provenance v1.0, ce qui, selon Cycode, satisfait SLSA Build Level 2 sur un runner hébergé signé via GitHub OIDC. Il fonctionne aussi sur Jenkins, GitLab CI, Buildkite et Harness, et Cycode indique qu'il est gratuit et open source.

Ce qui distingue CRACI

Le runner, pas un agent installé dessus

Cimon s'ajoute aux runners que vous conservez ; sur GitHub Actions, il s'exécute comme un conteneur privilégié qui rejoint les espaces de noms de processus et réseau du runner. C'est ce qui lui permet de fonctionner sur des runners hébergés et de nombreux systèmes CI. CRACI prend l'autre voie et remplace le runner. Vous remplacez runs-on par craci, et la politique de trafic sortant fait partie de la plateforme : validée avant le démarrage du job, elle rejette les champs inconnus et bloque tout en cas d'échec.

Des paquets et des sources, pas seulement des hôtes

La politique de trafic sortant de CRACI est typée par écosystème. Elle compte 24 presets de sources logicielles intégrés, des sources personnalisées pour npm, PyPI, apt, apk, le proxy Go, Nix, Cargo, les registres OCI et Git via HTTPS et SSH, ainsi que des règles TLS, TCP, UDP et ICMP explicites. Un proxy qui comprend les paquets enregistre les paquets récupérés par chaque job. Les preuves de dépendances suivent les caches CI : un paquet restauré depuis un cache figure donc toujours dans l'enregistrement, et chaque SBOM porte un état de complétude par job et par cache : Complete, Complete with connections, Incomplete, Unavailable ou Not recorded.

Du build jusqu'à ce qui a été livré

• Provenance : l'API renvoie les SBOM, les traces réseau et la provenance.
• Surveillance : CRACI continue de réévaluer les SBOM de ce que vous avez livré à mesure que de nouvelles vulnérabilités apparaissent, avec une agrégation sur l'ensemble des builds et des dépôts.
• Export : les SBOM en CycloneDX ou SPDX, vulnérabilités comprises.

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 le reconstituer à partir de notes de version et de tableurs.

Là où Cycode a l'avantage

Pour être clair : CRACI n'offre ni SAST, ni scan des secrets, de l'IaC ou des conteneurs, ni connecteurs ASPM, ni surveillance des processus ou des fichiers, et pas encore de mode détection ou surveillance (il figure sur la roadmap). CRACI ne signe pas la provenance et ne revendique aucun niveau SLSA, et il ne prend en charge que GitHub Actions aujourd'hui, avec GitLab CI et Jenkins sur la roadmap. Si vous avez besoin d'une seule plateforme pour tout votre code et tous vos systèmes CI, Cycode en couvre beaucoup plus.

Lequel vous convient

Cycode convient mieux si

• Vous voulez une seule plateforme ASPM pour le scan du code, les secrets, la posture CI/CD et la priorisation.
• Vous utilisez Azure Pipelines, Jenkins, GitLab CI ou Buildkite et voulez y protéger le build à l'exécution.
• Vous voulez conserver les runners hébergés par GitHub et leur ajouter un agent.

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, pour chaque build, d'une SBOM au niveau des paquets avec un état de complétude que vous pouvez montrer à un auditeur.
• Vous voulez la surveillance de ce qui a été livré et les preuves pour le CRA à partir du même enregistrement.

Utiliser les deux

Le scan du code, la détection des secrets et la gestion de la posture de Cycode couvrent un terrain que CRACI n'aborde pas : les deux peuvent donc coexister. Cimon fait exception : sur un runner CRACI, l'observation du build et le contrôle du trafic sortant font déjà partie du runner, si bien que CRACI remplace Cimon au lieu de s'exécuter à côté, sauf si vous avez besoin de la provenance signée de Cimon.

Pour d'autres plateformes ASPM, scanners et agents de runner, voir Alternatives à Cycode.

Pour le Cyber Resilience Act

Cycode positionne sa plateforme pour la conformité au CRA avec la génération automatisée de SBOM, le suivi des vulnérabilités et la collecte de preuves pour les dossiers techniques. 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, en partant du build : des SBOM avec états de complétude, la provenance, la surveillance de ce qui a été livré et l'export des SBOM comme preuves pour le CRA. Aucun des deux outils ne vous rend conforme à lui seul. Voir ce qu'exige le CRA et la conformité au CRA.

Ajouter CRACI

Installez la GitHub App CRACI sur votre organisation, puis remplacez le libellé du runner d'un job par runs-on: craci. Les exécutions apparaissent toujours dans l'interface GitHub. En savoir plus sur l'intégration CI/CD, la génération de SBOM au build et les tarifs.