La sécurité de la chaîne d'approvisionnement logicielle, enregistrée à chaque build
Votre chaîne d'approvisionnement logicielle rejoint votre produit dans le build CI. CRACI exécute vos jobs GitHub Actions sur des runners sécurisés et enregistre chaque dépendance qu'ils récupèrent, contrôle ce que chaque build peut joindre et continue de suivre les vulnérabilités de ce que vous avez livré.
Des runners sécurisés pour GitHub Actions
Remplacez runs-on par craci et vos jobs GitHub Actions s'exécutent sur les runners de CRACI, leurs exécutions restant visibles dans GitHub. Chaque job dispose de sa propre machine virtuelle isolée, sous Linux x86-64 ou ARM64, hébergée en Europe. Les builds tournent environ deux fois plus vite que sur les runners hébergés par GitHub, grâce à un matériel plus rapide, des files d'attente plus courtes et la mise en cache.
Une SBOM enregistrée à chaque build
CRACI enregistre, il ne scanne pas. Un proxy qui comprend les paquets, sur le runner, voit chaque paquet que le job récupère depuis npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk et les sources Git, ainsi que les presets de téléchargement Yocto et OpenEmbedded, y compris les paquets restaurés depuis les caches CI. La SBOM de chaque job porte un état de complétude et s'exporte en CycloneDX ou SPDX avec les dépendances transitives et la licence déclarée de chaque composant.
Contrôlez ce qu'un build peut joindre
Une politique de trafic sortant détermine les hôtes auxquels un job peut se connecter : refus ou autorisation par défaut, 24 presets 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 bloque tout en cas d'échec, et toute violation déclenche une alerte. Une dépendance ou une étape de build compromise ne peut pas envoyer discrètement des données vers un hôte que vous n'avez jamais approuvé.
La provenance de ce que vous livrez
La REST API publique renvoie les SBOM, les traces réseau et la provenance de chaque job, toutes enregistrées à partir du même build. Les preuves sont issues du build lui-même, sans étape supplémentaire dans le workflow.
Le suivi des vulnérabilités après la release
CRACI réévalue en continu les SBOM de ce que vous avez livré à mesure que de nouvelles vulnérabilités sont publiées, et agrège les résultats de l'ensemble des builds et des dépôts. Les équipes sécurité les trient et transmettent chacun à l'équipe chargée de la correction. Les gates de politique peuvent bloquer un build en fonction des résultats ou d'une licence, VEX est pris en charge, les SBOM des fournisseurs sont surveillées aux côtés de vos propres builds, et la vue d'inventaire montre quelles versions logicielles sont déployées sur quels produits.
Des preuves pour les clients et les auditeurs
Clients, auditeurs et réglementations exigent de plus en plus une SBOM par release et une trace du traitement des vulnérabilités. CRACI exporte les SBOM en CycloneDX ou SPDX, y compris les vulnérabilités détectées dans leurs composants, et une REST API publique renvoie les SBOM, les traces réseau et la provenance. Ces mêmes preuves servent pour le Cyber Resilience Act de l'UE, NIS2, les exigences SBOM de la FDA et les mesures ISO 27001 relatives à la chaîne d'approvisionnement.
Les questions que soulève un incident de la chaîne d'approvisionnement
Quand un paquet, une action CI ou un registre est compromis, les premières heures servent à déterminer si vous êtes touché. Voici les questions que se posent les équipes, et comment l'enregistrement du build par CRACI y répond.
| La question | La réponse de CRACI |
|---|---|
| L'un de nos builds a-t-il récupéré la version compromise du paquet ? | La SBOM de chaque build liste les paquets que le job a réellement récupérés : vous cherchez dans les builds enregistrés au lieu de rescanner les dépôts. |
| Lesquels de nos produits et de nos releases sont touchés ? | Les SBOM surveillées sont réévaluées en continu, et la vue d'inventaire relie les versions logicielles aux produits sur lesquels elles sont déployées. |
| Une étape de build a-t-elle pu envoyer des secrets quelque part ? | La trace réseau de chaque job enregistre les connexions qu'il a établies, et la politique de trafic sortant bloque les hôtes hors politique avant qu'ils ne soient joints. |
| Cette SBOM est-elle assez complète pour être transmise ? | La SBOM de chaque job indique sa complétude : Complete, Complete with connections, Incomplete, Unavailable ou Not recorded. |
| Qui corrige, et pouvons-nous prouver que c'est traité ? | Les résultats sont triés et transmis aux équipes responsables, et les SBOM s'exportent en CycloneDX ou SPDX avec les vulnérabilités détectées dans leurs composants. |
CRACI couvre le build et ce qu'il livre. L'analyse de code, la détection de secrets et l'analyse d'atteignabilité restent du ressort de vos outils de sécurité applicative. GitHub Actions est pris en charge aujourd'hui, les autres systèmes CI figurent sur la roadmap.
La sécurité de la chaîne d'approvisionnement logicielle, en questions
Ce qu'elle couvre, pourquoi elle a sa place dans la CI/CD, et la place de CRACI
Qu'est-ce que la sécurité de la chaîne d'approvisionnement logicielle ?
La sécurité de la chaîne d'approvisionnement logicielle protège tout ce qui entre dans votre logiciel entre le premier commit et la release : dépendances open source, images de base, outils de build, actions CI tierces, le pipeline CI lui-même et les artefacts que vous livrez. Il s'agit de savoir quels sont ces éléments, de contrôler leur origine et de prouver ce qui est entré dans chaque release.
Pourquoi sécuriser la chaîne d'approvisionnement logicielle dans la CI/CD ?
C'est dans le build de release que vos dépendances sont résolues, téléchargées et empaquetées. Un build de production n'est pas le build d'un ordinateur portable : plages de versions, tags modifiables et caches font qu'il peut récupérer autre chose. Un enregistrement réalisé pendant l'exécution du build de release est la seule trace fiable de ce qui a été livré, et c'est dans le runner du build que vous pouvez contrôler ce que le build peut joindre.
En quoi CRACI diffère-t-il d'un scanner de sécurité de la chaîne d'approvisionnement ?
Les scanners lisent des fichiers après coup : un manifeste, un lockfile, du code source ou un binaire terminé. CRACI est le runner de vos jobs GitHub Actions : il observe le build en direct et enregistre les paquets que chaque job a réellement récupérés, y compris les paquets restaurés depuis les caches CI. Chaque SBOM indique sa propre complétude, une politique de trafic sortant contrôle ce que le build peut joindre, et l'API renvoie les SBOM, les traces réseau et la provenance.
CRACI remplace-t-il mes workflows GitHub Actions ?
Non. CRACI remplace le runner, pas GitHub Actions. Vous remplacez runs-on par craci, et vos workflows, vos déclencheurs et votre historique d'exécutions restent dans GitHub.
Quels systèmes CI et quelles plateformes CRACI prend-il en charge ?
GitHub Actions aujourd'hui ; d'autres systèmes CI figurent sur la roadmap, dont GitLab CI et Jenkins. Les runners tournent sous Linux en x86-64 et ARM64, Windows et macOS étant sur la roadmap.
CRACI fait-il du SAST, de la détection de secrets ou de l'analyse d'atteignabilité ?
Non. CRACI enregistre et contrôle le build, suit les vulnérabilités de ce que vous avez livré et produit les preuves. L'analyse de votre propre code à la recherche de failles ou de secrets, ainsi que l'analyse d'atteignabilité, relèvent d'un outil de sécurité applicative.
Où sont stockées mes données de build ?
CRACI est hébergé en Europe, sur une infrastructure bare metal européenne, et les données sont conservées 180 jours par défaut, avec une durée de conservation personnalisée sur Enterprise. CRACI ne stocke pas votre code source. CRACI est certifié ISO 27001 ; les détails figurent dans le Trust Center.
Découvrez ce que vos builds récupèrent réellement
Réservez une démo pour voir la SBOM, la trace réseau, la politique de trafic sortant et la provenance que CRACI enregistre pour un build GitHub Actions
Réserver une démo