Constats d'audit courants dans les pipelines CI/CD — Top 10 des défaillances

Introduction : des schémas récurrents observés en audit

Après avoir examiné des implémentations de CI/CD dans des environnements réglementés — services financiers, santé, infrastructures critiques et entreprises technologiques soumises à SOC 2, ISO 27001, DORA, NIS2 et PCI DSS —, certains constats d’audit reviennent avec une régularité remarquable. Il ne s’agit pas de cas marginaux obscurs. Ce sont des défaillances systémiques de gouvernance que les auditeurs rencontrent à répétition, dans des organisations de toutes tailles et de tous niveaux de maturité.

Cet article présente les dix constats d’audit les plus courants dans les pipelines CI/CD, rédigé à l’intention des auditeurs, des responsables de la conformité et des gestionnaires de risques. Pour chaque constat, nous décrivons de quoi il s’agit, pourquoi il est important d’un point de vue réglementaire, comment il apparaît généralement lors d’un audit, et à quoi devrait ressembler la remédiation. Les équipes de conformité devraient l’utiliser comme une liste de contrôle d’auto-évaluation préalable à l’audit, afin d’identifier et de corriger les faiblesses avant qu’un auditeur externe ne le fasse.

Constat 1 : comptes de service partagés dotés de privilèges d’administration

Description

Plusieurs personnes ou équipes utilisent des comptes de service partagés dotés de privilèges élevés (souvent administratifs) pour exécuter des opérations de pipeline. Les actions individuelles ne peuvent pas être attribuées à des personnes précises.

Pourquoi c’est important

La responsabilité individuelle est un principe fondateur du contrôle d’accès. Lorsque les actions ne peuvent pas être rattachées à une personne précise, l’investigation des incidents devient impossible et l’effet dissuasif contre les abus disparaît. Les contrôles de séparation des tâches perdent tout leur sens si plusieurs personnes opèrent sous la même identité.

Références réglementaires

DORA : l’article 9 exige des contrôles d’identification et d’authentification pour les systèmes informatiques
ISO 27001 : annexe A.9.2 — Gestion des accès des utilisateurs, y compris l’identification unique des utilisateurs
SOC 2 : CC6.1 — Sécurité des accès logiques ; responsabilité individuelle
PCI DSS : exigence 8 — Attribuer un identifiant unique à chaque personne ayant accès aux systèmes informatiques

Preuve typique du constat

Les journaux du pipeline montrent que le même compte de service exécute des builds, des déploiements et des actions administratives pour plusieurs équipes. Les revues d’accès révèlent que les identifiants du compte de service sont partagés entre plusieurs personnes. Aucune correspondance n’existe entre les actions du compte de service et les opérateurs individuels.

Remédiation attendue

Mettre en place des comptes utilisateurs individuels pour toutes les interactions avec le pipeline. Lorsque des comptes de service sont techniquement nécessaires, mettre en œuvre des contrôles qui relient les actions du compte de service à la personne qui les a initiées (par exemple, par des déclencheurs de pipeline liés à des utilisateurs authentifiés). Réaliser une revue des privilèges et appliquer les principes du moindre privilège.

Gravité : élevée

Constat 2 : points d’approbation contournables ou auto-approuvés

Description

Des points d’approbation existent dans le pipeline, mais ils peuvent être contournés par des utilisateurs disposant de privilèges suffisants, ou la même personne qui initie un changement peut approuver son propre déploiement en production. La séparation des tâches n’est pas imposée.

Pourquoi c’est important

Les points d’approbation sont le principal mécanisme d’application de la séparation des tâches dans les environnements CI/CD. S’ils peuvent être contournés ou auto-approuvés, le contrôle est inefficace, qu’il existe ou non sur le papier. Il s’agit d’une défaillance de conception, et non d’une simple faiblesse opérationnelle.

Références réglementaires

DORA : article 9 — Procédures de gestion des changements informatiques avec approbation appropriée
NIS2 : les mesures de gestion des risques doivent inclure des contrôles d’autorisation appropriés
ISO 27001 : annexe A.12.1.2 — Gestion des changements ; annexe A.6.1.2 — Séparation des tâches
SOC 2 : CC8.1 — Contrôles de gestion des changements

Preuve typique du constat

La configuration du pipeline montre que les utilisateurs dotés des rôles « admin » ou « maintainer » peuvent contourner les exigences d’approbation. Les journaux de déploiement montrent des cas où la même personne a validé le code et approuvé le déploiement. Des procédures de contournement d’urgence existent, mais sans contrôles de gouvernance ni revue a posteriori.

Remédiation attendue

Imposer des points d’approbation qui ne peuvent être contournés que par un processus gouverné de changement d’urgence. Mettre en place des règles de séparation des tâches qui empêchent l’auto-approbation. Journaliser et examiner tous les cas où les processus d’approbation standard ne sont pas respectés.

Gravité : élevée

Constat 3 : absence de conservation des journaux du pipeline ou journaux stockés dans des systèmes modifiables

Description

Les journaux d’exécution du pipeline ne sont soit pas conservés au-delà d’une courte fenêtre opérationnelle (par exemple 30 jours), soit stockés dans des systèmes où ils peuvent être modifiés ou supprimés par le personnel d’exploitation.

Pourquoi c’est important

Les journaux du pipeline constituent une preuve de premier plan pour les contrôles de gestion des changements, d’autorisation des déploiements et de tests de sécurité. Sans conservation adéquate, les organisations ne peuvent pas démontrer aux auditeurs que les contrôles fonctionnaient au cours de périodes passées. Des journaux modifiables compromettent l’intégrité des preuves — un auditeur ne peut pas se fier à une preuve qui aurait pu être altérée.

Références réglementaires

DORA : article 12 — Exigences de journalisation pour les opérations informatiques ; conservation attendue de 5 ans
PCI DSS : exigence 10 — Suivre et surveiller tous les accès ; conservation minimale d’un an
ISO 27001 : annexe A.12.4 — Journalisation et surveillance
SOC 2 : CC7.2 — Surveillance des systèmes

Preuve typique du constat

Les demandes de journaux du pipeline datant de six mois ne donnent aucun résultat. Le stockage des journaux se trouve dans le même système où les opérateurs disposent d’un accès en écriture. Aucun mécanisme de vérification de l’intégrité des journaux n’existe (pas de sommes de contrôle, pas de stockage immuable).

Remédiation attendue

Mettre en place des politiques de conservation des journaux alignées sur les exigences réglementaires. Stocker les journaux dans un stockage immuable ou en écriture unique. Mettre en œuvre des mécanismes de vérification de l’intégrité des journaux. S’assurer que la conservation des journaux couvre l’intégralité de la période d’audit, à laquelle s’ajoutent les exigences réglementaires de conservation.

Gravité : élevée

Constat 4 : secrets codés en dur dans le code ou les configurations de pipeline

Description

Des identifiants, clés d’API, certificats ou autres secrets sont intégrés directement dans les dépôts de code source ou les fichiers de configuration du pipeline, plutôt que gérés au moyen d’une capacité dédiée de gestion des secrets.

Pourquoi c’est important

Les secrets codés en dur sont accessibles à quiconque dispose d’un accès au dépôt, ne peuvent pas être renouvelés sans modification du code et persistent dans l’historique du système de gestion de versions même après leur suppression. Cela crée une exposition incontrôlée des identifiants et rend la gestion des identifiants — renouvellement, révocation, journalisation des accès — pratiquement impossible.

Références réglementaires

DORA : article 9 — Protection des actifs et données informatiques
ISO 27001 : annexe A.9.4.3 — Gestion des mots de passe ; annexe A.10 — Contrôles cryptographiques
PCI DSS : exigence 2 — Ne pas utiliser les valeurs par défaut fournies par les fournisseurs ; exigence 8 — Gestion des identifiants
SOC 2 : CC6.1 — Contrôles d’accès logiques

Preuve typique du constat

L’analyse des dépôts révèle des secrets dans le code ou les fichiers de configuration. L’historique du système de gestion de versions contient des identifiants même s’ils ont été supprimés des versions actuelles. Aucune solution de gestion des secrets n’est utilisée, ou elle l’est mais sans adoption universelle.

Remédiation attendue

Retirer tous les secrets codés en dur des dépôts et des configurations de pipeline. Mettre en place une capacité centralisée de gestion des secrets. Renouveler tous les identifiants exposés. Mettre en œuvre une détection automatisée des secrets dans les pipelines afin de prévenir toute récurrence.

Gravité : critique

Constat 5 : résultats des analyses de sécurité ignorés — aucun point de contrôle de politique ne bloque le déploiement

Description

Des outils d’analyse de sécurité (SAST, DAST, SCA, analyse de conteneurs) sont intégrés aux pipelines, mais leurs résultats ne conditionnent pas les déploiements. Des vulnérabilités élevées ou critiques sont identifiées, mais le code passe en production malgré tout.

Pourquoi c’est important

Exécuter des analyses de sécurité sans agir sur les résultats relève de la mise en scène de sécurité. Cela crée l’apparence de tests de sécurité sans en fournir la substance. Du point de vue de la gouvernance, l’organisation a connaissance des vulnérabilités mais choisit de ne pas les traiter — ce qui peut être pire que de ne pas analyser du tout, car cela témoigne d’une acceptation consciente d’un risque non maîtrisé.

Références réglementaires

DORA : article 8 — Identification, protection et prévention des risques informatiques
NIS2 : article 21 — Traitement et divulgation des vulnérabilités
ISO 27001 : annexe A.12.6 — Gestion des vulnérabilités techniques
PCI DSS : exigence 6 — Développer et maintenir des systèmes sécurisés

Preuve typique du constat

Les rapports d’analyse font état de constats critiques sur des périodes prolongées sans remédiation. Les configurations du pipeline montrent que les analyses s’exécutent, mais que leurs résultats n’influent pas sur la progression du pipeline. Aucun seuil défini n’existe pour déterminer quels résultats d’analyse devraient bloquer le déploiement.

Remédiation attendue

Définir des seuils de sécurité clairs qui conditionnent la progression du pipeline. Mettre en place des points de contrôle de politique qui bloquent le déploiement lorsque les constats dépassent des seuils de gravité définis. Établir un processus gouverné de dérogation pour les constats acceptés — avec une acceptation du risque documentée par l’autorité appropriée.

Gravité : élevée

Constat 6 : absence de génération de SBOM ou d’inventaire des composants tiers

Description

L’organisation ne génère pas de nomenclatures logicielles (SBOM) et ne tient pas d’inventaire complet des composants tiers et open source utilisés dans ses applications.

Pourquoi c’est important

Sans SBOM, l’organisation ne peut pas identifier quelles applications sont concernées lorsqu’une vulnérabilité est divulguée dans un composant tiers (comme cela s’est produit avec Log4Shell, Spring4Shell et d’autres incidents de chaîne d’approvisionnement similaires). La réponse aux incidents devient une devinette, et les exigences réglementaires en matière de gestion des risques de la chaîne d’approvisionnement ne peuvent pas être satisfaites.

Références réglementaires

DORA : article 28 — Gestion du risque lié aux prestataires tiers de services informatiques
NIS2 : article 21 — Sécurité de la chaîne d’approvisionnement
ISO 27001 : annexe A.15 — Relations avec les fournisseurs
SOC 2 : CC9.2 — Gestion des risques liés aux prestataires tiers

Preuve typique du constat

Aucun fichier SBOM n’existe pour les applications déployées. À la question « lesquelles de vos applications utilisent le composant X ? », l’organisation ne peut pas répondre rapidement. Aucune analyse automatisée des dépendances n’est intégrée aux pipelines.

Remédiation attendue

Mettre en place la génération automatisée de SBOM dans le cadre du pipeline CI/CD. Utiliser des formats standard (CycloneDX ou SPDX). Tenir un référentiel central des SBOM pour toutes les applications déployées. Mettre en œuvre des processus permettant de recouper les nouvelles divulgations de vulnérabilités avec l’inventaire des SBOM.

Gravité : moyenne à élevée

Constat 7 : accès direct à la production sans gestion des changements

Description

Les développeurs ou les opérateurs peuvent accéder directement aux environnements de production et y effectuer des changements en dehors du pipeline CI/CD, contournant tous les contrôles du pipeline, y compris les points d’approbation, les analyses de sécurité et la journalisation d’audit.

Pourquoi c’est important

Si des changements de production peuvent être effectués en dehors du pipeline gouverné, l’ensemble du cadre de contrôle est compromis. Chaque contrôle intégré au pipeline — approbations, analyses, journalisation, séparation des tâches — peut être contourné simplement en effectuant les changements directement. Le pipeline devient optionnel, et non obligatoire.

Références réglementaires

DORA : article 9 — Contrôles de gestion des changements et de déploiement informatiques
ISO 27001 : annexe A.12.1.2 — Gestion des changements ; annexe A.14.2.2 — Contrôle des changements de système
SOC 2 : CC8.1 — Gestion des changements
PCI DSS : exigence 6.5 — Procédures de contrôle des changements

Preuve typique du constat

Les journaux d’accès à la production montrent des connexions directes par du personnel de développement ou d’exploitation. Les changements en production ne correspondent pas aux enregistrements de déploiement du pipeline. Les configurations de l’environnement de production diffèrent de ce que le pipeline a déployé en dernier.

Remédiation attendue

Restreindre l’accès à la production à des comptes de service autorisés contrôlés par le pipeline. Mettre en place un accès juste-à-temps pour les scénarios d’urgence, avec journalisation complète et revue a posteriori de l’accès. Surveiller tout changement direct en production en dehors du pipeline et déclencher des alertes le cas échéant.

Gravité : critique

Constat 8 : suppressions de vulnérabilités sans acceptation du risque documentée

Description

Des constats d’analyse de sécurité sont supprimés, écartés ou marqués comme « acceptés » sans documentation formelle d’acceptation du risque. Aucune trace n’existe indiquant qui a accepté le risque, quelle en était la justification, ou quand l’acceptation expire.

Pourquoi c’est important

L’acceptation du risque est une option légitime de traitement du risque — mais seulement lorsqu’il s’agit d’une décision consciente, documentée et autorisée. Des suppressions non gouvernées ne sont pas une acceptation du risque ; c’est une ignorance du risque. Elles créent des poches cachées de risque non maîtrisé que les auditeurs identifieront et signaleront.

Références réglementaires

DORA : article 8 — Identification et traitement des risques informatiques
ISO 27001 : clause 6.1.3 — Traitement du risque ; acceptation du risque documentée par les propriétaires du risque
SOC 2 : CC3.2 — Évaluation et gestion des risques
NIS2 : article 21 — Mesures de gestion des risques

Preuve typique du constat

Les configurations d’analyse de sécurité contiennent des listes de suppression sans documentation associée. Les constats supprimés incluent des vulnérabilités de gravité critique ou élevée. Aucun flux d’approbation n’existe pour l’ajout de constats aux listes de suppression. Les suppressions n’ont ni date d’expiration ni cycle de revue.

Remédiation attendue

Mettre en place un processus formel d’acceptation du risque exigeant une justification documentée, l’approbation de l’autorité appropriée, des dates d’expiration définies et une revue périodique. Réexaminer rétrospectivement toutes les suppressions existantes et, soit documenter l’acceptation du risque, soit retirer la suppression.

Gravité : élevée

Constat 9 : absence de séparation entre les environnements de développement, de préproduction et de production

Description

Les environnements de développement, de préproduction (ou de test) et de production ne sont pas suffisamment séparés. Ils peuvent partager une infrastructure, des identifiants, des données ou des segments de réseau, ou le personnel de développement peut disposer d’un accès équivalent à tous les environnements.

Pourquoi c’est important

La séparation des environnements est un contrôle fondamental qui protège les systèmes de production contre les changements non autorisés, empêche les activités de développement d’affecter les services en production et garantit que les tests sont menés dans des conditions qui se rapprochent de la production — sans la compromettre. Sans cette séparation, le risque de changements incontrôlés, de fuite de données et de contamination entre environnements augmente considérablement.

Références réglementaires

DORA : article 9 — Séparation des environnements informatiques
ISO 27001 : annexe A.12.1.4 — Séparation des environnements de développement, de test et d’exploitation
PCI DSS : exigence 6.5 — Séparation des environnements de développement/test et de production
SOC 2 : CC6.1 — Contrôles d’accès logiques entre environnements

Preuve typique du constat

La revue de l’infrastructure révèle des ressources partagées entre les environnements. Les mêmes identifiants fonctionnent en développement et en production. Le personnel de développement dispose d’un accès administratif aux environnements de production. Des données de production sont utilisées en développement ou en test sans anonymisation.

Remédiation attendue

Mettre en place des frontières claires entre les environnements, avec une infrastructure, des identifiants et des contrôles d’accès distincts. Restreindre l’accès à la production au personnel d’exploitation autorisé et aux comptes de service du pipeline. Mettre en œuvre l’anonymisation des données ou des données synthétiques pour les environnements hors production.

Gravité : élevée

Constat 10 : application incohérente des contrôles entre les équipes ou les pipelines

Description

Les contrôles sont appliqués de manière incohérente au sein de l’organisation. Certaines équipes disposent de pipelines bien gouvernés, avec des points d’approbation, des analyses de sécurité et une conservation des preuves, tandis que d’autres équipes fonctionnent avec des contrôles de pipeline minimaux, voire inexistants.

Pourquoi c’est important

La conformité est une obligation organisationnelle, et non une option au niveau de l’équipe. Une application incohérente des contrôles signifie que la posture de conformité de l’organisation n’est jamais plus solide que son pipeline le plus faible. Cela signale également une lacune de gouvernance : l’absence d’une norme d’entreprise pour les contrôles de pipeline et l’absence d’un mécanisme pour faire respecter cette norme.

Références réglementaires

DORA : le cadre de gestion des risques informatiques doit couvrir l’ensemble de l’organisation
NIS2 : les mesures de gestion des risques doivent être complètes et proportionnées
ISO 27001 : le périmètre du SMSI doit être défini et les contrôles appliqués de manière cohérente au sein de ce périmètre
SOC 2 : les contrôles doivent être appliqués à tous les systèmes et processus inclus dans le périmètre

Preuve typique du constat

La comparaison des configurations de pipeline entre les équipes révèle des variations importantes dans la mise en œuvre des contrôles. Certains pipelines ne disposent pas des points d’approbation, des analyses de sécurité ou de la conservation des preuves que d’autres possèdent. Aucune norme de gouvernance des pipelines à l’échelle de l’organisation n’existe, ou elle existe mais n’est pas appliquée.

Remédiation attendue

Définir une norme de gouvernance des pipelines à l’échelle de l’organisation précisant les contrôles minimaux requis. Mettre en place des mécanismes pour faire respecter cette norme (modèles de pipeline, politique-en-tant-que-code, analyse de conformité des configurations de pipeline). Réaliser une évaluation des écarts sur tous les pipelines et corriger les non-conformités.

Gravité : moyenne à élevée

Synthèse : constats, impact réglementaire et priorité de remédiation

Constat	DORA	NIS2	ISO 27001	SOC 2	PCI DSS	Gravité	Priorité de remédiation
1. Comptes de service partagés	Oui	Oui	Oui	Oui	Oui	Élevée	Immédiate
2. Points d’approbation contournables	Oui	Oui	Oui	Oui	Oui	Élevée	Immédiate
3. Absence de conservation / journaux modifiables	Oui	Oui	Oui	Oui	Oui	Élevée	Immédiate
4. Secrets codés en dur	Oui	Oui	Oui	Oui	Oui	Critique	Immédiate
5. Analyses de sécurité sans points de contrôle	Oui	Oui	Oui	Oui	Oui	Élevée	Élevée
6. Absence de SBOM / inventaire des composants	Oui	Oui	Oui	Oui	Partiel	Moyenne à élevée	Élevée
7. Accès direct à la production	Oui	Oui	Oui	Oui	Oui	Critique	Immédiate
8. Suppression de vulnérabilités non gouvernée	Oui	Oui	Oui	Oui	Oui	Élevée	Élevée
9. Absence de séparation des environnements	Oui	Oui	Oui	Oui	Oui	Élevée	Élevée
10. Contrôles incohérents entre équipes	Oui	Oui	Oui	Oui	Oui	Moyenne à élevée	Moyenne

Comment ces constats apparaissent généralement lors des audits

Comprendre comment les auditeurs découvrent ces constats aide les équipes de conformité à mieux se préparer :

Questions d’entretien : « Expliquez-moi comment un changement de code parvient en production. » « Qui peut approuver un déploiement ? » « Comment les secrets sont-ils gérés ? » Ces questions ouvertes révèlent souvent des faiblesses de contrôle à travers les réponses données — ou l’incapacité à répondre de manière cohérente.
Demandes de preuves : « Montrez-moi les journaux du pipeline d’il y a trois mois. » « Fournissez la trace d’approbation de ce déploiement précis. » « Montrez-moi votre SBOM pour cette application. » L’incapacité à produire rapidement des preuves constitue en soi un constat.
Revues de configuration : les auditeurs demandent de plus en plus accès aux configurations de pipeline, aux paramètres de contrôle d’accès et aux configurations des outils de sécurité. Ces revues révèlent si les contrôles existent en pratique, et non seulement dans la politique.
Recoupements : comparer les enregistrements de déploiement avec les traces d’approbation, comparer les configurations de production avec les sorties du pipeline, et comparer les résultats des analyses de sécurité avec les décisions de déploiement. Les incohérences entre ces sources révèlent des défaillances de contrôle.

Reconnaissance de schémas : ce que révèlent les combinaisons de constats

Les constats isolés sont préoccupants, mais les combinaisons de constats révèlent des problèmes de gouvernance plus profonds. Lorsque le constat 1 (comptes de service partagés) et le constat 2 (points d’approbation contournables) apparaissent ensemble, ils signalent une absence fondamentale de gouvernance des accès — et non de simples lacunes de contrôle isolées. De même, si le constat 5 (analyses sans points de contrôle) et le constat 8 (suppressions non gouvernées) coexistent, le programme de tests de sécurité de l’organisation est en réalité décoratif.

Les auditeurs devraient rechercher ces schémas, car ils indiquent si les constats sont des faiblesses isolées pouvant être corrigées individuellement, ou les symptômes d’une lacune plus large de maturité de la gouvernance nécessitant une réponse plus globale.

Recommandations pour les équipes de conformité

Utilisez cette liste comme une liste de contrôle d’auto-évaluation préalable à l’audit. Pour chaque constat :

Déterminez si le constat existe dans votre environnement.
Si tel est le cas, évaluez sa portée : est-il isolé à des équipes ou des pipelines spécifiques, ou est-il généralisé ?
Documentez honnêtement l’état actuel — tenter de dissimuler des problèmes connus aux auditeurs aggrave invariablement la situation.
Élaborez un plan de remédiation assorti de délais réalistes et d’une responsabilité clairement attribuée.
Si la remédiation ne peut pas être achevée avant l’audit, préparez un plan de remédiation documenté à présenter aux auditeurs, démontrant la prise de conscience et la volonté de traiter le problème.

L’identification et la remédiation proactives de ces constats courants témoignent d’une maturité de gouvernance et réduisent considérablement le risque d’issues d’audit défavorables.

Ressources connexes

Pour des recommandations complémentaires sur la préparation aux audits CI/CD et l’identification des signaux d’alerte, voir :

Ressources connexes pour les auditeurs

Glossaire — Définitions en langage clair des termes techniques
Comment les auditeurs examinent le CI/CD
Guide pratique du jour d’audit
Liste de contrôle de préparation à l’audit

Nouveau dans l’audit CI/CD ? Commencez par notre Guide de l’auditeur.