124% de CVE signalées en plus par jour en 2026 par rapport à l'an dernier.

Plateforme

Comment fonctionne CRACI

CRACI exécute vos builds GitHub Actions et enregistre ce que chacun récupère. Tout le reste, du suivi des vulnérabilités aux preuves CRA, repose sur cet enregistrement.

Mis à jour le

Vue d'ensemble de la plateforme CRACI. Le code source sur GitHub passe par GitHub Actions jusqu'au CRACI Secure Build Service. Le build alimente CRACI Package Analytics, puis Vulnerability Analysis (qui reçoit aussi des données de fournisseurs tiers), Digital Inventory et Compliance Reporting, qui rend compte à des tiers tels que les clients, les fournisseurs et l'ENISA. Le build alimente également CRACI Attack Prevention. Attack Prevention et Digital Inventory mènent tous deux au déploiement en préproduction et en production.
La plateforme CRACI, de gauche à droite. Ouvrir le schéma en taille réelle.

En bref

La plupart des outils de sécurité examinent votre code ou vos manifestes après coup et en déduisent ce qu'un build contenait probablement. CRACI est le runner du build : il voit ce que le build a réellement récupéré, au moment même où il l'a récupéré. Cet enregistrement alimente tout ce qui figure sur le schéma : analyse des paquets, prévention des attaques, analyse des vulnérabilités, traçabilité et reporting de conformité.

Vous conservez GitHub et GitHub Actions. Le changement tient en une ligne dans chaque workflow :

Switching a GitHub Actions job to CRACI A workflow file with a build job. The line runs-on: ubuntu-latest changes to runs-on: craci. That is the only change, and the job's runs still show up in GitHub. .github/workflows/build.yml jobs: build: runs-on: ubuntu-latest ubuntu-lates ubuntu-late ubuntu-lat ubuntu-la ubuntu-l ubuntu- ubuntu ubunt ubun ubu ub u c cr cra crac craci ✓ One line per job. Runs still show up in GitHub.

Étape par étape

1. Code source et CI/CD : GitHub et GitHub Actions

Votre code reste sur GitHub. Vous connectez votre organisation en installant la GitHub App de CRACI, sur tous les dépôts ou seulement ceux que vous choisissez. Les workflows continuent de s'exécuter depuis GitHub Actions et leurs exécutions apparaissent toujours dans GitHub. GitHub Actions est l'intégration CI prise en charge aujourd'hui ; la prise en charge d'autres systèmes CI/CD figure sur la roadmap.

2. Build : CRACI Secure Build Service

Les jobs s'exécutent sur des runners CRACI, dans des machines virtuelles isolées. Les runners vont de 1 à 32 unités de calcul (1 vCPU et 3 Go de RAM chacune), en x86-64 et ARM64 natifs, avec une image Ubuntu compatible GitHub ou les images allégées de CRACI. L'utilisation est mesurée à la seconde.

Les builds tournent environ deux fois plus vite sur CRACI que sur les runners hébergés standard de GitHub. Chaque minute coûte aussi moins cher : un runner Linux standard à 2 vCPU revient à $0.004 par minute, contre $0.006 chez GitHub (environ 33 % de moins). Au total, un build qui prend 10 minutes sur GitHub se termine en 5 minutes environ sur CRACI et coûte environ 67 % de moins. CRACI facture en outre à la seconde au lieu d'arrondir chaque job à la minute supérieure : les pipelines composés de nombreux jobs courts économisent davantage. Voir la comparaison complète avec les runners hébergés par GitHub.

One 10-minute build, GitHub-hosted runner versus CRACI On a GitHub-hosted 2-core Linux runner, a 10-minute build at $0.006 per minute costs $0.060, and each job is rounded up to a whole minute. On CRACI, the same build takes about 5 minutes at $0.004 per minute and costs $0.020, billed per second. That is about 67 percent less. GitHub-hosted runner standard 2-core Linux x64 build time 10 min per minute $0.006 cost of the build $0.060 CRACI size 2, Linux x64 build time about 5 min per minute $0.004 cost of the build $0.020 About 2x faster and about 67% less per build Billed per second; GitHub rounds jobs up to a minute.

3. Découverte de la chaîne d'approvisionnement : CRACI Package Analytics

Pendant l'exécution du job, un proxy qui comprend les paquets observe le trafic vers les sources de paquets et enregistre chaque dépendance externe récupérée par le build, sur npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk et les sources Git, ainsi que les presets de téléchargement Yocto et OpenEmbedded. Les preuves suivent les caches CI : les paquets restaurés depuis un cache sont donc eux aussi pris en compte.

C'est la différence avec les autres outils SBOM. Ils lisent le lockfile ou le résultat du build et en déduisent ce qui y est entré. CRACI voit le trafic : il enregistre donc aussi les dépendances cachées qu'aucun lockfile ne liste, comme le code téléchargé par les hooks de npm install, les fichiers que les scripts de build Rust récupèrent au moment du build et les couches de l'image de base d'un build de conteneur.

How a scanned SBOM and a recorded SBOM are made Left, a scanner: it reads the lockfile after the build, which lists packages A to E, so its SBOM contains A to E. The build also fetched code through an install hook, a build script download and a base image, which are in no lockfile, so the scanned SBOM is missing them. Right, CRACI: it sees the traffic coming into the build, so all eight packages, including the three hidden dependencies, land in the recorded SBOM. Scanner reads files after the build package-lock.json A B C D E the build also fetched install hook download build script download base image layers in no lockfile, so the scan never sees them Scanned SBOM A B C D E missing missing missing CRACI sees the traffic into the build the network build job on CRACI every package that comes in Recorded SBOM A B C D E install hook build script base image hidden ones too
A scanner can only list what the lockfile or the output declares. CRACI sees what actually came into the build, including the hidden dependencies.

Chaque job et chaque cache reçoit un état de complétude, de Complete à Not recorded : vous savez ainsi quel crédit accorder à la SBOM produite. Les SBOM s'exportent en CycloneDX ou SPDX, dépendances transitives comprises.

4. Sécurité continue de la chaîne d'approvisionnement : CRACI Attack Prevention

La couche qui enregistre le trafic le contrôle aussi. Une politique de trafic sortant détermine les hôtes qu'un job peut joindre, avec un refus ou une autorisation par défaut, des presets intégrés pour les sources logicielles courantes et des règles personnalisées pour les vôtres. Les politiques sont validées avant le démarrage du job et bloquent tout en cas d'échec, et CRACI vous alerte en cas de violation. Une dépendance ou un outil de build compromis qui tente de contacter son serveur est arrêté au niveau du runner.

Comme la politique n'autorise que ce dont le build a besoin, au lieu de rechercher des hôtes malveillants connus, elle fonctionne aussi contre une attaque que personne n'a encore vue. Si un ver comme Shai-Hulud atteint d'abord votre build, sa tentative d'exfiltrer vos secrets est bloquée malgré tout.

What happens when malware in a build tries to send your secrets out Left, a runner that allows all outbound traffic: the build reaches its package registry and publishes its output, then a malicious install hook sends the build's secrets to an attacker's server, and they arrive. Right, CRACI with a default-deny egress policy: the registry and publish connections are allowed, the connection to the attacker's server is blocked at the policy, and an alert is sent. The policy allows only what the build needs, so it works even against an attack nobody has seen before. Any outbound allowed build job holds your tokens and keys malicious install hook runs no egress policy package registry publish output attacker server allowed allowed secrets sent to the attacker CRACI default-deny egress policy build job on CRACI holds your tokens and keys malicious install hook runs egress policy: only what the build needs package registry publish output attacker server allowed allowed blocked blocked, and you get an alert
The policy allows only what the build needs, instead of looking for known-bad hosts, so it stops a new attack the first time it runs.

5. Réponse continue sur la chaîne d'approvisionnement : CRACI Vulnerability Analysis

Les paquets enregistrés sont confrontés aux vulnérabilités connues, et les SBOM surveillées sont réévaluées en continu : une vulnérabilité divulguée après la livraison vous parvient quand même. Des vues à l'échelle de l'organisation montrent quels builds et quels dépôts partagent une dépendance vulnérable, et les équipes sécurité peuvent trier chaque résultat et le transmettre à l'équipe chargée de la correction. Vous pouvez aussi ajouter les SBOM de vos fournisseurs tiers, afin que les composants que vous achetez soient surveillés aux côtés de ceux que récupèrent vos propres builds.

Using SBOMs for improved cybersecurity

Comment une SBOM de build devient une surveillance des vulnérabilités après la publication, la tâche qu'assurent la génération de SBOM et le suivi des vulnérabilités de CRACI.

Petteri Pulkkinen et Erika Marttinen lors de Kubernetes Community Days Helsinki 2026, 22:11 à 23:27 de SBOMbastic: Getting Ready for Upcoming EU Cybersecurity Regulation in Software Supply Chains.

6. Traçabilité de la chaîne d'approvisionnement : CRACI Digital Inventory

Chaque build dispose de sa SBOM et de la trace réseau des connexions qu'il a établies, et l'API CRACI renvoie les SBOM, les traces réseau et la provenance. Quand une nouvelle vulnérabilité ou un paquet compromis fait l'actualité, vous savez depuis un seul endroit lesquels de vos builds sont touchés.

A new vulnerability, traced back through build history Eight releases, v1.0 to v1.7, are built and recorded over time. Today a new advisory is published for example-lib 2.3.1. CRACI's build history shows that v1.2 and v1.3 contained it as a transitive dependency and v1.4 and v1.5 as a direct one, while v1.6 and v1.7 already shipped a fixed version. The exposure period is v1.2 to v1.5, answered from the recorded SBOMs without rescanning old code. Build history every build keeps its recorded SBOM New advisory today example-lib 2.3.1 today v1.0 v1.1 v1.2 v1.3 v1.4 v1.5 v1.6 v1.7 v1.2 transitive v1.3 transitive v1.4 direct v1.5 direct fixedfixed exposure period: v1.2 to v1.5 Answered from the recorded SBOMs, without rescanning old code
CRACI keeps re-evaluating the SBOMs of what you shipped. Build history follows your retention, 180 days by default.

7. Reporting sur la chaîne d'approvisionnement : CRACI Compliance Reporting

Les preuves recueillies en chemin vont à ceux qui les demandent : clients, fournisseurs et autorités. Les SBOM s'exportent en CycloneDX ou SPDX, y compris les vulnérabilités détectées dans leurs composants, l'API renvoie les SBOM, les traces réseau et la provenance, et CRACI soumet en votre nom les notifications de vulnérabilités exigées par le CRA.

Le Cyber Resilience Act est la réglementation la plus connue derrière ces exigences, mais pas la seule. D'un cadre à l'autre, la demande est la même : savoir ce que contient votre logiciel et disposer d'un processus pour en trouver et en traiter les vulnérabilités.

  • Cyber Resilience Act de l'UE : une SBOM et un traitement des vulnérabilités pour les produits comportant des éléments numériques vendus dans l'UE, avec des obligations de signalement à partir de septembre 2026.
  • NIS2 : sécurité de la chaîne d'approvisionnement, traitement et divulgation des vulnérabilités pour les entités essentielles et importantes.
  • ISO/IEC 27001 : ne cite pas les SBOM, mais ses mesures de l'annexe A exigent un inventaire des actifs (5.9), la sécurité dans la chaîne d'approvisionnement TIC (5.21) et la gestion des vulnérabilités techniques (8.8). Les SBOM générées au build et la surveillance continue constituent des preuves pour les trois.
  • FDA (États-Unis) : une SBOM dans les dossiers de soumission avant mise sur le marché des dispositifs médicaux connectés, ainsi qu'un plan de surveillance et de traitement des vulnérabilités après la mise sur le marché.
  • Executive Order 14028 (États-Unis) : des SBOM pour chaque produit et un processus de divulgation des vulnérabilités, dans les recommandations sur la chaîne d'approvisionnement logicielle destinées aux fournisseurs de l'administration fédérale.

CRACI vous fournit les SBOM et la surveillance continue des vulnérabilités qu'attendent ces cadres, ainsi que les preuves qui étayent vos déclarations de conformité. Se conformer à chaque cadre reste votre processus ; CRACI en automatise la partie preuves.

8. Déploiement : préproduction et production

Ce qui arrive en préproduction et en production a été construit sous votre politique réseau, avec une SBOM enregistrée pendant le build et surveillée après la mise en production pour détecter de nouvelles vulnérabilités.

Pour aller plus loin

Découvrez CRACI sur votre propre pipeline

Réservez une démo et nous passerons en revue vos builds, vos SBOM et vos preuves de conformité.

Réserver une démo