Les systèmes CI/CD s’authentifient auprès des plateformes cloud, récupèrent des configurations protégées, créent des versions d’exécution et modifient la production : chaque pipeline est donc un principal de sécurité dont l’identité, les dépendances, l’exposition aux identifiants et l’autorité doivent être conçues explicitement.
Questions abordées dans cette perspective
- Pourquoi les CTO doivent-ils traiter les flux CI/CD comme des identités privilégiées plutôt que comme des scripts d’automatisation ?
- Comment les contrôles de la chaîne d’approvisionnement logicielle évoluent-ils lorsqu’une compilation détient une autorité cloud et de production ?
- Comment séparer les autorisations entre compilation, création d’une candidate, promotion et retour arrière ?
La CI a cessé depuis longtemps d’être un simple serveur de compilation
Le vocabulaire de l’intégration continue conserve la trace d’un ancien modèle opératoire dans lequel un serveur récupérait le code, le compilait, exécutait les tests et produisait un artefact. Les chaînes modernes accomplissent bien davantage : elles s’authentifient auprès des plateformes cloud, récupèrent des configurations protégées, construisent des conteneurs et des packages sans serveur, créent des infrastructures, signent et publient des artefacts, modifient le routage, promeuvent des versions et peuvent parfois supprimer ou remplacer des ressources de production. Du point de vue de la sécurité, le flux CI/CD ne se contente donc plus d’exécuter une suite de commandes ; il agit au nom de l’organisation et transforme son état technologique.
L’unité pertinente de conception n’est par conséquent pas le fichier de pipeline, mais l’identité qu’il représente et l’autorité qui lui est accordée. Deux flux conservés dans le même dépôt peuvent justifier des niveaux de confiance très différents. Un déploiement de développement peut avoir le droit de créer un environnement éphémère, une chaîne de préparation à la production doit éventuellement accéder à une configuration protégée, tandis qu’un flux de promotion peut avoir besoin de modifier le trafic sans aucune raison de récupérer les identifiants applicatifs. Réunir ces responsabilités sous une identité CI unique et puissante simplifie l’exploitation à court terme, mais efface des distinctions essentielles à mesure que la livraison devient plus autonome.
L’identité de charge de travail rend le pipeline lisible
Les identifiants CI à longue durée de vie rendent l’identité difficile à interpréter. Lorsque plusieurs flux partagent la même clé cloud stockée, la plateforme destinataire sait principalement que la clé a été présentée ; le contexte organisationnel indiquant quel flux s’exécute, quel environnement il représente et quelle branche l’a déclenché doit être contrôlé ailleurs. La fédération d’identité des charges de travail peut intégrer une partie de ce contexte au mécanisme d’authentification lui-même.
Au lieu de présenter une clé réutilisable, le pipeline fournit des attributs vérifiables de sa charge et les échange contre une autorité de courte durée. La relation de confiance peut être limitée au dépôt attendu, au flux de production désigné, à un environnement de déploiement protégé, à la branche autorisée et à l’identité de service que cette combinaison peut assumer. Le modèle ne se résume plus à l’affirmation générale selon laquelle « la CI dispose d’un accès au cloud » ; il prend la forme d’un graphe d’autorisations capable d’exprimer qui agit, dans quel contexte et avec quel périmètre. Cette lisibilité constitue une base plus solide pour les livraisons pilotées par des personnes comme par des agents.
Le moment où apparaît le privilège compte pour la chaîne d’approvisionnement logicielle
La sécurité CI/CD ne peut être dissociée de celle de la chaîne d’approvisionnement logicielle, car les pipelines exécutent du code provenant du dépôt, de dépendances et d’outils tiers. Un flux courant peut installer des packages, exécuter des scripts de compilation, appeler des outils de framework, manipuler l’infrastructure et lancer des utilitaires de déploiement. Certains composants exécutent du code pendant leur installation ; d’autres résolvent dynamiquement des extensions ou téléchargent automatiquement de nouvelles versions.
Avant l’authentification privilégiée, ce comportement relève principalement de l’intégrité du logiciel. Après l’obtention d’une identité cloud ou la récupération de secrets applicatifs, il devient aussi un problème d’exposition des identifiants. Lorsqu’un pipeline télécharge un exécutable non épinglé après s’être authentifié, l’entreprise introduit un nouveau code dans un processus qui détient déjà une autorité de confiance. L’ordre des opérations devient donc un contrôle de sécurité : dans la mesure du possible, les dépendances doivent être installées et testées avant l’authentification privilégiée, les actions CI référencées par des révisions immuables et les outils de déploiement issus d’un état de dépendances reproductible ou de versions explicitement contrôlées.
Cette discipline n’interdit pas l’évolution des dépendances. Les logiciels doivent être mis à jour. Elle distingue plutôt une mise à niveau consciente, soumise à revue et à test, d’un changement implicite survenu parce qu’un pipeline privilégié a demandé la « dernière version ». La reproductibilité n’est donc pas uniquement une qualité de l’ingénierie ; elle constitue une propriété de sécurité.
L’héritage des identifiants crée des privilèges invisibles
Même un pipeline correctement authentifié peut distribuer ses privilèges plus largement que prévu par le simple héritage des environnements de processus. Une tâche obtient des identifiants cloud fédérés, récupère des secrets d’exécution, conserve un jeton de plateforme de déploiement, puis lance plusieurs commandes. Si chaque processus enfant reçoit l’environnement complet du parent, chacun peut hériter de ces trois formes d’autorité, qu’il en ait besoin ou non.
Cette expansion passe facilement inaperçue parce qu’aucune nouvelle autorisation n’apparaît dans la console IAM et qu’aucune politique du coffre n’a changé. Pourtant, au niveau du système d’exploitation, le nombre de programmes susceptibles d’observer les identifiants s’est accru. Or les outils présentent des profils de confiance différents : l’utilitaire de déploiement a besoin du droit de déployer, la ligne de commande cloud de l’identité correspondante, tandis qu’une commande Git n’a besoin ni de l’un ni de l’autre. Un outil de hachage peut recevoir une valeur d’entrée déterminée sans hériter des jetons d’infrastructure présents dans le processus parent.
Le modèle le plus robuste construit explicitement l’environnement de chaque sous-processus. Cette discipline rend également l’autorité inspectable : un réviseur peut voir quels identifiants sont volontairement transmis à quelle opération. À mesure que les agents modifient eux-mêmes le code de livraison, la sécurité ne dépend plus de leur capacité à se rappeler qu’un processus enfant hérite par défaut de tout ce que connaît le parent.
Créer une candidate et promouvoir en production relèvent d’autorités différentes
La mise en production offre une séparation particulièrement utile. La création d’une candidate peut nécessiter l’accès au code, aux dépendances, à la configuration et à des secrets protégés afin de constituer une version représentant un état applicatif exact. La promotion répond à une autre question : cette candidate doit-elle recevoir du trafic de production ? Sur les plateformes dotées de déploiements versionnés, cette opération peut n’exiger que le droit de modifier l’état du déploiement, sans accès aux mots de passe de base de données, aux clés d’API ou au coffre utilisés lors de la construction.
Le retour arrière suit la même logique : réorienter le trafic vers une version stable connue devrait idéalement ne mobiliser que l’autorité nécessaire au routage. La séparation réduit la durée pendant laquelle les secrets de production sont accessibles, diminue les privilèges du flux de promotion, maintient la capacité de restauration même si le coffre connaît une difficulté indépendante et produit des traces distinguant la construction technique de la décision d’exposer la version aux utilisateurs. Elle permet également d’appliquer des politiques d’approbation différentes sans transformer le pipeline entier en une action privilégiée indivisible.
L’architecture CI devient une composante de l’architecture d’identité de l’entreprise
L’ingénierie agentique rend cette évolution plus urgente, mais la conclusion ne dépend pas de l’IA : la CI/CD constitue déjà un système d’identité. Elle représente un logiciel qui agit au nom de l’entreprise, traverse des frontières de confiance, accède à des ressources protégées et modifie l’état des systèmes à une fréquence qu’aucune personne ne pourrait superviser directement.
Les CTO doivent donc attendre des identités CI les mêmes qualités que celles exigées des autres identités privilégiées : périmètre limité, autorité de courte durée, conditions de confiance explicites, séparation des responsabilités, auditabilité et révocation. La définition du pipeline devient l’implémentation de cette architecture, et non une simple liste d’étapes d’automatisation. Une plateforme de livraison commune peut alors standardiser l’identité de charge, la récupération des secrets, l’épinglage des outils et l’autorité de promotion, au lieu de laisser chaque équipe de produit créer un modèle légèrement différent.
La décision essentielle consiste à changer la question posée lors de la revue d’un flux CI. Il ne suffit plus de demander quelles commandes il exécute. Il faut établir quelle identité il devient, quelles ressources cette identité peut atteindre et quels processus héritent de cette autorité pendant l’exécution. C’est à ce niveau que doit désormais être conçue la sécurité des chaînes de livraison.
