CRACI vs Buildkite

En bref

Buildkite est une plateforme CI/CD hybride. Son plan de contrôle SaaS gère l'orchestration, et les agents qui exécutent vos jobs se trouvent sur votre propre infrastructure, on-premises ou dans le cloud. Buildkite indique que le code source et les secrets restent dans votre environnement. Il propose aussi des agents hébergés entièrement gérés si vous préférez ne pas exploiter les vôtres.

CRACI est un runner géré, compatible avec GitHub Actions, conçu pour la sécurité de la chaîne d'approvisionnement. Il enregistre chaque dépendance externe récupérée par un build, applique une politique de trafic sortant au réseau du build, et produit à partir de cet enregistrement des SBOM, des données de provenance et des preuves pour le CRA. En résumé : Buildkite est une CI classique avec un contrôle maximal de l'infrastructure ; CRACI est une CI pensée pour la sécurité, où le runner constitue la preuve.

CRACI ne prend en charge que GitHub Actions aujourd'hui : il n'exécute donc pas les pipelines Buildkite. Une équipe sur Buildkite devrait faire passer un pipeline sur GitHub Actions pour utiliser les runners CRACI, ou attendre la prise en charge d'autres systèmes CI, qui figure sur la roadmap.

Ce que Buildkite fait bien

Le contrôle de la puissance de calcul. Comme vous hébergez les agents, vous choisissez le matériel, le système d'exploitation, le réseau et la région. Les agents interrogent l'API agent de Buildkite en HTTPS : vous n'avez donc pas besoin d'ouvrir de ports entrants dans le pare-feu. Ce modèle convient aux grands monorepos, au matériel spécialisé et aux organisations dont les politiques imposent de garder le code source dans leur propre périmètre.

L'intégrité des pipelines. Avec les pipelines signés, les jobs sont signés au téléversement et les agents vérifient la signature avant de les exécuter : un agent n'exécutera pas un job dont les instructions ont été modifiées après le téléversement.

L'outillage autour du build. Test Engine détecte et met en quarantaine les tests instables et répartit les tests sur des jobs parallèles. Package Registries peut publier des artefacts avec une provenance SLSA, qui selon Buildkite satisfait au SLSA Build Level 1 ; cette fonctionnalité est disponible sur les plans Enterprise.

Une tarification flexible. En septembre 2026, Buildkite propose un plan Free et un plan Pro à $30 par utilisateur actif et par mois, avec 10 agents auto-hébergés inclus sur Pro et des agents supplémentaires à $3.50 par agent et par mois. Les agents Linux hébergés coûtent $0.004 par minute vCPU, décomptés à la seconde.

Ce qui distingue CRACI

Les preuves de sécurité font partie du runner

Avec des agents auto-hébergés, la sécurisation de l'environnement de build vous revient. Les recommandations de sécurité de Buildkite elles-mêmes vous conseillent d'installer des systèmes d'exploitation minimaux, de désactiver le SSH entrant et d'appliquer des contrôles stricts du trafic réseau sortant. C'est un partage des responsabilités équitable, et cela signifie que les preuves sur la chaîne d'approvisionnement dépendent de ce que votre équipe construit autour des agents.

Sur CRACI, cette couche est fournie avec le runner. Un proxy qui comprend les paquets enregistre le trafic vers les sources de paquets pendant l'exécution de chaque job, pour npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk et les sources Git, ainsi que des presets de téléchargement. Les preuves de dépendances suivent les caches CI. 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.

Une politique de trafic sortant sans avoir à la construire

Les politiques de trafic sortant de CRACI sont 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. Les politiques sont validées avant le démarrage du job, bloquent tout en cas d'échec et envoient une alerte en cas de violation.

Provenance et surveillance

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

Le compromis

CRACI existe uniquement en service géré. Les jobs s'exécutent dans des machines virtuelles isolées sur l'infrastructure de CRACI, et le code source est traité dans la VM du job pendant la durée du build, sans être stocké. Sur le plan Enterprise, CRACI propose la résidence des données dans l'UE, avec exécution des builds sur une infrastructure bare metal européenne. Si votre politique impose des builds sur votre propre matériel, le modèle de Buildkite répond à cette exigence, celui de CRACI non.

Lequel choisir

• Buildkite si vous avez besoin de builds sur votre propre matériel ou réseau, exécutez des builds Windows ou macOS, utilisez GitLab ou Bitbucket, ou opérez à une échelle où posséder la puissance de calcul est rentable.
• CRACI si vous êtes sur GitHub Actions et voulez des preuves de build sans avoir à les construire ni à les exploiter : dépendances enregistrées, politique de trafic sortant et preuves pour le CRA, à partir d'un seul runner.
• Les deux si votre organisation est partagée : Buildkite pour les pipelines qui doivent rester sur votre matériel, CRACI pour les workflows GitHub Actions sous Linux. Les builds Linux lourds, comme les images Yocto, peuvent s'exécuter sur des runners CRACI allant jusqu'à 32 vCPU et 96 Go de RAM, comme le décrit le guide Yocto de CRACI.

Pour le Cyber Resilience Act

Le Cyber Resilience Act de l'UE demande aux fabricants de savoir ce que contient chaque release et d'en traiter les vulnérabilités, avec des obligations de signalement dès septembre 2026 et une application complète à partir de décembre 2027. Sur Buildkite, ces preuves proviennent des outils que vous exécutez sur vos agents. CRACI les produit à partir de l'enregistrement du build, continue de surveiller ce qui a été livré et exporte les SBOM en CycloneDX ou SPDX, vulnérabilités comprises. Il 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.

Ajouter CRACI

Pour un dépôt sur GitHub avec des workflows GitHub Actions, 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. En savoir plus sur la génération de SBOM au build et sur la façon dont CRACI gère la sécurité, ou consulter les tarifs.