Pendant des années, les programmes de sécurité applicative se sont concentrés sur les environnements de production : durcissement des serveurs, correction des vulnérabilités, déploiement de WAFs et surveillance du comportement en temps réel. Cette approche était logique lorsque la plupart des compromissions significatives se produisaient après le déploiement, en exploitant les faiblesses des applications en cours d’exécution.
Mais les attaquants modernes contournent de plus en plus les défenses de production. Au lieu d’attaquer l’application au moment de l’exécution, ils compromettent les systèmes qui construisent, empaquettent et livrent les logiciels : les pipelines CI/CD et la supply chain logicielle qui les sous-tend.
Dans de nombreuses organisations, les pipelines CI/CD constituent désormais une cible plus précieuse et plus fragile que la production elle-même. La raison est simple : les pipelines se situent à l’intersection de la confiance, des privilèges et de la distribution. Si les attaquants parviennent à contrôler le pipeline, ils peuvent contrôler ce qui atteint la production — et ce qui atteint les utilisateurs.
Cet article explique pourquoi les pipelines sont devenus une surface d’attaque principale, ce que les incidents récents de supply chain nous enseignent, en quoi la sécurité des pipelines diffère de la sécurité en production, et quelles erreurs de conception courantes rendent les pipelines vulnérables. La conclusion est claire : le pipeline est une frontière de confiance, et il doit être conçu en conséquence.
L’évolution des attaques logicielles
Les menaces classiques de sécurité applicative ciblaient les vulnérabilités en production : injection SQL, RCE, SSRF, contournement d’authentification et escalade de privilèges. Les défenseurs ont passé deux décennies à augmenter le coût de ces attaques grâce à :
- Une meilleure gestion des correctifs, l’analyse des dépendances et la gestion des vulnérabilités
- Des contrôles de sécurité cloud-native et une infrastructure managée
- Une meilleure isolation (conteneurs, sandboxes, segmentation)
- Des capacités centralisées de journalisation et de détection
En conséquence, les adversaires se sont adaptés. Si la production devient plus difficile à exploiter directement, les attaquants cherchent un levier ailleurs — et le processus de livraison logicielle offre ce levier.
Au lieu de se demander « Comment pénétrer ce système en cours d’exécution ? », les attaquants se demandent de plus en plus :
Comment faire en sorte que mon code soit livré comme s’il était légitime ?
Lorsque cela se produit, les défenses conçues pour les compromissions en production peuvent devenir sans objet. Une mise à jour malveillante délivrée par des canaux légitimes n’est pas une « brèche » au sens traditionnel — elle peut ressembler à une opération normale.
Trois incidents qui illustrent cette évolution
Les incidents majeurs de supply chain ne se sont pas produits parce que les défenses en production étaient faibles. Ils se sont produits parce que les attaquants ont compromis des mécanismes de livraison situés en amont de la production. Les détails diffèrent, mais le schéma est constant : compromettre une étape de build ou de distribution de confiance, et vous héritez de cette confiance à grande échelle.
SolarWinds : compromettre le build et atteindre tout le monde
Lors de l’incident SolarWinds, les attaquants ont réussi à injecter du code malveillant dans les mises à jour logicielles. La caractéristique déterminante n’était pas un serveur unique exploité — c’était la capacité de distribuer un logiciel backdooré via un canal de mise à jour de confiance.
Le retour sur investissement de l’attaquant était massif : compromettre le pipeline de build ou de release une seule fois, puis laisser les clients installer votre payload à votre place.
Codecov : compromettre l’outillage CI et voler des secrets à grande échelle
Lors de l’incident Codecov, une compromission a affecté la manière dont les environnements CI géraient un script. L’impact pratique : les systèmes CI exécutés dans de nombreuses organisations ont divulgué des informations sensibles.
Les environnements CI sont extrêmement sensibles car ils contiennent généralement :
- Des tokens de dépôt
- Des identifiants cloud
- Des clés de signature ou un accès aux services de signature
- Des secrets de déploiement
Cet incident souligne que l’outillage CI n’est pas « juste de l’automatisation » — c’est un système de traitement de secrets à haute valeur.
3CX : compromettre un fournisseur et instrumentaliser la confiance
L’incident 3CX a démontré une autre dynamique de supply chain : compromettre un fournisseur et instrumentaliser la confiance pour distribuer des logiciels malveillants aux clients en aval.
Du point de vue de la défense, la leçon ne se limite pas aux fournisseurs. En interne, votre pipeline CI/CD est en fait un « fournisseur » pour votre environnement de production et pour vos utilisateurs : la production fait confiance aux sorties du pipeline.
Pourquoi le pipeline est plus attractif que la production
Les attaquants choisissent leurs cibles en fonction de l’effet de levier. Les pipelines CI/CD offrent un effet de levier que les systèmes de production égalent rarement.
1) Les pipelines agrègent la confiance
Un pipeline est le tissu connectif entre :
- Les dépôts de code source (Git)
- Les registres de dépendances (npm, PyPI, Maven, etc.)
- Les systèmes de build et les runners
- Les dépôts d’artefacts (registres de conteneurs, dépôts de packages)
- Les systèmes de signature et les métadonnées de provenance
- Les cibles de déploiement (Kubernetes, comptes cloud, serveurs de production)
Compromettre la production vous donne généralement accès à un seul environnement. Compromettre le pipeline peut vous donner :
- Un accès à de multiples environnements via les identifiants d’automatisation
- Le contrôle des artefacts de release
- Une influence sur ce qui est déployé et quand
Les pipelines sont des « multiplicateurs de confiance » : ils peuvent prendre des entrées non fiables et produire des sorties de confiance. Si les attaquants contrôlent cette transformation, ils contrôlent la confiance.
2) Les pipelines fonctionnent avec des privilèges élevés par conception
L’automatisation nécessite des privilèges. Les pipelines requièrent souvent des permissions pour :
- Lire et écrire dans les dépôts (y compris les tags et les releases)
- Télécharger des dépendances et publier des artefacts
- Accéder aux secrets pour la signature ou le déploiement
- Déployer en staging ou en production
Dans de nombreuses organisations, les identités de pipeline deviennent des « super identités » au fil du temps, car il est plus facile d’accorder un accès large que de concevoir des permissions granulaires.
Cela crée une stratégie prévisible pour l’attaquant : compromettre l’identité du pipeline au lieu de combattre les défenses de production.
3) La compromission de pipeline passe mieux à l’échelle
La compromission en production passe souvent mal à l’échelle : vous devez exploiter les cibles de manière répétée, gérer la variabilité entre les environnements et maintenir la persistance par cible.
La compromission de pipeline passe efficacement à l’échelle : injecter une seule fois, distribuer partout. Si vous pouvez modifier une étape de build, un chemin de résolution de dépendances ou un artefact de release, vous pouvez compromettre de nombreux systèmes tout en paraissant légitime.
4) La détection est plus difficile car « tout semble normal »
Les outils de sécurité en production recherchent des comportements suspects au moment de l’exécution : appels réseau inattendus, escalades de privilèges, processus anormaux. Mais si du code malveillant est livré sous forme de release normale, il s’exécute dans le cadre du comportement attendu de l’application.
Sans contrôles d’intégrité solides et sans provenance, les défenseurs peuvent avoir du mal à répondre à cette question :
Ce binaire ou ce conteneur est-il réellement ce que nous avions l’intention de construire ?
Sécurité du pipeline vs sécurité en production
Une idée reçue courante est que la sécurité du pipeline est simplement « la sécurité en production appliquée plus tôt dans le cycle de vie ». Cette vision est incomplète. La sécurité du pipeline et la sécurité en production protègent des garanties différentes.
La sécurité en production répond à :
Que fait ce système en ce moment, et est-ce malveillant ?
La sécurité du pipeline répond à :
Pourquoi devrions-nous faire confiance à ce logiciel ?
Si le pipeline est compromis, les défenses en production pourraient fidèlement protéger une application malveillante, car du point de vue du système, c’est « l’application ». La véritable défaillance s’est produite en amont, au point où la confiance a été établie.
C’est pourquoi la sécurité de la supply chain se concentre sur :
- L’intégrité des sorties de build
- La provenance (qui ou quoi l’a construit, où et comment)
- Les portes de vérification avant le déploiement
- La réduction de la capacité à altérer les étapes de build et de release
Où les pipelines sont réellement vulnérables
Pour sécuriser les pipelines, nous devons être précis sur les points d’attaque. « CI/CD » n’est pas un composant unique. C’est une chaîne de composants et de transitions de confiance. Voici les points d’attaque les plus courants.
Source : pull requests et contributions non fiables
De nombreux pipelines exécutent du code provenant de pull requests. Si le pipeline traite le code des PR comme étant de confiance (ou divulgue des secrets aux builds de PR), les attaquants peuvent exfiltrer des identifiants ou modifier les sorties de build.
Dépendances : confiance transitive à l’échelle d’Internet
Les builds modernes récupèrent des centaines ou des milliers de dépendances tierces. Une dépendance compromise, un package de typosquatting ou une confusion de dépendances peuvent détourner l’exécution à l’intérieur de l’environnement de build — souvent sans toucher votre code source.
Configuration du pipeline : du « code » souvent moins bien révisé
Les définitions CI (workflows YAML, templates partagés, actions réutilisables) contrôlent l’exécution. Un changement subtil peut :
- Étendre les permissions
- Introduire une exfiltration de données
- Changer les sources d’artefacts
- Désactiver les contrôles de sécurité
Pourtant, la configuration CI reçoit parfois une révision moins rigoureuse que le code applicatif.
Runners : l’environnement d’exécution est une frontière de sécurité
Les runners hébergés, les runners auto-hébergés et les conteneurs éphémères ont tous des profils de risque différents. Mais le point essentiel est universel : les runners exécutent des entrées non fiables. Si les runners ne sont pas correctement isolés, ils deviennent un point d’ancrage pour l’attaquant.
Artefacts : l’intégrité et la provenance sont souvent présumées, jamais prouvées
De nombreuses organisations partent du principe que « si ça vient du CI, c’est sûr ». C’est précisément l’hypothèse que les attaquants exploitent. Sans signatures, attestations et portes de vérification, l’intégrité des artefacts est fragile.
Erreurs courantes de conception des pipelines
La plupart des compromissions de pipelines réussissent en raison d’erreurs d’ingénierie prévisibles — généralement motivées par la rapidité, la commodité ou un manque de clarté dans la responsabilité. Ces erreurs créent des violations de confiance silencieuses.
Erreur n°1 : Traiter les runners CI comme « internes et de confiance »
Les runners fonctionnent souvent au sein de réseaux de confiance et ont accès à des ressources sensibles. Mais ils exécutent du code qui peut être influencé par des contributeurs externes, des dépendances ou des actions tierces. Si le runner est compromis, l’attaquant peut :
- Voler des secrets depuis les variables d’environnement
- Extraire des tokens depuis la configuration locale
- Modifier les sorties de build
- Persister via les caches, les images ou les volumes partagés
Erreur n°2 : Des identités de pipeline sur-privilégiées
Les tokens à permissions larges (par exemple, des tokens de dépôt « write-all », des identifiants cloud multi-environnements) sont courants. Ils facilitent l’automatisation — mais ils offrent aussi aux attaquants un chemin rapide vers l’impact.
Erreur n°3 : Des frontières faibles entre les étapes du pipeline
Si une étape précoce peut influencer les artefacts utilisés par les étapes ultérieures sans vérification d’intégrité, l’empoisonnement d’artefacts devient trivial. Cela inclut :
- Des caches de build non vérifiés
- Des espaces de travail partagés entre les jobs
- Des artefacts transmis entre les étapes sans contrôle
Erreur n°4 : Des composants tiers non contrôlés
Les actions réutilisables, les plugins et les templates sont puissants. Mais ils ajoutent aussi un risque de supply chain au sein même du CI. Si les composants tiers ne sont pas épinglés, révisés et contraints, ils deviennent un vecteur d’exécution.
Erreur n°5 : Des « contrôles de sécurité » qui ne bloquent pas le déploiement
L’analyse de sécurité qui ne bloque pas les releases est souvent considérée comme « suffisante ». Du point de vue de l’attaquant, elle est sans importance. Les contrôles doivent être exécutoires : ils doivent affecter ce qui peut être construit, signé et déployé.
Le pipeline est une frontière de confiance
Le bon modèle mental n’est pas « le CI/CD comme automatisation ». C’est le CI/CD comme frontière de confiance.
Une frontière de confiance est l’endroit où des entrées non fiables deviennent des sorties de confiance. C’est exactement ce que fait un pipeline :
- Il prend du code source (potentiellement influencé par de nombreux acteurs)
- Il résout les dépendances (souvent depuis des écosystèmes externes)
- Il exécute les instructions de build
- Il produit des artefacts auxquels la production fera confiance
Si vous ne rendez pas la confiance explicite, vous obtenez une confiance implicite. La confiance implicite est ce que les attaquants monétisent.
Concevoir le pipeline comme une frontière de confiance signifie :
- Des frontières d’étapes explicites avec isolation et vérification entre elles
- Le moindre privilège pour les identités de pipeline, par job et par environnement
- Une exécution éphémère (ou une isolation forte) pour les runners et les builds
- L’intégrité cryptographique des artefacts (signature et vérification)
- La provenance et les attestations vérifiables au moment du déploiement
Ce que doit inclure une stratégie de sécurité moderne
Si les pipelines sont des surfaces d’attaque principales, les programmes de sécurité doivent investir en conséquence. Non pas en ajoutant plus de « contrôles », mais en intégrant des garanties solides dans le processus de livraison.
1) Modéliser les menaces du pipeline (pas seulement de l’application)
Cartographiez les frontières de confiance : entrées de PR, résolution de dépendances, runners, stockage d’artefacts, signature et déploiement. Identifiez où une influence non fiable peut s’introduire.
2) Réduire agressivement les privilèges et le périmètre
Utilisez des identités scopées par job, des identifiants scopés par environnement, des tokens à durée de vie courte et des frontières de permissions explicites. Évitez les « super utilisateurs de pipeline ».
3) Durcir les runners et les environnements d’exécution
Privilégiez les runners éphémères lorsque c’est possible. Si vous utilisez des runners auto-hébergés, isolez-les : restrictions réseau, contrôles du système de fichiers, pas d’état partagé persistant, et une ségrégation stricte entre les charges de travail non fiables et fiables.
4) Rendre l’intégrité vérifiable, pas présumée
Signez les artefacts, générez des attestations et vérifiez-les avant le déploiement. Assurez-vous que la production fait confiance à la vérification, et non simplement au fait que « le CI l’a produit ».
5) Valider les changements de pipeline comme les changements de production
Traitez la configuration CI comme du code à haut risque. Utilisez des code owners, des revues et l’application de politiques pour empêcher l’expansion silencieuse des privilèges ou l’injection d’étapes non fiables.
Conclusion
Les pipelines CI/CD sont discrètement devenus certains des composants les plus critiques — et les plus exploités — des écosystèmes logiciels modernes. Ils agrègent la confiance, fonctionnent avec des privilèges élevés et offrent aux attaquants un chemin à fort effet de levier pour un impact à grande échelle.
L’étape la plus importante est de changer le modèle mental :
Un pipeline CI/CD n’est pas « juste de l’automatisation ». C’est une frontière de confiance.
Les organisations qui conçoivent leurs pipelines avec des frontières de confiance explicites — par l’isolation, le moindre privilège, l’intégrité et la provenance — seront bien mieux positionnées pour se défendre contre la prochaine génération d’attaques sur la supply chain logicielle.
