CRACI vs Aikido

Consolidation ou preuves

Les équipes se tournent généralement vers Aikido parce qu'elles veulent moins d'outils de sécurité. Aikido couvre les dépendances open source, le code propriétaire, les secrets, l'infrastructure as code, les conteneurs, la posture cloud, les tests dynamiques et la protection à l'exécution dans un seul produit, avec un point unique pour trier les résultats. Pour une petite équipe qui a besoin d'une couverture large rapidement, c'est une offre solide.

Les équipes se tournent vers CRACI pour une raison plus précise. Elles doivent savoir ce que leurs builds ont réellement fait, contrôler ce que le build peut atteindre et produire, pour chaque release, des preuves qui tiennent devant un client ou un auditeur. CRACI y parvient en étant lui-même le runner CI.

Ce qu'Aikido fait bien

L'étendue est son argument principal. Chaque plan Aikido comprend SCA, SAST, détection de secrets, IaC, posture cloud, scan de conteneurs, DAST, analyse des licences et génération de SBOM. Son SCA utilise l'atteignabilité au niveau des fonctions pour réduire le bruit, et AutoFix ouvre des pull requests avec des versions corrigées. En CI, Aikido peut bloquer les pull requests présentant des risques critiques, et il fonctionne avec GitHub, GitLab, Jenkins, Bitbucket, CircleCI et d'autres. CRACI ne prend en charge que GitHub Actions aujourd'hui, avec GitLab CI et Jenkins sur la roadmap.

Aikido propose aussi Safe Chain, un outil gratuit qui place un proxy local devant les gestionnaires de paquets npm et PyPI et bloque les paquets contenant des malwares connus avant leur installation, en local et en CI. CRACI ne bloque pas de paquets individuels aujourd'hui. Le blocage de paquets à l'échelle de l'organisation figure sur la roadmap de CRACI, pas dans le produit.

Côté conformité, les plans supérieurs d'Aikido incluent des rapports de conformité SOC 2 et ISO 27001 et une synchronisation avec des plateformes de conformité comme Drata et Vanta. Si votre objectif principal est d'alimenter un programme SOC 2 avec des résultats de sécurité applicative, Aikido est conçu pour cela.

Ce qui distingue CRACI

CRACI est l'environnement d'exécution de la CI

La protection à l'exécution d'Aikido protège les applications en production. CRACI intervient à un autre moment d'exécution : le job de build. Vos jobs GitHub Actions s'exécutent sur CRACI dans des machines virtuelles isolées, sur des runners de 1 à 32 unités de calcul, en x86-64 ou ARM64. La mise en place consiste à remplacer runs-on par craci. Vos workflows ne changent pas, et les exécutions apparaissent toujours dans l'interface GitHub.

Comme CRACI exécute le job, il peut appliquer une politique de trafic sortant pendant son exécution. Les politiques sont en refus par défaut ou en autorisation par défaut, avec 24 presets de sources logicielles intégrés et des sources personnalisées typées pour npm, PyPI, apt, apk, le proxy Go, Nix, Cargo, les registres OCI et Git. Elles sont validées avant le démarrage du job et bloquent tout en cas d'échec. Un scanner peut vous dire qu'un paquet risqué existe. Une politique réseau empêche le build d'atteindre des destinations qu'il ne devrait pas atteindre.

Des preuves de build déterministes

Aikido établit sa vue des dépendances à partir des manifestes et des lockfiles et y ajoute de l'analyse, notamment des contrôles d'exploitabilité pilotés par l'IA. C'est une manière judicieuse de prioriser le travail.

La SBOM de CRACI n'est pas déduite. Un proxy qui comprend les paquets enregistre ce que le job a récupéré depuis les sources de paquets, et les preuves de dépendances suivent les caches CI : les paquets restaurés depuis un cache sont donc toujours comptés. Chaque SBOM indique sa propre complétude par job et par cache : Complete, Complete with connections, Incomplete, Unavailable ou Not recorded. C'est un enregistrement de ce qui s'est passé plutôt qu'une estimation, et il vous dit où se trouvent ses lacunes.

C'est important, car les outils SBOM statiques se contredisent plus qu'on ne le pense, et la raison est structurelle. Chacun lit un ensemble de fichiers différent et les résout différemment : ce qu'un dépôt est censé contenir dépend donc de l'outil interrogé et de sa configuration. Un projet qui ne versionne aucun lockfile, comme express 5.2.1, ne donne absolument rien à résoudre à un lecteur de lockfile. CRACI ne peut pas être comparé sur ce terrain, car il enregistre des builds au lieu de scanner des répertoires, et c'est tout l'intérêt : un enregistrement de build ne dépend pas des fichiers qui se trouvent présents.

Les données de provenance via l'API

CRACI génère la SBOM dans son propre runner, à partir de ce que le job a récupéré. L'API renvoie les SBOM, les traces réseau et la provenance.

Des résultats de conformité fondés sur cet enregistrement

Pour le Cyber Resilience Act de l'UE, la difficulté consiste à montrer ce qui est entré dans chaque release et comment vous en suivez les vulnérabilités dans le temps. CRACI agrège les vulnérabilités de l'ensemble des builds et des dépôts, et réévalue en continu les SBOM surveillées. Les SBOM s'exportent en CycloneDX ou SPDX, vulnérabilités comprises, et l'API renvoie les SBOM, les traces réseau et la provenance. CRACI automatise une part importante de la visibilité et des preuves sur la chaîne d'approvisionnement logicielle dont les entreprises ont besoin pour leur démarche plus large de conformité au CRA. Voir Conformité CRA et Preuves CRA.

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. Quand 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.

Lequel choisir

• Choisissez Aikido si vous voulez un seul outil couvrant le code, les dépendances, le cloud et les applications en production, si vous utilisez aujourd'hui des systèmes CI autres que GitHub Actions, ou si votre priorité de conformité est un reporting SOC 2 ou ISO 27001 à partir de résultats de sécurité applicative.
• Choisissez CRACI si vous construisez sur GitHub Actions et devez savoir précisément ce que chaque build a récupéré, contrôler l'accès réseau du build et conserver des preuves de release pour le CRA et les audits clients.
• Utilisez les deux si vous voulez le scan et le blocage des pull requests d'Aikido, plus les contrôles à l'exécution du build et les preuves de CRACI. Les contrôles CI et Safe Chain d'Aikido s'exécutent comme des étapes de votre workflow, et ces étapes peuvent tourner sur un runner CRACI comme n'importe quelles autres.