Traiter le CI/CD comme un système réglementé d’application et d’audit
Introduction
Dans les environnements réglementés, les pipelines CI/CD sont souvent mal compris comme des outils de productivité développeur.
En réalité, ce sont des systèmes d’application des contrôles.
Lorsqu’il est correctement conçu, un pipeline CI/CD devient :
- Le chemin unique autorisé vers la production
- Le moteur d’application des politiques de sécurité
- Le générateur de preuves d’audit continues
- L’implémentation technique de la séparation des tâches
Cet article présente un modèle d’architecture CI/CD-only, où le pipeline lui-même est traité comme un système réglementé responsable de l’application des contrôles, des approbations et de la traçabilité.
1. Pourquoi « CI/CD Only » est important
Dans de nombreuses organisations, les contrôles de sécurité et de conformité sont fragmentés entre :
- Les systèmes de ticketing
- Les approbations par email
- Des outils de gouvernance séparés
- Des processus de validation manuels
Cette fragmentation crée des lacunes :
- Application incohérente
- Opportunités de contournement
- Pistes de preuves faibles
- Complexité d’audit
Une architecture CI/CD-only consolide l’application dans un système unique et contrôlé.
Si cela ne passe pas par le pipeline, cela n’atteint pas la production.
2. Principes fondamentaux d’une architecture CI/CD-Only
2.1 Chemin unique vers la production
Tous les changements en production doivent :
- Provenir de dépôts contrôlés par version
- Passer par le pipeline CI/CD
- Être approuvés dans des portes de workflow contrôlées
- Générer des journaux traçables
L’accès direct à la production est minimisé ou éliminé.
2.2 Application intégrée des politiques
Les politiques de sécurité et de conformité sont implémentées comme :
- Des vérifications automatisées
- Des portes de politique
- Des contrôles bloquants
- Des seuils configurables
Exemples :
- Application SAST et DAST
- Conformité des politiques de dépendances
- Exigences de génération SBOM
- Workflows d’approbation obligatoires
Les contrôles sont obligatoires et déterministes, pas consultatifs.
2.3 Séparation des tâches via la conception des workflows
Une architecture CI/CD réglementée applique :
- Le développeur ne peut pas approuver sa propre livraison
- Rôles séparés pour le build et le déploiement
- Processus de dérogation contrôlés
- Gestion des exceptions journalisée
La séparation est appliquée techniquement — pas documentée comme intention.
2.4 Génération de preuves par défaut
Chaque exécution de pipeline produit :
- Des journaux d’exécution
- Des résultats de scans de sécurité
- Des enregistrements d’approbation
- Des métadonnées d’artefacts
- Des marqueurs de traçabilité
Les preuves sont :
- Générées par le système
- Horodatées
- Conservées
- Corrélables
Le pipeline devient une usine à preuves d’audit.
3. Couches architecturales
Un modèle CI/CD-only comprend généralement trois couches logiques :
Couche 1 : Contrôles de gouvernance
- Gestion des identités et des accès (IAM)
- Permissions basées sur les rôles
- Séparation des tâches
- Policy-as-code
- Gouvernance des exceptions
Cette couche assure le contrôle sur qui peut agir et sous quelles conditions.
Couche 2 : Application du pipeline
- Validation du code source
- Tests statiques et dynamiques
- Analyse des dépendances
- Portes de politique
- Workflows d’approbation
- Signature des artefacts
Cette couche assure le contrôle sur ce qui est livré et comment.
Couche 3 : Preuves & conservation
- Stockage centralisé des journaux
- Enregistrements d’audit immuables
- Historique des approbations
- Mapping de traçabilité (commit → build → artefact → production)
- Conservation alignée avec les exigences réglementaires
Cette couche assure le contrôle sur ce qui peut être prouvé ultérieurement.
4. Modèle de traçabilité
Une architecture CI/CD réglementée établit une traçabilité complète :
- ID de commit
- Revue de pull request
- Exécution du pipeline
- Artefact de build
- Décision d’approbation
- Événement de déploiement
- Surveillance runtime
Chaque étape est liée par des identifiants cohérents.
Les auditeurs échantillonnent fréquemment un changement en production et demandent :
« Montrez-moi la chaîne complète du code à la production. »
Dans un modèle CI/CD-only, cela est reproductible et déterministe.
5. Ce que cette architecture empêche
Un modèle CI/CD-only correctement conçu empêche :
- Les déploiements hors bande
- Les livraisons en production non approuvées
- Les échecs silencieux des vérifications de sécurité
- L’application incohérente des contrôles
- Les preuves manquantes pendant les audits
Il supprime la dépendance à la mémoire, aux emails ou aux workflows non documentés.
6. Alignement avec les cadres réglementaires
Cette architecture soutient directement :
- DORA (gestion des risques ICT & supervision des tiers)
- ISO 27001 (contrôle des changements & développement sécurisé)
- SOC 2 (accès logique & gestion des changements)
- NIS2 (résilience opérationnelle & sécurité de la supply chain)
- PCI DSS (développement sécurisé & gestion des vulnérabilités)
Plutôt que de construire la conformité séparément, l’architecture produit la conformité en continu.
7. Idées reçues courantes
« Nous avons des outils de sécurité dans CI/CD, donc nous sommes conformes. »
Les outils ne garantissent pas l’application.
Les auditeurs examinent :
- Si les échecs bloquent le déploiement
- Si les contrôles peuvent être contournés
- Si les journaux sont conservés
- Si les approbations sont séparées par rôle
La conformité exige une application systémique.
« Les approbations par email sont suffisantes. »
Les approbations externes créent :
- Une fragmentation des preuves
- Une traçabilité faible
- Des lacunes de gouvernance
Les approbations doivent être intégrées dans le workflow du pipeline.
8. Quand le CI/CD devient un système ICT réglementé
Dans les environnements financiers réglementés, les pipelines CI/CD doivent être :
- Inclus dans les inventaires d’actifs ICT
- Couverts par les évaluations de risques
- Gouvernés par la gestion des changements
- Soumis à des revues d’accès
- Testés dans des scénarios d’incidents
À ce niveau de maturité, le CI/CD n’est pas un support d’infrastructure — c’est un système de contrôle réglementé.
9. Niveaux de maturité de l’application CI/CD
Niveau 1 — Consultatif
Les vérifications de sécurité existent mais ne bloquent pas les livraisons.
Niveau 2 — Application partielle
Certains contrôles sont bloquants, d’autres optionnels.
Niveau 3 — Application réglementée
Tous les contrôles critiques sont obligatoires et auditables.
Niveau 4 — Gouvernance basée sur les preuves
Traçabilité complète, reporting automatisé, tests de résilience et préparation à la sortie.
Les environnements réglementés devraient opérer au Niveau 3 ou supérieur.
Conclusion
Une architecture CI/CD-only repositionne le pipeline comme :
- Un moteur d’application de la sécurité
- Un mécanisme de gouvernance
- Une implémentation de la séparation des tâches
- Un générateur de preuves de conformité
Dans les environnements réglementés, la vitesse de livraison et le contrôle réglementaire ne sont pas des opposés.
Lorsqu’il est conçu correctement, le CI/CD devient la colonne vertébrale technique d’une conformité continue et auditable.
Articles connexes
- Modèles d’application basés sur CI/CD
- Comment les auditeurs évaluent l’application CI/CD
- Fondamentaux du Secure SDLC
- Conformité continue via CI/CD sous DORA
