Les pipelines CI/CD sont de plus en plus inclus dans le périmètre des audits de sécurité et réglementaires. Alors que de nombreuses organisations se concentrent sur les politiques et les descriptions d’outils, les auditeurs évaluent les pipelines CI/CD de manière très différente en pratique.
Ce guide explique comment les auditeurs abordent réellement les revues CI/CD, ce qu’ils examinent en premier, comment ils testent les contrôles, et pourquoi de nombreuses organisations échouent aux audits malgré des pipelines « sécurisés » sur le papier.
Les auditeurs ne commencent pas par les outils
Contrairement à une croyance répandue, les auditeurs commencent rarement par demander quelle plateforme CI/CD ou quels outils de sécurité sont utilisés. Ils commencent par déterminer si les pipelines CI/CD sont traités comme des systèmes ICT réglementés.
Les premières questions que les auditeurs posent typiquement sont :
- Les pipelines CI/CD sont-ils inclus dans le périmètre de gestion des risques ?
- Qui est responsable de la sécurité CI/CD et de la gouvernance ?
- L’organisation peut-elle démontrer un contrôle sur le comportement des pipelines ?
Si les pipelines sont traités comme de simples outils de développement, cela est souvent signalé comme un écart de maturité dès le début de l’audit.
Étape 1 : Cadrage du CI/CD comme système réglementé
Les auditeurs vérifient d’abord si les pipelines CI/CD sont explicitement inclus dans :
- Les inventaires de systèmes ICT
- Les évaluations de risques
- Les périmètres de conformité
Ils vérifient si les pipelines sont classés selon leur criticité et si leur impact sur les systèmes de production est clairement compris.
Les organisations échouent fréquemment à cette étape en excluant le CI/CD du périmètre ICT formel, même lorsque les pipelines ont un accès direct à la production.
Étape 2 : Évaluation de la gouvernance et de la responsabilité
Une fois les pipelines CI/CD dans le périmètre, les auditeurs évaluent la gouvernance. Ils recherchent des réponses claires à :
- Qui approuve les changements d’architecture CI/CD ?
- Qui peut modifier les définitions de pipelines ?
- Qui est responsable des pannes ou incidents de sécurité des pipelines ?
Les auditeurs ne se satisfont pas d’une responsabilité informelle. Ils attendent des rôles documentés, des responsabilités définies et des preuves que la gouvernance est appliquée de manière cohérente.
Étape 3 : Contrôle d’accès et revue des privilèges
Le contrôle d’accès est l’un des domaines les plus scrutés lors des audits CI/CD.
Les auditeurs examinent :
- Qui peut administrer les plateformes CI/CD
- Qui peut modifier les pipelines
- Comment les credentials des pipelines sont gérés
- Si les comptes de service respectent le principe du moindre privilège
Ils demandent souvent des démonstrations en direct ou des exports de configuration pour valider que les permissions sont appliquées techniquement, pas seulement décrites dans des politiques.
Étape 4 : Séparation des fonctions en pratique
Les auditeurs testent la séparation des fonctions en analysant les workflows, pas les diagrammes.
Les vérifications typiques incluent :
- Un développeur peut-il approuver son propre déploiement en production ?
- Les permissions de build et de déploiement sont-elles séparées ?
- Les dérogations d’urgence sont-elles journalisées et revues ?
Même des pipelines bien conçus échouent aux audits lorsque les exceptions ne sont pas documentées ou sont trop permissives.
Étape 5 : Preuves de gestion des changements
Les auditeurs portent une attention particulière à la façon dont les changements transitent par les pipelines CI/CD.
Ils vérifient :
- Que tous les changements en production passent par le CI/CD
- Que les approbations sont obligatoires et traçables
- Que les déploiements hors bande sont empêchés ou journalisés
Les auditeurs sélectionnent souvent des changements de production au hasard et demandent aux équipes de démontrer la traçabilité de bout en bout, du code source au déploiement.
Étape 6 : Contrôles de sécurité et automatisation
Les tests de sécurité sont évalués comme un mécanisme d’application, pas comme un élément de checklist.
Les auditeurs recherchent :
- Des vérifications de sécurité obligatoires (SAST, SCA, DAST)
- Des gates de politique qui bloquent les builds non conformes
- Des preuves que les vérifications échouées empêchent le déploiement
Les scans optionnels ou consultatifs sont généralement considérés comme insuffisants dans les environnements réglementés.
Étape 7 : Journalisation, surveillance et détection
Les auditeurs vérifient si les pipelines CI/CD produisent des logs exploitables et conservés.
Ils évaluent :
- La complétude des logs de pipeline
- La collecte centralisée des logs
- La rétention alignée sur les exigences réglementaires
- La capacité à investiguer les incidents historiques
Un échec courant est d’avoir des logs qui existent mais ne sont pas conservés assez longtemps ou ne peuvent pas être corrélés.
Étape 8 : Qualité et reproductibilité des preuves
Les auditeurs favorisent fortement les preuves générées par le système plutôt que les captures d’écran ou documents.
Ils attendent :
- Des logs horodatés
- Des enregistrements immuables
- Des preuves reproductibles
- Une cohérence entre les équipes et les pipelines
Si les preuves dépendent d’une explication manuelle, les auditeurs les considèrent comme faibles.
Étape 9 : Scénarios d’incidents et de résilience
Les auditeurs testent de plus en plus le comportement des pipelines CI/CD lors d’incidents.
Ils demandent :
- Que se passe-t-il si un pipeline est compromis ?
- Comment les credentials sont-ils révoqués ?
- Comment les releases sont-elles stoppées ou annulées ?
Les organisations qui ne peuvent pas répondre de manière convaincante à ces questions font souvent face à des constats liés à la résilience opérationnelle.
Pourquoi les organisations échouent aux audits CI/CD
Les schémas d’échec courants incluent :
- CI/CD exclu du périmètre de conformité
- Privilèges excessifs accordés aux pipelines
- Faible séparation des fonctions
- Contrôles de sécurité optionnels
- Mauvaise rétention des logs
- Dépendance excessive à la documentation plutôt qu’aux preuves
Ces échecs sont rarement liés aux outils ; ce sont des problèmes de gouvernance et de conception.
Comment préparer le CI/CD pour les vrais audits
Les organisations qui réussissent les audits :
- Traitent le CI/CD comme un système ICT réglementé
- Intègrent les contrôles directement dans les pipelines
- Génèrent des preuves en continu
- Alignent les équipes sécurité, engineering et conformité
- Testent les scénarios d’audit avant que les audits ne surviennent
Les pipelines CI/CD deviennent alors des atouts de conformité plutôt que des passifs d’audit.
Conclusion
Les auditeurs n’auditent pas les pipelines CI/CD de la façon dont les ingénieurs les conçoivent sur des tableaux blancs. Ils auditent l’application des contrôles, la traçabilité et la qualité des preuves.
Les organisations qui comprennent comment les auditeurs examinent réellement les pipelines CI/CD sont bien mieux préparées pour répondre aux attentes réglementaires. En alignant la conception CI/CD avec la réalité de l’audit, les équipes peuvent réduire les constats, améliorer la résilience et construire une confiance durable avec les régulateurs.
Ressources associées
- Compliance
- CI/CD Security
- DORA Article 21 Deep Dive
- DORA Article 21 Auditor Checklist
- DORA Article 21 Evidence Pack
