Confiance
Ce que CRACI peut atteindre et ce qu'il conserve
Passer vos builds sur un nouveau runner, c'est lui confier votre code source et vos secrets CI. Cette page explique ce dont CRACI a besoin, où votre code s'exécute, ce que nous stockons et comment garder un périmètre restreint.
Mis à jour le
Pourquoi cette question mérite une réponse franche
Un runner CI voit plus de choses que la plupart des outils de votre stack. Il récupère votre code source, installe vos dépendances et détient les secrets que vos workflows utilisent pour publier des paquets et déployer. Lorsque la GitHub Action tj-actions/changed-files a été compromise en mars 2025, la CISA a indiqué que le code malveillant avait exposé des secrets, notamment des clés d'accès, des personal access tokens GitHub, des tokens npm et des clés RSA privées. C'est sur le runner que ces secrets résident pendant l'exécution d'un job.
Avant de diriger un workflow vers CRACI, vous devez donc savoir exactement ce qu'il peut atteindre. Vous trouverez les réponses ci-dessous, et les détails dans le CRACI Trust Center et sur docs.craci.com.
À quoi sert la GitHub App
CRACI remplace le runner, pas GitHub Actions. Vous conservez vos workflows, vous remplacez la valeur de runs-on par craci pour les jobs de votre choix, et les exécutions apparaissent toujours dans l'interface GitHub. Pour cela, votre organisation installe la GitHub App CRACI.
Lors de l'installation, vous accordez à l'App l'accès soit à tous les dépôts, soit à une sélection. Seuls les dépôts auxquels vous donnez accès peuvent exécuter des workflows sur CRACI.
Les permissions exactes demandées par l'App sont listées sur l'écran d'installation de GitHub, et vous pouvez les consulter ensuite dans les paramètres de votre organisation. En bref, l'App peut lire votre code et vos exécutions Actions, et elle gère les runners qu'elle enregistre pour votre organisation.
Où votre code s'exécute
Les jobs s'exécutent dans des machines virtuelles isolées. L'exécution des builds repose sur une infrastructure bare metal européenne. Votre code source est traité dans la VM du job pendant la durée du build.
Chaque job s'exécute sur l'une de ces trois images : CRACI Slim, CRACI Slim ARM64 ou une image Ubuntu 24.04 compatible GitHub. Les runners sont uniquement Linux pour l'instant ; Windows et macOS figurent sur la roadmap.
La façon dont les jobs sont isolés, et ce qu'il advient de la VM d'un job à sa fin, sont documentés sur docs.craci.com et dans le Trust Center.
Ce que CRACI stocke, et pendant combien de temps
CRACI traite votre code source dans la VM du job pendant le build et ne le stocke pas. Il conserve les preuves qu'il enregistre sur chaque build, ainsi que les caches que vos workflows sauvegardent :
- Métadonnées de build
- Données de paquets, c'est-à-dire les dépendances récupérées par chaque job
- Traces réseau du job
- SBOM
- Enregistrements de provenance
- Caches
- Enregistrements d'audit
Un cache contient tout ce que votre workflow y place : traitez donc son contenu comme n'importe quelle autre sortie de build.
La durée de conservation par défaut est de 180 jours. Les plans Enterprise peuvent définir une durée de conservation personnalisée. La suppression et le chiffrement des données sont traités dans le Trust Center.
Hébergement et résidence des données
CRACI est hébergé en Europe et propose la résidence des données dans l'UE, avec une exécution des builds sur une infrastructure bare metal européenne. La plateforme fonctionne chez Hetzner, un fournisseur allemand, dans un data center situé à Tuusula, en Finlande. Consultez la résidence des données pour savoir quelles données CRACI traite.
Les contrôles sur le build lui-même
Un runner qui voit vos secrets doit aussi vous permettre de limiter où ils peuvent aller. Les politiques de trafic sortant de CRACI fixent, pour chaque job, une règle par défaut de refus ou d'autorisation, avec 24 presets intégrés pour les sources logicielles courantes et des sources personnalisées typées pour des registres comme npm, PyPI, Cargo, Go proxy et OCI. Vous pouvez aussi écrire 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 rejettent les champs inconnus. Des alertes signalent les violations de politique.
Le trafic sortant des jobs provient d'une plage d'adresses IP stable : vous pouvez donc autoriser les runners CRACI par adresse dans vos propres pare-feu.
Les accès au sein de votre organisation
- Les plans Enterprise prennent en charge l'authentification unique SAML, avec Google Workspace comme fournisseur d'identité.
- Un journal d'audit administrateur enregistre les actions administratives. Il est disponible dans l'interface et ne peut pas encore être exporté.
- Les tokens d'API sont créés par les administrateurs, peuvent être révoqués à tout moment et expirent au bout de 90 jours.
Comment garder un périmètre restreint
Vous n'avez pas à donner à CRACI l'accès à toute votre organisation pour l'évaluer.
- Installez l'App sur certains dépôts. Choisissez "Only select repositories" lors de l'installation de l'App et sélectionnez-en un ou deux. Vous pourrez élargir ou réduire cette sélection plus tard depuis les Settings de votre organisation, sous GitHub Apps, CRACI, Configure. La modification prend effet immédiatement.
- Migrez un job à la fois. Seuls les jobs avec
runs-on: cracis'exécutent sur CRACI. Tout le reste demeure sur le runner utilisé aujourd'hui. - Commencez par un job qui détient peu de secrets. Un job de test ou de lint vous montre la SBOM et les preuves réseau sans placer d'identifiants de publication ou de déploiement sur un nouveau runner.
- Activez une politique de trafic sortant avec refus par défaut. Autorisez les sources de paquets dont le job a besoin, et rien d'autre.
- Sachez comment partir. Dans GitHub, vous pouvez suspendre l'App, ce qui bloque ses accès tout en la laissant installée, ou la désinstaller, ce qui supprime ses accès à votre organisation.
Notre posture de sécurité
Notre page sécurité explique notre approche : documenter plutôt qu'affirmer. Le Trust Center rassemble les politiques, contrôles et documents sur lesquels repose la plateforme, et c'est là que vous pouvez demander des éléments pour une évaluation fournisseur.
Cette page ne revendique aucune certification. Pour connaître l'état actuel de notre programme de sécurité et de tout travail d'audit, consultez le Trust Center.
Une question à laquelle cette page ne répond pas ? Envoyez-la via le Trust Center ou contactez-nous. Les acheteurs Enterprise peuvent aussi contacter l'équipe commerciale.
Examinez CRACI avec votre équipe de sécurité
Réservez une démo et apportez vos questions d'évaluation fournisseur. Nous passerons en revue les accès, l'isolation et le traitement des données sur un vrai build.
Réserver une démo