Votre application est peu risquée. Votre pipeline de build, non.

Le raisonnement tient, jusqu'à un certain point

Nous l'entendons souvent, et cela part généralement d'un raisonnement sensé. L'application est un tableau de bord interne, un pipeline de données ou un petit service avec une poignée d'utilisateurs. Elle ne contient rien qui intéresse un attaquant. Le budget de sécurité va d'abord au produit destiné aux clients.

Cette logique vaut pour l'application. Elle ne vaut pas pour la façon dont l'application est construite. Toute équipe, quoi qu'elle livre, possède un pipeline CI contenant des identifiants et un arbre de dépendances qu'elle n'a pas écrit. Ces éléments valent la peine d'être attaqués parce qu'ils sont partagés, et une compromission à ce niveau atteint tout ce que ces identifiants permettent de toucher : vos registres, vos comptes cloud et vos autres dépôts.

Des attaques indifférentes à ce que fait l'application

Aucun de ces incidents ne visait un type d'application particulier. Chacun a atteint les équipes par un outil ou un paquet qu'elles utilisaient pour construire leurs logiciels.

tj-actions/changed-files, 2025

Une GitHub Action très utilisée, qui détecte les fichiers modifiés, a été compromise. Selon la CISA, des versions malveillantes ont été en ligne entre le 12 et le 15 mars 2025, et la compromission a 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. Wiz a indiqué que le code vidait la mémoire du runner CI : sur les dépôts publics, les secrets se sont donc retrouvés dans les journaux de workflow. Les workflows qui référençaient l'action par un tag de version ont exécuté le code malveillant, quel que soit le contenu du dépôt.

Ver npm Shai-Hulud, 2025

En septembre 2025, la CISA a alerté sur un ver auto-répliquant ayant compromis plus de 500 paquets npm. Il récoltait des personal access tokens GitHub et des clés d'API cloud pour AWS, Google Cloud et Azure. Unit 42 de Palo Alto Networks a décrit comment il utilisait des tokens npm volés pour publier des versions infectées des autres paquets de la victime, et comment une vague ultérieure s'exécutait pendant la pré-installation, ce qui a étendu sa portée aux pipelines CI/CD.

3:27

Codecov Bash Uploader, 2021

Un attaquant a extrait un identifiant grâce à une erreur dans le processus de build de l'image Docker de Codecov et a modifié le script Bash Uploader que de nombreuses équipes exécutaient en CI. Du 31 janvier au 1er avril 2021, le script altéré pouvait envoyer à un tiers des variables d'environnement, y compris les identifiants, tokens et clés disponibles dans l'environnement CI. L'attaque a été découverte lorsqu'un client a remarqué que la somme de contrôle du script ne correspondait pas.

xz utils, 2024

Du code malveillant a été intégré aux versions 5.6.0 et 5.6.1 de XZ Utils, une bibliothèque de compression de données susceptible d'être présente dans les distributions Linux. La CISA a conseillé de revenir à une version non compromise comme la 5.4.6 et de rechercher toute activité malveillante. Une bibliothèque de compression est à peu près la dépendance la moins prestigieuse qui soit, et elle a tout de même été visée.

event-stream, 2018

Une personne se faisant passer pour un mainteneur serviable a pris le contrôle du populaire paquet npm event-stream et y a ajouté une dépendance malveillante, flatmap-stream, dans la version 3.3.6. L'équipe npm a indiqué que la charge utile visait une application précise, le portefeuille bitcoin Copay. Tous les autres utilisateurs d'event-stream ont eux aussi reçu le code malveillant.

Ce que ces incidents ont en commun

• Ils se sont produits au moment du build ou de l'installation. Le code malveillant s'est exécuté sur les machines des développeurs et les runners CI, pas dans l'application en production.
• Ils visaient les identifiants. Les tokens et les clés du pipeline étaient le butin, car ils ouvrent des portes au-delà du projet en cours de build.
• Ils sont arrivés sous des noms de confiance. Une action familière, un paquet familier, un script familier. Personne n'a choisi d'installer un logiciel malveillant.
• La première question a ensuite été la même. Un de nos builds a-t-il récupéré la mauvaise version, et qu'a-t-elle pu atteindre ? Les équipes sans trace de ce que chaque build avait utilisé ont dû le reconstituer.

À quoi ressemble l'effort minimal

Vous n'avez pas besoin d'une équipe de sécurité pour couvrir les bases. L'essentiel des conseils de GitHub et de la CISA tient en une courte liste :

1. Épinglez les GitHub Actions tierces sur un SHA de commit complet plutôt que sur un tag, pour qu'un tag déplacé ne puisse pas changer ce qui s'exécute.
2. Commitez les lockfiles et épinglez les versions de dépendances sur des releases reconnues comme saines.
3. Donnez aux tokens CI les permissions les plus restreintes possibles, et renouvelez-les lorsqu'un incident touche un élément que vous utilisez.
4. Exigez une authentification multifacteur résistante au hameçonnage sur les comptes de développement et de publication.
5. Gardez une trace de ce que chaque build a installé, pour pouvoir répondre à la question « avons-nous été touchés ? » à partir de données plutôt que de souvenirs.

Les quatre premiers points relèvent de la configuration. Le cinquième est celui que la plupart des petites équipes laissent de côté, car il nécessite des outils.

La place de CRACI, pour peu d'efforts

CRACI prend en charge la tenue des traces et ajoute une frontière réseau, sans vous demander de modifier votre application ni vos workflows.

• Une ligne par job. Remplacez la valeur de runs-on par craci. Vos workflows GitHub Actions restent tels quels, et les exécutions apparaissent toujours dans GitHub.
• Une SBOM pour chaque build. CRACI enregistre les paquets réellement récupérés par chaque job, y compris les paquets restaurés depuis les caches, et exporte le résultat en CycloneDX ou SPDX.
• Une trace réseau par job. Lorsqu'un incident est annoncé, vous pouvez vérifier quels builds ont récupéré le paquet concerné et à quoi chaque job s'est connecté.
• Une politique de trafic sortant que vous pouvez passer en refus par défaut. Autorisez les sources de paquets dont un job a besoin, et une étape compromise aura moins d'endroits où envoyer ce qu'elle trouve. Les politiques bloquent tout en cas d'échec, et les violations déclenchent une alerte.
• Réévaluation continue. Les SBOM surveillées sont revérifiées à mesure que de nouvelles vulnérabilités sont publiées : un ancien build ne reste pas « propre » simplement parce que personne ne l'a regardé.

Soyons clairs sur les limites : une politique de trafic sortant n'aurait pas empêché la compromission de tj-actions d'afficher des secrets dans un journal public, et aucun outil n'annule la fuite d'un token. L'épinglage et le renouvellement restent importants. Ce que CRACI change, c'est la rapidité avec laquelle vous pouvez déterminer si vous avez été exposé, et jusqu'où peut aller une étape compromise.

Pour lancer un premier workflow, il suffit d'installer la GitHub App et de changer une ligne en runs-on: craci.

Ce que ça coûte

CRACI ne facture que les minutes de build : $0.002 par minute vCPU ($0.004 pour un runner par défaut à 2 vCPU), mesurée à la seconde, sans frais mensuels ni frais par SBOM. Consultez les tarifs pour toutes les conditions. Les startups éligibles peuvent candidater au programme startup pour bénéficier d'au moins 100k minutes de build gratuites et d'un accompagnement personnalisé à la prise en main.

Si vous vendez des logiciels dans l'UE, il vaut aussi la peine de vérifier si le Cyber Resilience Act s'applique à vous. Notre guide du CRA explique son champ d'application et ses échéances.