Le threat modeling est une pratique bien établie en sécurité applicative. Les équipes modélisent régulièrement les menaces pesant sur les API, les services backend et les environnements de production.
Cependant, les pipelines CI/CD sont souvent exclus des exercices formels de threat modeling, alors qu’ils constituent l’un des composants les plus critiques des systèmes logiciels modernes.
C’est une lacune dangereuse.
Les pipelines CI/CD se situent à l’intersection d’entrées non fiables, de privilèges élevés et de sorties de confiance. Ce sont précisément le type de systèmes où le threat modeling apporte le plus de valeur — et pourtant, ils sont fréquemment considérés comme de la « simple automatisation ».
Cet article explique comment modéliser efficacement les menaces des pipelines CI/CD, en se concentrant sur l’identification des trust boundaries, la compréhension des chemins d’attaque et la priorisation des contrôles qui réduisent réellement les risques.
Pourquoi le threat modeling des pipelines CI/CD est différent
Les approches traditionnelles de threat modeling supposent généralement un périmètre système relativement stable : une application s’exécutant en production, avec des utilisateurs, des flux de données et des actifs bien définis.
Les pipelines CI/CD remettent en cause bon nombre de ces hypothèses.
Un pipeline n’est pas un système unique. C’est une chaîne dynamique de systèmes qui :
- Consomme des entrées provenant de sources multiples
- Exécute du code non fiable
- Opère avec des privilèges élevés
- Produit des artefacts auxquels les systèmes en aval font implicitement confiance
En d’autres termes, les pipelines ne sont pas simplement partie intégrante du processus de livraison — ce sont des mécanismes de transformation de la confiance.
Le threat modeling des pipelines CI/CD nécessite donc un changement de mentalité :
L’objectif n’est pas seulement de prévenir les compromissions, mais de comprendre où la confiance est créée, amplifiée ou violée.
Ce que nous protégeons réellement
Avant d’identifier les menaces, il est essentiel de clarifier quels actifs un pipeline CI/CD est chargé de protéger.
Les actifs courants d’un pipeline incluent :
- Intégrité du code source — garantir que le code n’est pas modifié de manière inattendue
- Intégrité du build — garantir que les builds s’exécutent comme prévu
- Intégrité des artefacts — garantir que les sorties correspondent aux entrées
- Secrets et identifiants — tokens, clés et identités utilisés par l’automatisation
- Authenticité des releases — garantir que les livraisons sont légitimes et attribuables
Une attaque réussie contre un pipeline n’implique pas toujours le vol de données ou le crash de systèmes. Souvent, l’objectif de l’attaquant est bien plus subtil :
Introduire un comportement malveillant tout en préservant l’apparence de légitimité.
Comprendre les trust boundaries dans le CI/CD
Un trust boundary existe chaque fois que des données ou un contrôle passent d’un contexte moins fiable à un contexte plus fiable.
Dans les pipelines CI/CD, les trust boundaries sont omniprésents — mais rarement explicites.
Le threat modeling commence par identifier ces frontières et poser une question simple :
Quelles hypothèses faisons-nous sur la confiance à ce stade ?
1. Entrées de code source
Les pipelines consomment du code source provenant de dépôts, de branches, de tags et de pull requests. Toutes ces entrées n’ont pas le même niveau de confiance.
- Les branches principales peuvent être restreintes et révisées
- Les branches de fonctionnalités peuvent être faiblement contrôlées
- Les pull requests peuvent inclure des contributions non fiables
Pourtant, de nombreux pipelines traitent toutes les entrées de code comme également fiables.
Cela crée une surface d’attaque où du code non fiable peut influencer les processus de build et de déploiement de confiance.
2. Résolution des dépendances
Les builds modernes résolvent les dépendances dynamiquement à partir d’écosystèmes externes : registres de paquets, registres de conteneurs et dépôts d’artefacts.
Chaque étape de résolution de dépendances franchit un trust boundary :
- Du contrôle interne vers une infrastructure externe
- D’entrées vérifiées vers du code tiers
Le threat modeling doit prendre en compte :
- La dependency confusion
- Le typosquatting
- Les paquets upstream compromis
Ignorer les dépendances dans le threat modeling laisse un chemin d’attaque majeur inexploré.
3. Runners CI/CD et environnements d’exécution
Les runners sont l’endroit où la logique du pipeline s’exécute réellement. Ils constituent l’un des trust boundaries les plus critiques — et les plus mal compris.
Les runners exécutent :
- Du code source
- Des scripts de build
- Des actions ou plugins tiers
Si les runners sont considérés comme une infrastructure de confiance, mais qu’ils exécutent des entrées non fiables, le trust boundary s’effondre.
Le threat modeling doit explicitement considérer :
- L’isolation des runners
- La persistance entre les jobs
- L’accès au réseau et au système de fichiers
- L’accès aux secrets
4. Configuration et orchestration du pipeline
Les fichiers de configuration CI/CD définissent ce qui s’exécute, quand cela s’exécute et avec quelles permissions.
Ce sont en fait des plans de contrôle pour le processus de livraison.
Toute modification de la configuration du pipeline peut :
- Altérer le flux d’exécution
- Étendre les privilèges
- Introduire de nouveaux chemins d’attaque
Le threat modeling doit traiter les modifications de configuration avec la même rigueur que les modifications du code de production.
5. Artefacts et transfert vers le déploiement
Le dernier trust boundary est le transfert du pipeline vers la production.
À ce stade, les environnements de production supposent souvent :
Si cela provient du CI/CD, c’est sûr.
Cette hypothèse est précisément ce que les attaquants exploitent.
Sans vérification d’intégrité et contrôles de provenance, la production ne peut pas distinguer les artefacts légitimes des artefacts empoisonnés.
Identifier les chemins d’attaque courants en CI/CD
Une fois les trust boundaries identifiés, l’étape suivante consiste à cartographier les chemins d’attaque réalistes.
L’objectif n’est pas d’énumérer toutes les menaces théoriques, mais de comprendre comment les attaquants se déplacent à travers le système.
Chemin d’attaque 1 : De la pull request à l’exfiltration de secrets
Un chemin d’attaque courant implique :
- Un attaquant soumet une pull request
- Le pipeline exécute le code de la PR
- Les secrets sont exposés dans l’environnement de build
- L’attaquant exfiltre les identifiants
Cette attaque n’exploite pas une vulnérabilité — elle exploite une hypothèse de confiance implicite.
Chemin d’attaque 2 : De la compromission de dépendance à l’empoisonnement du build
Un autre chemin courant :
- Une dépendance est compromise en amont
- Le pipeline résout la dépendance
- Du code malveillant s’exécute pendant le build
- Les artefacts sont modifiés avant leur publication
Sans contrôles d’intégrité ni vérification de provenance, l’artefact empoisonné peut sembler parfaitement légitime.
Chemin d’attaque 3 : Manipulation de la configuration du pipeline
Les fichiers de configuration du pipeline font souvent l’objet de moins de scrutin que le code applicatif.
Un attaquant capable de modifier la configuration peut :
- Ajouter des étapes d’exécution cachées
- Étendre silencieusement les permissions
- Rediriger les sorties d’artefacts
Ce chemin d’attaque est particulièrement dangereux car il peut persister à travers de multiples builds.
Chemin d’attaque 4 : Compromission des runners et mouvement latéral
Si les runners sont partagés, persistants ou mal isolés, un attaquant peut :
- Persister entre les jobs
- Voler des secrets d’autres pipelines
- Modifier les builds futurs
Dans certains cas, la compromission d’un runner fournit un accès aux réseaux internes ou aux environnements cloud.
Cartographier visuellement les trust boundaries
Un threat modeling efficace bénéficie de représentations visuelles.
Pour les pipelines CI/CD, les diagrammes doivent se concentrer sur :
- Où les entrées non fiables pénètrent
- Où les privilèges augmentent
- Où les artefacts sont produits et consommés
Chaque flèche du diagramme représente une transition de confiance. Chaque transition est un candidat pour l’application de contrôles.
La question clé à chaque frontière est :
Quelles garanties avons-nous à ce stade, et comment sont-elles appliquées ?
Prioriser les contrôles en fonction du threat modeling
Le threat modeling n’a de valeur que s’il guide l’action.
Pour les pipelines CI/CD, les contrôles à plus fort impact incluent généralement :
1. Réduire la confiance implicite
Distinguer explicitement les entrées fiables des entrées non fiables. Ne pas exposer les secrets ni les actions privilégiées aux contextes non fiables.
2. Appliquer le principe du moindre privilège
Les identités des pipelines doivent être limitées par job, par étape et par environnement. Éviter les tokens à longue durée de vie et à portée étendue.
3. Isoler les environnements d’exécution
Les runners doivent être éphémères ou fortement isolés. Les charges de travail non fiables ne doivent jamais partager un contexte d’exécution avec celles de confiance.
4. Vérifier l’intégrité des artefacts
Les artefacts doivent être signés, attestés et vérifiés avant le déploiement. La production doit se fier à la vérification — pas aux hypothèses.
5. Traiter la configuration du pipeline comme du code à haut risque
Appliquer des revues, des politiques et des validations aux modifications de la configuration CI/CD. Empêcher l’extension silencieuse de l’exécution ou des privilèges.
Erreurs courantes dans le threat modeling CI/CD
Même lorsque les organisations tentent de modéliser les menaces des pipelines, elles tombent souvent dans des pièges prévisibles.
- Se concentrer uniquement sur les outils, pas sur les relations de confiance
- Supposer qu’« interne » signifie « de confiance »
- Ignorer les composants tiers
- Modéliser des architectures idéalisées au lieu des pipelines réels
Un threat modeling efficace doit refléter le fonctionnement réel des pipelines, et non la manière dont nous souhaiterions qu’ils fonctionnent.
Conclusion
Les pipelines CI/CD ne sont pas des systèmes périphériques. Ils sont au cœur de l’intégrité, de la sécurité et de la confiance dans les logiciels.
Le threat modeling des pipelines révèle des chemins d’attaque que les modèles de menaces applicatifs traditionnels manquent, car l’objectif de l’attaquant n’est pas d’exploiter un comportement en production, mais de contrôler ce qui est livré en premier lieu.
En identifiant les trust boundaries, en cartographiant les chemins d’attaque réalistes et en priorisant des contrôles applicables, les organisations peuvent réduire significativement le risque d’attaques de la chaîne d’approvisionnement logicielle.
Le changement le plus important est conceptuel :
Si vous ne modélisez pas explicitement la confiance dans votre pipeline, vous vous appuyez sur des hypothèses — et les attaquants exploitent les hypothèses.
