CRACI vs CircleCI

La réponse courte

CircleCI est une plateforme CI/CD mature et flexible. Elle se connecte à GitHub, GitLab et Bitbucket, exécute les jobs sur un large éventail de machines, des conteneurs Docker à macOS et aux GPU, et vous permet de regrouper une configuration réutilisable sous forme d'orbs. Côté sécurité, CircleCI protège les identifiants et confie le scan aux orbs et à des outils tiers.

CRACI adopte l'approche inverse : le runner est l'enregistrement de sécurité. Il exécute les jobs GitHub Actions, observe chaque dépendance externe récupérée par chaque build, applique une politique de trafic sortant sur le réseau du build, et produit des SBOM, des données de provenance et des preuves pour le CRA à partir de ce qu'il a vu. C'est toute la différence entre une CI traditionnelle et une CI pensée pour la sécurité.

CRACI ne prend en charge que GitHub Actions aujourd'hui, avec GitLab CI et Jenkins sur la roadmap. CircleCI n'est pas encore pris en charge. Les équipes sur CircleCI devraient migrer un pipeline vers GitHub Actions pour utiliser les runners CRACI, ou attendre les autres systèmes CI, qui figurent sur la roadmap.

Les points forts de CircleCI

L'étendue des ressources de calcul. CircleCI propose des classes de ressources Docker, VM Linux, Arm, Windows, macOS et GPU : une seule plateforme peut donc construire un backend, un client Windows et une app iOS. Les runners auto-hébergés étendent cela à vos propres machines Linux, Windows et macOS ainsi qu'à Kubernetes, et le temps de job sur ces runners ne consomme pas de crédits.

Des fonctionnalités de vitesse. Le cache des couches Docker est disponible sur tous les plans. Le test splitting répartit une suite de tests entre des exécuteurs parallèles par nom, taille de fichier ou données de durée historiques, ce qui réduit le temps réel d'exécution des grandes suites de tests.

Une configuration réutilisable. Les orbs regroupent jobs, commandes et exécuteurs pour que les équipes puissent les réutiliser d'un projet à l'autre, et ils facilitent l'intégration d'outils tiers, scanners de sécurité compris.

L'hygiène des identifiants. Les recommandations de CircleCI sur la chaîne d'approvisionnement portent surtout sur la protection des secrets : les répartir dans des contexts, placer les clés de déploiement et de signature dans des contexts restreints gérés par vos groupes VCS, et utiliser des jetons OIDC pour que les jobs accèdent aux services cloud sans identifiants de longue durée stockés dans CircleCI.

Ce qui distingue CRACI

Le build est la source de vérité

Sur une plateforme CI traditionnelle, une SBOM est produite par un outil que vous ajoutez au pipeline, qui lit généralement les manifestes et les lockfiles. CRACI observe plutôt le build. Un proxy qui comprend les paquets enregistre le trafic vers les sources de paquets pendant l'exécution du job, pour npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk et Git, ainsi que les presets de téléchargement. Les preuves de dépendances suivent les caches CI : un paquet restauré depuis un cache est donc toujours comptabilisé.

Vous savez à quel point la SBOM est complète

Chaque job produit une SBOM CycloneDX ou SPDX avec un état de complétude par job et par cache : Complete, Complete with connections, Incomplete, Unavailable ou Not recorded.

Le réseau du build a une politique

La fonctionnalité de plages d'IP de CircleCI fait passer les jobs par des adresses CircleCI connues afin que vos propres systèmes puissent les autoriser. Cela règle l'accès entrant. CRACI ajoute du contrôle dans l'autre sens : des politiques de trafic sortant pour chaque job, en refus ou en autorisation par défaut, avec 24 presets de sources logicielles intégrés, des sources personnalisées typées et des règles TLS, TCP, UDP et ICMP explicites. Les politiques sont validées avant le démarrage du job et bloquent tout en cas d'échec. CRACI fournit aussi une plage d'IP de sortie stable.

Provenance et surveillance à partir du même enregistrement

L'API renvoie les SBOM, les traces réseau et la provenance. 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.

Lequel vous convient

• Restez sur CircleCI si votre code est sur GitLab ou Bitbucket, si vous dépendez de builds Windows, macOS ou GPU, ou si vous exécutez des jobs sur votre propre matériel.
• Envisagez CRACI si votre code est sur GitHub, que vous hésitez entre GitHub Actions et CircleCI, et que vous livrez des logiciels pour lesquels vous devez montrer ce qui est entré dans chaque release.
• Utilisez les deux pendant une migration progressive : gardez les pipelines macOS et Windows sur CircleCI, et exécutez les workflows GitHub Actions Linux sur CRACI là où les preuves de build comptent le plus.

Pour le Cyber Resilience Act

Le Cyber Resilience Act de l'UE attend des fabricants qu'ils sachent ce que contient chaque release et qu'ils en gèrent les vulnérabilités, avec des obligations de signalement à partir de septembre 2026 et une application complète à partir de décembre 2027. Sur CircleCI, ces preuves viennent des scanners et des orbs que vous intégrez à vos pipelines. CRACI les produit à partir de l'enregistrement du build et exporte les SBOM en CycloneDX ou SPDX, vulnérabilités comprises. Il 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.

Migrer un pipeline vers CRACI

CRACI exécute des workflows GitHub Actions : un pipeline CircleCI doit donc d'abord avoir un équivalent GitHub Actions. Une fois celui-ci en place, installez la GitHub App CRACI sur votre organisation et définissez le label du runner :

runs-on: craci

Les exécutions apparaissent toujours dans l'interface GitHub. Les jobs disposent de Docker Engine, Buildx et Compose v2, de tailles de runner de 1 à 32 vCPU avec 3 Go de RAM chacun, et de la prise en charge du cache GitHub Actions. En savoir plus sur la génération de SBOM au build, ou consultez les tarifs et le programme startup.