OWASP Top 10 CI/CD : les dix risques de la chaîne de livraison

Publié en 2022 et sans deuxième édition depuis, le Top 10 OWASP des risques de sécurité CI/CD (Continuous Integration / Continuous Delivery) est l’un des référentiels les plus utiles de la famille, et l’un des moins cités. Son objet n’est ni une application ni une plateforme, mais le chemin qui mène du poste d’un développeur à la production. Ce chemin franchit tous les contrôles d’accès que l’organisation a mis des années à poser, et il le fait en quelques minutes, automatiquement, parce que c’est précisément à cela qu’il sert.

→ Lire l’explication complète de la marmotte

Les dix risques, et où les lire

Chaque ligne renvoie à une fiche qui décrit le mécanisme, ce que l’attaquant en obtient, ce qui se détecte et par quoi, et ce que le défenseur fait.

Code	Titre officiel	Le risque en une ligne
CICD-SEC-1	Insufficient Flow Control Mechanisms	Mécanismes de contrôle de flux insuffisants : une seule entité suffit à pousser du code jusqu’en production.
CICD-SEC-2	Inadequate Identity and Access Management	Gestion des identités et des accès inadéquate : des centaines d’identités réparties sur des systèmes qui n’ont pas le même annuaire.
CICD-SEC-3	Dependency Chain Abuse	Abus de la chaîne de dépendances : le mauvais paquet est non seulement téléchargé, mais exécuté.
CICD-SEC-4	Poisoned Pipeline Execution	Exécution de pipeline empoisonnée : modifier ce que la machine de construction va lire, sans y entrer.
CICD-SEC-5	Insufficient PBAC (Pipeline-Based Access Controls)	Contrôles d’accès du pipeline insuffisants : ce que l’on trouve une fois dans le nœud de construction.
CICD-SEC-6	Insufficient Credential Hygiene	Hygiène des identifiants insuffisante : cinq endroits où les secrets finissent par traîner.
CICD-SEC-7	Insecure System Configuration	Configuration système non sécurisée : le fruit mûr, dont SolarWinds relève selon ses auteurs.
CICD-SEC-8	Ungoverned Usage of 3rd Party Services	Usage non gouverné de services tiers : cinq façons de brancher un tiers en deux minutes.
CICD-SEC-9	Improper Artifact Integrity Validation	Validation d’intégrité des artefacts défaillante : ce qui passe une jonction passe jusqu’à la production.
CICD-SEC-10	Insufficient Logging and Visibility	Journalisation et visibilité insuffisantes : le journal montre une construction réussie.

Les codes ne portent pas de millésime, et pour une fois cela ne gêne pas : il n’y a qu’une édition. C’est à la fois la limite du document et sa commodité, puisque « CICD-SEC-4 » désigne la même chose depuis 2022, ce qu’aucune autre liste de la famille ne peut dire.

Les trois entrées qui tiennent les autres

CICD-SEC-4, l’exécution de pipeline empoisonnée, est l’entrée la plus développée du référentiel et la plus spécifique à son objet : un attaquant qui dispose de droits sur le gestionnaire de code source, et d’aucun droit sur l’environnement de construction, fait exécuter ses commandes par cet environnement en modifiant ce que celui-ci va lire. Le document en distingue trois formes, directe, indirecte et publique, et la fiche détaille laquelle se ferme par quelle mesure : exécution de pipeline empoisonnée.

CICD-SEC-5, les contrôles d’accès du pipeline, en est le corollaire, et la clé du dimensionnement du risque. Le terme PBAC désigne le contexte dans lequel chaque étape s’exécute : ce qu’elle atteint, ses permissions sur l’hôte, ses flux vers Internet. L’objectif annoncé admet l’échec, et c’est ce qui le rend utile : on ne cherche pas à empêcher l’exécution de code hostile, on cherche à ce qu’elle ne mène nulle part, comme l’explique la fiche correspondante.

CICD-SEC-1, les mécanismes de contrôle de flux, ouvre la liste sur un défaut d’organisation plutôt que de technique : une seule entité, humaine ou programmatique, suffit à pousser du code ou un artefact jusqu’en production, faute d’approbation supplémentaire. Le référentiel en donne sept variantes qui se lisent comme un inventaire des commodités d’équipe, détaillées dans la fiche sur le contrôle de flux, avec la recommandation que personne n’applique : séparer le droit de pousser du code non relu et celui de déclencher un déploiement.

Pourquoi cette liste existe : des incidents, pas des hypothèses

Le référentiel appuie son existence sur une série de compromissions qu’il nomme et que l’industrie connaît. SolarWinds, où le système de construction compromis a servi à diffuser un code malveillant jusqu’à dix-huit mille clients. Codecov, qui a conduit à l’exfiltration de secrets stockés dans les variables d’environnement de milliers de pipelines, dans de nombreuses entreprises. PHP, avec la publication d’une version du langage contenant une porte dérobée. La confusion de dépendances, qui exploite la façon dont les dépendances externes sont récupérées pour exécuter du code sur les postes de développement et les environnements de construction. Les paquets npm ua-parser-js, coa et rc, chacun à plusieurs millions de téléchargements hebdomadaires, dont la compromission a exécuté du code sur des millions d’environnements.

Le constat des auteurs est que les attaquants de tous niveaux se sont déplacés vers la chaîne de livraison, parce qu’elle offre un chemin efficace vers les actifs les mieux gardés, pendant que les défenseurs en sont encore à chercher comment détecter et gérer ces risques. Trois ans après, l’affirmation reste défendable. Chacun de ces incidents est rattaché par le document à une entrée précise, et les fiches disent laquelle : la liste n’est pas une collection d’anecdotes, c’est une taxonomie construite à partir d’elles.

Un document stable, un projet au repos

Le projet est classé Lab par l’OWASP, palier intermédiaire de ses quatre niveaux, et n’a pas connu de deuxième édition depuis 2022. Ce n’est pas un abandon : la chaîne de livraison logicielle a beaucoup moins bougé en trois ans que l’intelligence artificielle, les dix risques décrivent toujours ce qu’on observe, et le vocabulaire (PPE, PBAC) s’est imposé dans le métier. Le document a été écrit et relu par des responsables de la sécurité de grandes plateformes logicielles, ce qui se sent à la précision des variantes d’attaque.

Il reste qu’un document sans révision ne couvre pas ce qui est arrivé après lui. Deux sujets manquent visiblement : l’exécution de code dans un pipeline par un agent d’intelligence artificielle disposant des droits du pipeline, et les actions réutilisables épinglées sur une étiquette mutable plutôt que sur un condensat, ce second point relevant de CICD-SEC-3 et de CICD-SEC-9 sans y être nommé. La façon de citer un Top 10 selon sa maturité est traitée dans la page chapeau ; ici, la stabilité est plutôt un avantage.

Et comme pour les autres référentiels de la famille, ce n’est pas une norme : personne n’est en conformité avec CICD-SEC-6. Pour l’articulation avec une obligation réelle, notamment les exigences du règlement sur la cyberrésilience en matière de processus de développement, c’est la rubrique Normes qui porte le sujet.

🐝 Ce qui arrive si on s’en passe

Sans contrôle de flux, un unique compte pousse du code jusqu’en production sans seconde relecture : la protection de branche existe mais exclut deux comptes de service, et c’est par eux que passe la livraison. Sans séparation entre le droit de pousser du code non relu et celui de déclencher un déploiement, la revue de code devient décorative, puisque le pipeline exécute ce qui n’a pas été relu avant de décider s’il faut le relire. Sans restriction du contexte d’exécution des pipelines, un Makefile modifié dans une demande de fusion exécute du code avec tous les secrets du pipeline et un accès sortant libre : les identifiants partent, et l’enregistrement de l’incident montre une construction réussie. Sans validation d’intégrité des artefacts, un paquet déposé à la main dans le dépôt d’artefacts est ramassé par le pipeline de déploiement comme s’il sortait de l’environnement de construction. Sans journalisation du pipeline lui-même, aucune de ces étapes ne laisse de trace distinguable d’une livraison ordinaire, et la question « quand cet artefact est-il entré » reste sans réponse.

🦫 Explication de la marmotte 🍫

Dans une entreprise qui développe des logiciels, le code écrit par une personne ne part pas directement en service. Une machinerie automatique le récupère, l’assemble, le teste, fabrique un paquet et l’installe sur les serveurs. On appelle cela une chaîne d’intégration et de livraison continues. Elle existe pour aller vite, et elle va vite : quelques minutes suffisent parfois entre l’écriture et la mise en service.

Cette machinerie est une cible idéale, parce qu’elle détient tout : le code source, les mots de passe des serveurs, le droit d’installer des programmes en production. Une association internationale de spécialistes a publié en 2022 la liste des dix façons les plus courantes d’en prendre le contrôle. Elle n’a pas été révisée depuis, et reste valable.

Le mécanisme le plus caractéristique porte un nom imagé : l’empoisonnement du pipeline. L’attaquant n’entre pas dans la machinerie ; il modifie un fichier que la machinerie va lire et exécuter. Comme la machinerie se déclenche automatiquement dès qu’un fichier change, et comme elle exécute ce qu’elle lit, le code de l’attaquant tourne avec tous les droits de la machinerie, sans que personne l’ait relu, puisque la relecture vient après.

Les autres risques sont du même ordre : une seule personne peut tout envoyer en production sans qu’un deuxième regard soit exigé ; les mots de passe traînent dans des variables accessibles à toutes les étapes ; les composants téléchargés sur Internet ne sont pas vérifiés ; un service extérieur a reçu un accès large qu’on a oublié de retirer ; et les enregistrements d’activité sont trop pauvres pour reconstituer ce qui s’est passé. Chacun a sa fiche, dont le tableau plus haut donne la liste.

Pages voisines

La citent

OWASP Kubernetes Top 10 2025 : les dix risques d'un cluster

OWASP Top 10 CI/CD : les dix risques de la chaîne de livraison

Elle cite

: les deux pages se citent l’une l’autre.

OWASP Top 10 CI/CD : les dix risques de la chaîne de livraison

OWASP Top 10 CI/CD : les dix risques de la chaîne de livraison

Les dix risques, et où les lire

Les trois entrées qui tiennent les autres

Pourquoi cette liste existe : des incidents, pas des hypothèses

Un document stable, un projet au repos

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines