Comparatif
CRACI vs GitLab CI
GitLab scanne votre projet et rapporte ce que déclarent ses lockfiles. CRACI est le runner : il enregistre donc ce que chaque build a réellement récupéré. La différence tient à l'origine de votre SBOM et de votre provenance.
Mis à jour le
En bref
GitLab est une plateforme DevSecOps complète : gestion du code source, merge requests, planification et CI/CD dans un seul produit, avec un large éventail de scanners de sécurité et une gestion des vulnérabilités dans son offre Ultimate. Si vous voulez un seul fournisseur pour tout le cycle de vie logiciel, GitLab est conçu pour cela.
CRACI est plus ciblé. C'est un runner compatible avec GitHub Actions qui enregistre chaque dépendance externe récupérée par un build, contrôle ce que le build peut joindre et transforme cet enregistrement en SBOM, en données de provenance et en preuves pour le CRA. La différence fondamentale oppose une CI classique à laquelle on greffe des scanners à une CI où le runner constitue lui-même l'enregistrement de sécurité.
Un point pratique avant tout. CRACI ne prend en charge que GitHub Actions aujourd'hui ; GitLab CI et Jenkins figurent sur la roadmap. Si vos pipelines sont sur GitLab CI, vous devriez les faire passer sur GitHub Actions pour utiliser les runners CRACI, ou attendre la prise en charge de GitLab CI, qui figure sur la roadmap.
| Fonctionnalité | CRACI | GitLab |
|---|---|---|
| Dépendances enregistrées à partir du build | Récupérations observées, paquets des caches CI compris | Les scanners lisent les lockfiles et les exports de graphes de dépendances |
| Export de SBOM | CycloneDX ou SPDX par build, avec état de complétude | Rapports CycloneDX ; export de la liste de dépendances en Ultimate |
| Politique de trafic sortant du build | Refus ou autorisation par défaut, blocage total en cas d'échec | Vos propres contrôles réseau sur les runners autogérés |
| Provenance de build | Données de provenance via l'API ; non signées | Déclaration de provenance SLSA 1.0 émise par le runner |
| Surveillance continue des vulnérabilités | Réévalue en continu les SBOM surveillées | Scan continu des vulnérabilités en Ultimate |
| Reporting de conformité | SBOM en CycloneDX ou SPDX, enregistrements via l'API ; pas d'export de rapport | Fonctionnalités de conformité et de gouvernance en Ultimate |
| SAST, détection de secrets, DAST | SAST et secrets de base dans toutes les offres ; DAST en Ultimate | |
| Gestion du code source et planification | Fonctionne avec vos dépôts GitHub | Dépôts, merge requests et planification sur une seule plateforme |
| Systèmes CI pris en charge | GitHub Actions aujourd'hui ; GitLab CI et Jenkins sur la roadmap | GitLab CI/CD, hébergé ou autogéré |
| Plateformes de runners hébergés | Linux en x86-64 et ARM64, de 1 à 32 vCPU. Windows et macOS sur la roadmap. | Linux en x86-64 et arm64 ; runners hébergés Windows et macOS en bêta. |
| Tarifs | Paiement à la minute de build : $0.004 par minute pour 2 vCPU, décompté à la seconde. Sans abonnement mensuel ni frais par SBOM. | Gratuit avec 400 minutes de calcul ; Premium à $29 par utilisateur et par mois, facturé annuellement ; Ultimate sur devis (en septembre 2026). |
- Inclus
- En partie
- Non inclus
- Sur la roadmap
Ce que GitLab fait bien
Une seule plateforme. Le code, les revues, les pipelines, les résultats de sécurité et la planification se trouvent au même endroit, avec un seul modèle de permissions. Pour de nombreuses organisations, cela suffit à trancher la question.
Le scan de sécurité, selon l'offre. Soyez précis sur ce que chaque offre inclut. Selon GitLab, le SAST de base, la détection de secrets et le scan de conteneurs s'exécutent dans toutes les offres, y compris Free. Dans Free et Premium, ces scans produisent des artefacts de rapport JSON. Ultimate ajoute le workflow autour : les résultats dans les merge requests, le rapport de vulnérabilités, la liste de dépendances, les approbations de sécurité et GitLab Advanced SAST. Le scan des dépendances, le scan continu des vulnérabilités et le DAST sont des fonctionnalités d'Ultimate. Le scan de conteneurs peut aussi produire un rapport SBOM CycloneDX dans toutes les offres.
La provenance. GitLab Runner peut générer une déclaration de provenance d'artefact au format SLSA 1.0 dans toutes les offres. Des attestations SLSA Level 3 signées existent aussi, mais GitLab les présente comme une expérimentation sur GitLab.com pour Ultimate, derrière un feature flag désactivé par défaut.
Le choix des runners. Les runners hébergés par GitLab couvrent Linux en x86-64 (de 2 à 32 vCPU) et arm64, avec Windows et macOS en bêta. Vous pouvez aussi exécuter vos propres runners n'importe où, et GitLab indique que les jobs sur vos propres runners ne consomment pas de minutes de calcul. GitLab Dedicated ajoute la résidence des données dans la région de votre choix.
Ce qui distingue CRACI
La SBOM vient du build, pas du lockfile
Le scan des dépendances de GitLab, fondé sur les SBOM, détecte les dépendances à partir de lockfiles pris en charge ou d'exports de graphes de dépendances. C'est une approche solide lorsque le lockfile dit tout. Les builds en font souvent davantage : ils exécutent des scripts d'installation, téléchargent des chaînes d'outils, restaurent des caches et récupèrent des images de base.
CRACI voit cette activité, car il est le runner. Un proxy qui comprend les paquets observe le trafic vers les sources de paquets pendant l'exécution du job, pour npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk et les sources Git, ainsi que les presets de téléchargement. Les preuves de dépendances suivent les caches CI : un paquet restauré depuis un cache reste donc comptabilisé. Chaque job produit une SBOM en CycloneDX ou SPDX.
La complétude est indiquée, pas supposée
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, vous pouvez la voir.
Le réseau du build est une politique
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 et des sources personnalisées typées pour npm, PyPI, apt, apk, le proxy Go, Nix, Cargo, les registres OCI et Git. 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. Sur GitLab, le contrôle réseau des builds se limite à ce que vous configurez autour de vos propres runners.
Provenance
L'API renvoie les SBOM, les traces réseau et la provenance. CRACI ne signe pas la provenance et ne revendique aucun niveau SLSA.
Surveiller ce qui a été livré
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 à mesure que paraissent de nouveaux avis de sécurité.
Lequel choisir
- Restez sur GitLab si votre code et vos pipelines sont sur GitLab et que vous voulez une seule plateforme, ou si vous avez besoin de SAST, de DAST et de détection de secrets dans le même produit.
- Choisissez CRACI si votre code est sur GitHub, que vous utilisez GitHub Actions, et que vous avez besoin de preuves de ce qui est entré dans chaque release, d'un contrôle de ce que les builds peuvent joindre et de SBOM que vous pouvez défendre lors d'un audit.
- Utilisez les deux si votre organisation exploite les deux plateformes. GitLab continue de couvrir ses projets et ses scanners ; CRACI exécute les builds GitHub Actions et les enregistre.
Pour le Cyber Resilience Act
Au titre du Cyber Resilience Act de l'UE, les fabricants doivent savoir ce que contient chaque release de leurs produits et en traiter les vulnérabilités. Les obligations de signalement des vulnérabilités s'appliquent à partir de septembre 2026, et le règlement s'applique intégralement à partir de décembre 2027. GitLab Ultimate aide à trouver et à gérer les vulnérabilités dans vos projets. CRACI enregistre à partir de quoi chaque release a été construite, continue de la surveiller et exporte les SBOM en CycloneDX ou SPDX. 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. Aucun des deux outils ne vous rend conforme à lui seul.
Ajouter CRACI
Pour un dépôt sur GitHub, installez la GitHub App CRACI sur votre organisation, pour tous les dépôts ou une sélection, puis modifiez le label du runner :
runs-on: craciLes workflows, les actions et l'interface GitHub restent les mêmes. CRACI remplace le runner, pas GitHub Actions. En savoir plus sur la génération de SBOM au build et les preuves pour le CRA, ou consulter les tarifs.
Découvrez ce que récupère vraiment un build
Exécutez un workflow GitHub Actions sur CRACI et comparez sa SBOM à celle que produisent vos scanners aujourd'hui.
Réserver une démo