Ce que CRACI remplace dans votre stack, et ce avec quoi il fonctionne

La réponse courte : ce qui bouge et ce qui reste

Cartographiez votre propre stack avec ce tableau. Chaque ligne indique une tâche qu'un outil de votre stack accomplit aujourd'hui, ce que cette tâche doit voir pour être accomplie, et si CRACI s'en charge depuis sa position.

Tâche dans votre stack	Ce que la tâche doit voir	CRACI	Ce que vous gardez, et pourquoi
Runners CI pour les jobs Linux sur GitHub Actions : hébergés par GitHub, par un fournisseur tiers ou une flotte auto-hébergée	Un endroit où exécuter le job	Remplace	Les runners pour Windows, macOS, GitHub Enterprise Server et les systèmes CI autres que GitHub Actions, que CRACI ne prend pas en charge aujourd'hui
Agents de surveillance réseau ou de trafic sortant ajoutés aux runners que vous gardez	Le trafic sortant du job	Remplace sur les runners CRACI	Les agents sur les runners que vous gardez ailleurs
Générateurs de SBOM exécutés en CI, équipe par équipe : scanners de manifestes, de lockfiles ou d'images utilisés pour produire des SBOM	Ce que le build a réellement récupéré	Remplace pour les builds sur CRACI	Les générateurs pour les logiciels que vous ne construisez pas sur CRACI, comme les images que vous récupérez sans jamais les construire
Génération de SBOM intégrée à Yocto (create-spdx) pour la couverture de la chaîne d'approvisionnement	Chaque source et chaque outil récupéré par le build BitBake	Remplace pour la couverture de la chaîne d'approvisionnement	create-spdx, si vous comptez sur ses métadonnées de recettes : patchs appliqués et CVE marquées comme corrigées
Suivi des vulnérabilités à partir des SBOM : importer des SBOM, rapprocher les avis de sécurité, surveiller les nouveaux	Une SBOM exacte par version, tenue à jour	Remplace pour les builds sur CRACI ; les SBOM fournisseurs peuvent être ajoutées	Un outil dédié si vous avez besoin de ce que CRACI ne fait pas : atteignabilité, indicateurs de remédiation comme le MTTR ou des échéances par gravité
SBOM et listes de composants tenues dans des tableurs	Une SBOM exacte par version, tenue à jour	Remplace	Rien
Contrôle des licences déclarées et politique de licences	La licence déclarée de chaque composant	En partie	Analyse de licences au niveau du texte intégral et des extraits, mentions d'attribution
SAST et analyse de code	Votre code source	Fonctionne avec	À garder ; il s'exécute sans changement comme étape de workflow sur un runner CRACI
Détection de secrets et protection des push	Votre dépôt et vos commits	Fonctionne avec	À garder
DAST et tests d'API	Votre service en fonctionnement	Fonctionne avec	À garder
Analyse de binaires et de firmware tiers	Un binaire fini que vous n'avez pas construit	Fonctionne avec	À garder
Analyse d'extraits et de signatures pour le code copié ou embarqué	Le contenu des fichiers du dépôt	Fonctionne avec	À garder
Priorisation fondée sur l'atteignabilité	Votre graphe d'appels	Fonctionne avec	À garder si vous en dépendez
Analyse de l'IaC, des clusters et des erreurs de configuration	La configuration et l'infrastructure en fonctionnement	Fonctionne avec	À garder
Contrôles de posture CI/CD sur la configuration des workflows	Les fichiers et paramètres des workflows	Fonctionne avec	À garder
Ticketing, gestion des dossiers PSIRT, publication d'avis de sécurité	Votre processus	Fonctionne avec	À garder
Automatisation de la conformité : collecte de preuves pour les audits SOC 2 ou ISO 27001	Vos contrôles à travers les systèmes	Fonctionne avec	À garder ; les enregistrements de CRACI sont des preuves qu'elle peut collecter

Avant et après

Avant : des runners hébergés par GitHub, un générateur de SBOM différent dans le workflow de chaque équipe, le create-spdx de Yocto qui allonge le temps de build, et des SBOM importées dans un outil de suivi ou un tableur, entourées de l'analyse de code, de la détection de secrets, de l'analyse de binaires et du ticketing. Après : des runners CRACI qui exécutent chaque job, appliquent sa politique de trafic sortant, enregistrent sa SBOM et la gardent sous surveillance. Les outils qui lisent le code, les dépôts, les binaires et votre processus ne changent pas.

Ce que CRACI remplace, et pourquoi

Chacune de ces tâches a lieu pendant le build. CRACI peut les reprendre parce que c'est là que le build s'exécute. Pour chacune : le mécanisme, ce à quoi vous renoncez, et un exemple.

Vos runners

CRACI est un runner pour GitHub Actions. Vous remplacez runs-on par craci, et les exécutions apparaissent toujours dans GitHub comme n'importe quel autre job Actions. Chaque job dispose de sa propre machine virtuelle, sous Linux x86-64 ou ARM64, d'une taille de 1 à 32 vCPU, facturée à la seconde. Aucune réécriture de workflow : vos étapes existantes, étapes d'analyse comprises, continuent de tourner.

CRACI ne facture que les minutes de build : $0.002 par vCPU-minute ($0.004 pour un runner par défaut de 2 vCPU), facturé à la seconde, sans abonnement mensuel ni frais par SBOM. Cela en fait l'un des runners CI les plus abordables. Il exécute les builds environ deux fois plus vite que les runners hébergés par GitHub, grâce à un matériel plus rapide, des files d'attente plus courtes et le cache.

Runner, par minute	CRACI	Hébergé par GitHub	Écart
2 vCPU x64	$0.004	$0.006	CRACI environ 33 % moins cher
2 vCPU ARM64	$0.004	$0.005	CRACI 20 % moins cher
32 vCPU x64	$0.064	$0.082	CRACI environ 22 % moins cher
32 vCPU ARM64	$0.064	$0.050	CRACI 28 % plus cher

Prix catalogue de GitHub en septembre 2026. GitHub arrondit chaque job à la minute supérieure ; CRACI facture à la seconde. Exemple : un build de 10 minutes sur un runner x64 à 2 cœurs hébergé par GitHub coûte $0.060. À une vitesse environ deux fois supérieure, il prend 5 minutes sur un runner CRACI de 2 vCPU et coûte $0.020, soit environ 67 % de moins. Voir les tarifs et les tarifs des runners CI.

Ce à quoi vous renoncez. Les runners Windows et macOS, les autres systèmes CI et les runners hébergés par le client ne sont pas disponibles aujourd'hui ; GitLab CI, Jenkins, Windows, macOS et les runners hébergés par le client sont sur la feuille de route. GitHub Enterprise Server n'est pas pris en charge. Les runners sont gérés, sur une infrastructure européenne. Si vous comparez des runners gérés à votre propre flotte, consultez runners gérés ou auto-hébergés.

Les agents de trafic sortant sur les runners que vous gardez

Un agent de trafic sortant observe ou limite le trafic d'un runner exploité par quelqu'un d'autre. Sur CRACI, c'est le runner lui-même qui applique la politique de trafic sortant : refus ou autorisation par défaut, 24 préréglages intégrés de sources logicielles, des sources personnalisées typées pour les registres de paquets et Git, et des règles réseau explicites. La politique est validée avant le démarrage du job et échoue en mode fermé (fail closed), et CRACI envoie des alertes en cas de violation de la politique. Aucun agent séparé n'est nécessaire sur les runners CRACI.

Exemple : une dépendance compromise tente d'envoyer les secrets du job vers un hôte dont le build n'a jamais eu besoin. Avec une politique de refus par défaut, la connexion est bloquée, même lors d'une attaque que personne n'a encore vue, car la politique n'autorise que ce dont le build a besoin au lieu de chercher des hôtes malveillants connus.

Ce à quoi vous renoncez. La politique couvre les jobs sur les runners CRACI. Les runners que vous gardez ailleurs ont toujours besoin de leur propre contrôle.

Le générateur de SBOM dans le workflow de chaque équipe

Un générateur lit les fichiers qu'il a sous les yeux, comme un manifeste, un lockfile ou une image, et reconstitue ce qui y est entré. Des générateurs différents renvoient des listes différentes à partir du même checkout, et les équipes choisissent généralement le leur : l'organisation se retrouve avec plusieurs inventaires qui ne concordent pas.

CRACI enregistre les paquets que chaque job a réellement récupérés, y compris les paquets restaurés depuis les caches CI, ainsi que les dépendances cachées que les outils fondés sur les lockfiles manquent : le code téléchargé par les hooks d'installation npm, les scripts de build Rust qui téléchargent au moment du build, et l'image de base avec ses couches de système d'exploitation dans un build de conteneur. Chaque composant de la SBOM était dans le build. La SBOM de chaque job indique sa complétude, Complete, Complete with connections, Incomplete, Unavailable ou Not recorded, de sorte qu'une lacune est visible au lieu de passer inaperçue. Le résultat est un inventaire unique pour chaque dépôt qui construit sur CRACI, exporté en CycloneDX ou SPDX. Écosystèmes enregistrés aujourd'hui : npm, PyPI, RubyGems, Composer, Cargo, Go, Nix, OCI, apt, apk et les sources Git, ainsi que les téléchargements Yocto et OpenEmbedded.

Exemple : expressjs/express 5.2.1 ne versionne aucun lockfile. Un générateur qui résout les dépendances à partir des lockfiles n'a rien à résoudre, et peut tout de même renvoyer un document qui ne liste aucune des dépendances npm déclarées dans package.json. Un build du même projet sur CRACI enregistre les paquets que npm install a récupérés. Plus de détails sur la méthode dans les SBOM au moment du build et comparatif des outils SCA et SBOM ; pour une pile de générateurs faite maison, voir la pile SBOM DIY.

Ce à quoi vous renoncez. Les écosystèmes que CRACI n'enregistre pas encore. Maven et Java sont sur la feuille de route, et tout ce qui ne figure pas dans la liste ci-dessus n'est pas couvert. Gardez un générateur pour ces builds.

La génération de SBOM intégrée à Yocto

Yocto écrit sa propre SBOM SPDX via create-spdx, et elle est rigoureuse sur ce que BitBake construit. Elle ne voit pas ce qui se passe en dehors des métadonnées de BitBake. CRACI exécute le build BitBake et enregistre ce qu'il a récupéré. Lors d'un build comparatif de core-image-sato sur un runner ARM64 natif de 32 vCPU, la SBOM de CRACI contenait tous les composants de la SBOM de Yocto, plus 88 qu'elle avait manqués : 23 paquets hôtes sur la machine de build, 10 sources GitHub dont la GitHub Action actions/upload-artifact, et 55 autres sources et outils récupérés pendant le build. Elle a enregistré les 653 versions de crates Rust avec des package URL pkg:cargo, afin qu'elles puissent être rapprochées des avis de sécurité. Le build sans la génération de SBOM de Yocto a pris 43 % de temps en moins : environ $9.96 contre $5.68 par build au prix de CRACI.

Ce à quoi vous renoncez. Le SPDX de Yocto contient des métadonnées de recettes que CRACI n'enregistre pas : les patchs appliqués et les CVE marquées comme corrigées. Si vous en dépendez, laissez create-spdx activé. La méthode et la comparaison complète sont sur les builds Yocto sur CRACI.

Des SBOM au suivi des vulnérabilités

Un outil de suivi autonome doit être alimenté en SBOM et se fie à ce qu'on lui donne. CRACI produit la SBOM et conserve l'enregistrement. Les SBOM surveillées sont réévaluées en continu à mesure que de nouveaux avis de sécurité sont publiés. L'historique des builds montre quels builds contenaient une dépendance vulnérable, directe ou transitive, pour que vous connaissiez la période pendant laquelle vous étiez exposé, dans la limite de la durée de conservation de votre offre. Les résultats sont attribués à l'équipe responsable du correctif, CRACI informe les personnes concernées d'une vulnérabilité et de sa gravité, et les policy gates peuvent bloquer un build en fonction des résultats, y compris un build qui contient une CVE précise. VEX est pris en charge. Les SBOM fournisseurs peuvent être ajoutées, afin que les composants achetés soient surveillés aux côtés de vos propres builds.

Exemple : un avis de sécurité est publié pour une crate que l'un de vos services a compilée il y a trois mois. CRACI la rapproche de chaque SBOM surveillée et montre quels builds contenaient cette version, sans que personne n'importe quoi que ce soit à nouveau.

Ce à quoi vous renoncez. CRACI ne propose ni analyse d'atteignabilité ni indicateurs de remédiation comme le MTTR, les échéances par gravité ou les tendances du backlog. Si vous en dépendez, gardez l'outil qui les fournit. Voir le suivi des vulnérabilités pour l'ensemble de la fonctionnalité.

Le tableur

Pour les équipes sans outillage SBOM, ce que CRACI remplace, c'est l'assemblage manuel : quelqu'un copie des listes de dépendances dans un tableur avant une version ou un audit. Un build sur CRACI produit la SBOM comme effet secondaire de son exécution, la liste existe donc pour chaque build, pas seulement pour ceux auxquels quelqu'un a pensé.

Ce avec quoi CRACI fonctionne, et comment

Ces outils lisent des choses que CRACI ne lit jamais. CRACI ne lit pas votre code source à la recherche de failles, ne teste pas les services en fonctionnement et n'analyse pas les binaires qu'il n'a pas construits. Ils continuent de tourner comme aujourd'hui.

Les outils qui lisent votre code et votre dépôt

Le SAST, la détection de secrets et la protection des push, l'analyse d'extraits et de signatures, l'analyse de l'IaC et les contrôles de posture CI/CD inspectent tous votre code, vos commits ou votre configuration. Les étapes de votre workflow s'exécutent sans changement sur un runner CRACI, et les fonctionnalités au niveau du dépôt ne sont pas affectées, puisqu'elles ne se sont jamais exécutées sur le runner. Une étape d'analyse de code peut se trouver dans le même job que votre build. Le SAST est hors périmètre par choix : de nombreux excellents outils SAST fonctionnent avec CRACI. Voir SAST ou SCA pour comprendre en quoi les deux types de résultats diffèrent.

Les outils qui inspectent ce que vous n'avez pas construit

L'analyse de binaires et de firmware de fournisseurs, les scanners d'images que vous récupérez sans jamais les construire, et le DAST sur les services en fonctionnement examinent tous quelque chose qui a été construit ailleurs ou qui tourne déjà. CRACI enregistre des builds ; un binaire livré par un fournisseur a été construit dans un endroit que CRACI n'a jamais vu. Si le fournisseur vous remet une SBOM, CRACI peut la surveiller aux côtés de vos propres builds.

La priorisation fondée sur l'atteignabilité lit votre graphe d'appels, que CRACI n'analyse pas. Gardez-la si vous en dépendez ; voir l'analyse d'atteignabilité pour ce qu'elle peut et ne peut pas vous dire.

Les systèmes de processus

Le ticketing, la gestion des dossiers PSIRT, la publication d'avis de sécurité et les plateformes d'automatisation de la conformité font tourner votre processus à travers de nombreux systèmes. CRACI oriente les résultats vers l'équipe responsable et conserve les preuves issues du build ; gardez vos outils de processus pour le reste. Les enregistrements sortent de CRACI sous forme de SBOM CycloneDX ou SPDX et via l'API, qui renvoie les SBOM, les traces réseau et les données de provenance. Pour le volet audit, voir les contrôles SBOM pour SOC 2. Pour le travail sur les licences au-delà des licences déclarées, comme les mentions et la revue du texte intégral, voir la conformité des licences open source. CRACI porte la licence déclarée de chaque composant et applique les règles de politique de licences, jusqu'à bloquer un build pour une licence.

Comment trouver le point de bascule dans votre propre stack

Cinq questions auxquelles vous pouvez répondre en un après-midi. Chaque réponse vous dit si une ligne de votre stack bouge.

1. Vos builds tournent-ils sur GitHub Actions sous Linux ? Si oui, les runners bougent. Sinon, CRACI ne remplace rien aujourd'hui.
2. Qui génère les SBOM aujourd'hui, et combien de générateurs différents sont utilisés ? Chaque générateur d'un dépôt que vous passez sur CRACI est une ligne qui disparaît.
3. Construisez-vous des images Yocto ? Si oui, vérifiez si quelqu'un compte sur les patchs appliqués et les CVE corrigées dans la sortie de create-spdx avant de le désactiver.
4. Où vont les SBOM une fois générées : un outil de suivi, un tableur, nulle part ? Cet outil ou ce processus est la deuxième ligne qui disparaît, sauf si vous en attendez de l'atteignabilité ou des indicateurs de remédiation.
5. Lesquels de vos outils de sécurité lisent du code, des dépôts ou des binaires tiers ? Ceux-là restent. Notez-les, pour que personne n'attende de CRACI qu'il les remplace.

Un exemple concret

Un fabricant d'appareils fictif, qui ne s'inspire d'aucune entreprise réelle : des builds Linux sur des runners hébergés par GitHub, deux équipes utilisant deux générateurs de SBOM différents, une gamme de produits Yocto avec create-spdx activé, des SBOM rassemblées dans un tableur partagé, une suite d'analyse de code et un système de ticketing. Son équipe sécurité répond oui aux questions 1 et 3, trouve deux générateurs pour la question 2 et un tableur pour la question 4, et cite l'analyse de code, la détection de secrets et le système de ticketing pour la question 5. Personne n'utilise les métadonnées de patchs du SPDX de Yocto.

Passe sur CRACI	Reste
Les runners hébergés par GitHub pour les jobs Linux	L'analyse de code, exécutée comme étape sur les runners CRACI
Les deux générateurs de SBOM	La détection de secrets
create-spdx, puisque personne n'a besoin de ses métadonnées de patchs	Le système de ticketing
Le tableur des SBOM

Sur la ligne des runners, un build de 10 minutes qui coûte $0.060 sur un runner x64 à 2 cœurs hébergé par GitHub coûte environ $0.020 sur CRACI grâce à l'accélération. Le coût des autres outils reste à renseigner par l'entreprise elle-même.

Quand CRACI n'est pas la réponse

• Vos pipelines tournent sur GitLab CI, Jenkins, Azure DevOps ou un autre système CI. CRACI ne prend en charge que GitHub Actions aujourd'hui, avec GitLab CI et Jenkins sur la feuille de route, il ne remplace donc encore rien.
• Vos builds ont besoin de runners Windows ou macOS ou de GitHub Enterprise Server, ou doivent tourner sur votre propre infrastructure.
• Votre principal problème est le bruit de l'analyse de code dans votre propre code. C'est une question de réglage du SAST ; voir SAST ou SCA et comment réduire le bruit des vulnérabilités.
• Votre principal risque vient des firmwares et des binaires que vous recevez de fournisseurs, pas du code que vous construisez.
• Votre stack repose surtout sur Java et Maven, qui sont sur la feuille de route, ou sur .NET, qui ne figure pas dans la liste des écosystèmes que CRACI enregistre.
• Vous avez besoin dès aujourd'hui d'une priorisation fondée sur l'atteignabilité ou d'une gestion des dossiers PSIRT.

Pour une vue pas à pas du produit, voir comment fonctionne CRACI ; pour la SBOM elle-même, la génération de SBOM.

Ce que CRACI remplace : questions fréquentes

Que remplace CRACI ?

Vos runners GitHub Actions pour les jobs Linux, les générateurs de SBOM que les équipes exécutent en CI pour les builds qui passent sur CRACI, le create-spdx de Yocto pour la couverture de la chaîne d'approvisionnement, les agents de trafic sortant sur les runners, et le suivi autonome des vulnérabilités à partir des SBOM pour ces builds. Il ne remplace pas les outils qui lisent votre code, vos dépôts ou des binaires tiers.

CRACI est-il un complément à notre outil SCA, ou remplace-t-il quelque chose ?

Il remplace des tâches de la couche build : le runner, la génération de SBOM et le suivi qui découle de la SBOM. Que cela remplace votre outil SCA dépend de l'usage que vous en faites. S'il lit votre code, fait de l'analyse d'extraits ou de binaires ou vous donne l'atteignabilité, ces parties restent.

Avons-nous encore besoin de notre générateur de SBOM si nous exécutons nos builds sur CRACI ?

Pas pour les builds qui tournent sur CRACI et utilisent les écosystèmes qu'il enregistre. CRACI enregistre les paquets que chaque job a récupérés et exporte la SBOM en CycloneDX ou SPDX. Gardez un générateur pour les logiciels que vous ne construisez pas sur CRACI, comme les images que vous récupérez, et pour les écosystèmes que CRACI n'enregistre pas encore, comme Maven.

Avons-nous encore besoin de la génération de SBOM intégrée à Yocto (create-spdx) ?

Pour la couverture de la chaîne d'approvisionnement, non : lors d'un build comparatif de core-image-sato, la SBOM de CRACI contenait tous les composants de celle de Yocto, plus 88 qu'elle avait manqués, et le build sans create-spdx a pris 43 % de temps en moins. Laissez create-spdx activé si vous comptez sur ses patchs appliqués et ses CVE marquées comme corrigées, que CRACI n'enregistre pas.

CRACI remplace-t-il l'analyse de code ou la détection de secrets ?

Non. CRACI ne lit pas votre code source ni vos commits à la recherche de failles ou de secrets. Gardez ces outils. Les étapes d'analyse de code s'exécutent sans changement dans votre workflow sur un runner CRACI, et les fonctionnalités au niveau du dépôt ne sont pas affectées.

CRACI remplace-t-il l'analyse de binaires ou de firmware ?

Non. CRACI enregistre les builds qu'il exécute. Pour les firmwares et les binaires que vous recevez de fournisseurs, l'analyse de binaires est l'outil adapté. Si un fournisseur vous remet une SBOM, CRACI peut la surveiller aux côtés de vos propres builds.

Pouvons-nous garder nos étapes de sécurité existantes dans GitHub Actions sur les runners CRACI ?

Oui. CRACI remplace le runner, pas GitHub Actions : vous définissez runs-on sur craci, et vos workflows, étapes et résultats restent dans GitHub. Les étapes d'analyse, de test et toutes les autres continuent de tourner comme avant.