Cyberrésilience automatisée pour les développeurs et les agents

Faites de chaque build votre première ligne de défense.

Placez la sécurité de la chaîne d'approvisionnement au cœur de votre logiciel, avec des runners rapides, fiables et moins chers.

Lancer votre premier build Voir comment ça marche

Runners sécurisés
SBOM générées au build
Surveillance des vulnérabilités
Réponse aux vulnérabilités

185 paquets enregistrés
6 connexions refusées
SBOM complète
Corrigé dans v2.4.1

Build

northwind-controls/web-portal

release.yml #1843 · 5d08e3b
runs-on: craci
size 2 · x86-64
Paquets
185 paquets enregistrés
- next 15.2.2
- react 19.0.0
- react-dom 19.0.0
- express 4.21.2
- tailwindcss 4.0.14
- typescript 5.8.2
Gate de politique

Build #1843 arrêté
CVE-2025-29927 · Critical
Build #1844 réussi
Corrigé dans next 15.2.3
Artefact publié

ghcr.io/northwind-controls/web-portal:2.4.1

sha256:e2b9…5c07
Publié en v2.4.1

Les équipes qui construisent avec CRACI

Les vulnérabilités arrivent plus vite que les correctifs.

Il suffit d'une seule porte d'entrée aux attaquants, et les agents les aident à la trouver plus vite que jamais. Votre équipe doit combler chaque brèche, le plus souvent à la main.

2026 à ce jour

CVE publiées par jour: 293; Une toutes les 5 minutes, en moyenne.
De plus par jour que l'année précédente: +124%; Par rapport au rythme quotidien de 2025.
De gravité élevée ou critique, chaque jour: 148; D'après leur score CVSS.

CVE publiées par jour, par année
Année	CVE par jour	Élevées ou critiques par jour
2020	39	7
2021	54	12
2022	68	20
2023	78	28
2024	109	48
2025	131	54
2026 à ce jour	293	148

D'après la liste publique des CVE, actualisée chaque jour. Choisissez une année à comparer. Lire le rapport sur les CVE

Pourquoi maintenant

Les alertes sont devenues du bruit.
Quand des centaines de résultats sont urgents, aucun ne l'est. Les équipes cessent de gérer le risque et se mettent à compter les alertes.
Le volume dépasse toutes les équipes.
Le tri et les correctifs se font encore à la main. À ce volume, recruter davantage ne comble pas l'écart.
Les correctifs rivalisent avec les fonctionnalités.
Les équipes produit sont évaluées sur les fonctionnalités livrées : le travail de sécurité attend un sprint calme qui n'arrive jamais.
Les scanners ne font qu'estimer.
Une liste reconstituée à partir de fichiers après le build passe à côté de ce qui y est réellement entré, et une fausse assurance dissuade de regarder de plus près.

Votre logiciel prend forme pendant le build.

Votre lockfile fixe ce qui devrait être installé. Le build décide de ce qui arrive réellement. CRACI enregistre chaque paquet à son arrivée, avec la version résolue, sa provenance et s'il a été restauré depuis un cache CI.

package-lock.json Ce que vous avez fixé

"packages": {
  …
  
  
  
  
  
  …
}

Ne liste que des versions, sans dire d'où vient chaque paquet ni comment il est entré.

Enregistrement du build #1842 185 paquets enregistrés

Paquets enregistrés pendant le build d'exemple #1842 de northwind-controls/web-portal, regroupés selon leur voie d'entrée dans le build.
Paquet	Résolu	Arrivé via	Source
Via package.json
express via package.json	4.21.2	package.json	registry.npmjs.org
next via package.json Désormais touché par CVE-2025-29927 · Critical	15.2.2	package.json	registry.npmjs.org
react via package.json · depuis le cache CI	19.0.0	package.json	Cache CI
react-dom via package.json · depuis le cache CI	19.0.0	package.json	Cache CI
styled-jsx via next	5.1.6	next	registry.npmjs.org
Via un script de build
tailwindcss via script de build	4.0.14	script de build	registry.npmjs.org
typescript via script de build	5.8.2	script de build	registry.npmjs.org
et 178 autres paquets enregistrés

185 paquets enregistrés · 2 restaurés depuis le cache

Sécurisez le build. Enregistrez ses dépendances.

Vos jobs tournent sur des runners CRACI au lieu des runners hébergés par GitHub, deux fois plus vite. Chaque paquet qu'ils récupèrent est enregistré avec sa version, sa source et sa licence. Tout ce qui provient d'une source hors de votre politique est refusé.

Secure Build Service

Chaque job s'exécute dans sa propre machine virtuelle isolée, derrière une politique de trafic sortant vérifiée avant le démarrage du job.

VM isolée
Sortie refusée par défaut
Bloque en cas d'échec
Alerte en cas de violation

Package Analytics

Un proxy qui comprend les paquets enregistre chaque paquet récupéré par un job, avec sa version résolue, sa source et sa licence déclarée.

npm
PyPI
RubyGems
Cargo
Go
Nix
OCI
Yocto
et d'autres

Événement de politique Build #1842

time2025-03-14 09:13:07 UTC
jobrelease.yml #1842
stepnpm run build
policyDefault deny. Allowed: npm, GitHub, ghcr.io, Docker Hub, example.com
denied malicious.example:443
reasonL'hôte ne figure pas dans la politique
actionBloqué au niveau du runner

Connexion refusée. Alerte envoyée.

Graphe de dépendances v2.4.0

Extrait de SBOM CycloneDX 1.7 · JSON

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.7",
  …
  "components": [{
    "name": "next",
    "version": "15.2.2",
    "purl": "pkg:npm/[email protected]",
    "licenses": [
      { "license": { "id": "MIT" } }
    ]
  }, …]
}

S'exporte en CycloneDX ou SPDX, dépendances transitives et vulnérabilités comprises.

CRACI voit le trafic que les scanners ne voient pas.

Les autres outils SBOM lisent le lockfile ou le résultat du build et devinent ce qui y est entré. CRACI voit ce qui entre réellement dans chaque build, y compris les dépendances cachées qu'apportent les hooks exécutés au build, les scripts de build et les images de base.

Scanner

Scanner concurrent

Méthode: Lit package-lock.json
Quand: Après le build
Voit: Ce que liste le lockfile

SBOM qu'un scanner construit à partir du lockfile du build d'exemple #1842.
Paquet	Version	Licence	Trouvé dans
next pkg:npm/[email protected]	15.2.2	MIT	package-lock.json
react pkg:npm/[email protected]	19.0.0	MIT	package-lock.json
react-dom pkg:npm/[email protected]	19.0.0	MIT	package-lock.json
express pkg:npm/[email protected]	4.21.2	MIT	package-lock.json
styled-jsx pkg:npm/[email protected]	5.1.6	MIT	package-lock.json
Absent de tout lockfile, donc absent de la SBOM
Absent de tout lockfile, donc absent de la SBOM
Absent de tout lockfile, donc absent de la SBOM

142 paquets listés 43 manquants

SBOM enregistrée

Méthode: Voit le trafic du build
Quand: Pendant le build
Voit: Ce que le build a récupéré

SBOM que CRACI enregistre à partir du trafic du build d'exemple #1842.
Paquet	Version	Licence	Récupéré depuis
next pkg:npm/[email protected]	15.2.2	MIT	registry.npmjs.org
react pkg:npm/[email protected]	19.0.0	MIT	registry.npmjs.org
react-dom pkg:npm/[email protected]	19.0.0	MIT	registry.npmjs.org
express pkg:npm/[email protected]	4.21.2	MIT	registry.npmjs.org
styled-jsx pkg:npm/[email protected]	5.1.6	MIT	registry.npmjs.org
binaire précompilé caché via hook postinstall · pkg:npm/hidden-package	—	—	registry.npmjs.org
2 téléchargements du script de build caché via script de build · pkg:generic/[email protected]?download_url=example.com/tool	—	—	example.com
40 paquets OS de l'image de base caché via Dockerfile FROM · pkg:oci/ubuntu	—	—	registry.hub.docker.com

185 paquets enregistrés 43 de plus que ce qu'indique le lockfile

Build d'exemple. Comment fonctionnent les SBOM générées au build

Reliez chaque vulnérabilité potentielle aux releases concernées.

CRACI vérifie en continu les SBOM enregistrées à la recherche de nouvelles vulnérabilités. Dans cet exemple illustratif, une vulnérabilité critique est divulguée 7 jours après la release. Suivez l'enregistrement du build, du paquet touché jusqu'au correctif de l'équipe.

Étape 1 sur 4

CVE-2025-29927 est divulguée

next est une dépendance directe, et le build #1842 en a enregistré la version exacte.

Gravité: Critical 9.1
Paquet: next
Concerné: 15.0.0 à 15.2.2
Corrigé dans: 15.2.3

Étape 2 sur 4

Une release est touchée

CRACI la rapproche de la SBOM enregistrée.

Release: web-portal v2.4.0
Correspondance: next 15.2.2, dépendance directe
SBOM: Complete

Étape 3 sur 4

Elle a été livrée sous cette image

La release, son image et sa SBOM restent liées.

Image: ghcr.io/northwind-controls/web-portal:2.4.0
Release: v2.4.0
SBOM: Suivie

Étape 4 sur 4

Le correctif a un responsable

Triez-le, attribuez-le et suivez-le jusqu'à une release corrigée.

Responsable: Équipe plateforme
Action: Mettre à jour next vers 15.2.3 et relancer le build
Corrigé dans: web-portal v2.4.1, 2025-03-22

Répondez à chaque auditeur avec des preuves.

Chaque build laisse des preuves derrière lui : les SBOM, les enregistrements de vulnérabilités et le chemin de chaque correctif jusqu'à une release. Utilisez-les pour vos démarches CRA, NIS2, ISO 27001 et SOC 2 : la question d'un auditeur se règle par un téléchargement, pas par un projet.

Composition: Une SBOM générée au build pour chaque release.

CycloneDX
SPDX
Dépendances transitives
Vulnérabilités
Licences déclarées
Traitement des vulnérabilités: Les SBOM enregistrées sont réévaluées en continu.

Tri
Correctif
Conservé avec la release
Signalement: CRACI effectue les soumissions en votre nom.

Alerte précoce
Notification
Rapport final

Cyber Resilience Act

11 septembre 2026 Les obligations de signalement s'appliquent
11 décembre 2027 Le règlement s'applique intégralement

Lire le guide du CRA

Déclaration de vulnérabilité Extrait

web-portal v2.4.0

northwind-controls/web-portal · build #1842

SBOM: CycloneDX · Complete
Build: #1842 · commit 9f3c2e1
Vulnérabilité: CVE-2025-29927 · Critical
Composant: next 15.2.2
Destinataires: CSIRT et ENISA, via la plateforme unique de déclaration du CRA

Chronologie du traitement

2025-03-14 Release construite et SBOM enregistrée
2025-03-21 Avis publié et rapproché de cette release
2025-03-21 Trié par Sécurité produit, attribué à Équipe plateforme
2025-03-22 v2.4.1 publiée avec next 15.2.3

La SBOM s'exporte en CycloneDX ou SPDX

Lancez votre premier build en 5 minutes.

Dans cette démo, nous emmenons un site TanStack Start de l'inscription jusqu'à sa première exécution sur CRACI. Nous connectons GitHub, routons les jobs avec runs-on: craci et suivons la première exécution. CRACI enregistre chaque dépendance externe récupérée par le build, signale les vulnérabilités connues et remonte chacune jusqu'au job qui l'a introduite.

Voyez comment CRACI s'intègre à votre workflow de livraison.

CRACI remplace le runner, pas GitHub Actions. Vos workflows, vos revues et vos étapes de déploiement restent inchangés.

Connectez la GitHub App

Sur tous les dépôts ou seulement ceux que vous choisissez.
Changez de runner

Indiquez runs-on: craci dans le workflow. Rien d'autre ne change.
Lancez votre prochain build

Les exécutions apparaissent toujours dans GitHub. L'enregistrement du build et la SBOM apparaissent dans CRACI.

Runners: Runners Linux managés en x86-64 et ARM64, sur une infrastructure européenne.
Builds: Docker Engine, Buildx et Compose v2. Les builds Yocto et BitBake sont documentés.
Votre code et vos données: CRACI traite le code source pendant votre build et ne le stocke pas. Les données de build sont hébergées en Europe. Le contenu des caches dépend de ce que vos workflows y enregistrent. Lire la page sécurité.
Sur la roadmap: GitLab, Jenkins et d'autres systèmes CI, les runners Windows et macOS, les runners on-prem, Maven et Java.

Lancer votre premier build Voir comment fonctionne CRACI

Les questions posées avant une démo

Compatibilité, mise en place, sécurité et traitement des données.

Quels environnements CI et écosystèmes de paquets sont pris en charge ?

GitHub Actions est l'intégration CI prise en charge aujourd'hui, et d'autres systèmes CI figurent sur la roadmap. CRACI enregistre les registres npm, PyPI, RubyGems, Cargo, Go, Nix et OCI, les dépôts de paquets Debian, Ubuntu et Alpine, ainsi que les téléchargements Git et autres sources. Maven et Java figurent sur la roadmap. Les runners tournent sous Linux en x86-64 et ARM64.

Que faut-il pour la mise en place ?

Vous connectez la GitHub App de CRACI sur tous les dépôts ou sur une sélection, et vous indiquez runs-on: craci dans votre workflow. CRACI remplace le runner, pas GitHub Actions : vos exécutions apparaissent donc toujours dans GitHub.

À quelles données CRACI accède-t-il, et où sont-elles stockées ?

La GitHub App lit votre code et vos exécutions Actions, et gère les runners qu'elle enregistre pour votre organisation. CRACI traite le code source pendant votre build et ne le stocke pas. Les données de build, y compris les métadonnées, les données de paquets, les traces réseau, les SBOM, la provenance, les caches et les journaux d'audit, sont hébergées en Europe, avec une durée de conservation personnalisée sur Enterprise. Le contenu des caches dépend de ce que vos workflows y enregistrent. En savoir plus sur la sécurité et le traitement des données.

CRACI bloque-t-il ou alerte-t-il ? Que devient un build qui enfreint une politique ?

La politique de trafic sortant est appliquée au niveau du runner. Elle est validée avant le démarrage du job et bloque tout en cas d'échec : une connexion hors politique est refusée et vous recevez une alerte. Les gates de politique peuvent aussi arrêter un build en temps réel.

Quels formats puis-je exporter ?

Les SBOM s'exportent en CycloneDX ou SPDX, dépendances transitives, vulnérabilités et licences déclarées comprises.

Qu'est-ce qui est disponible aujourd'hui, et qu'est-ce qui figure sur la roadmap ?

Disponible aujourd'hui : des runners Linux managés pour GitHub Actions, des SBOM générées au build avec leurs vulnérabilités, la politique de trafic sortant, la surveillance continue des vulnérabilités avec tri, et les gates de politique. Sur la roadmap : GitLab, Jenkins et d'autres systèmes CI, les runners Windows et macOS, et les runners on-prem.

Soutenu par