Commencez ici — Guide de l'auditeur pour la sécurité CI/CD

Bienvenue, auditeur

Si vous auditez, évaluez ou gouvernez des organisations qui livrent des logiciels, ce site est fait pour vous. La livraison logicielle moderne s’appuie sur des pipelines automatisés (CI/CD) de plus en plus soumis à la surveillance réglementaire — au titre de DORA, NIS2, ISO 27001, SOC 2 et PCI DSS.

Parcours en cinq étapes pour auditer la CI/CD en confiance

Vous n’avez pas besoin de comprendre le code pour auditer des pipelines CI/CD. Vous devez comprendre les contrôles, les preuves et ce à quoi ressemble une bonne gouvernance. Ce guide vous donne cette base.

Ce guide vous aide à naviguer sur le site et à gagner en confiance pour évaluer les environnements CI/CD, même sans bagage technique approfondi.

Qu’est-ce qu’un pipeline CI/CD ?

Un pipeline CI/CD est un système automatisé qui prend le code écrit par les développeurs et le fait passer par une série d’étapes — construction, test, analyse, approbation, déploiement — avant qu’il n’atteigne la production. Voyez-le comme une chaîne de montage contrôlée pour le logiciel, où chaque poste effectue un contrôle de qualité ou de sécurité précis.

Voici une vue simplifiée d’un pipeline typique :

CODE → BUILD → TEST → SCAN → APPROVE → DEPLOY → MONITOR

Chaque étape a une finalité distincte — et chacune compte pour l’assurance d’audit :

CODE — Les développeurs écrivent et valident (commit) leurs changements dans un dépôt sous contrôle de version. Les auditeurs s’y intéressent car c’est là que commence la traçabilité des changements.
BUILD — Le code source est compilé en artefacts déployables. Les auditeurs s’y intéressent car l’intégrité de la construction garantit que ce qui a été revu est bien ce qui est déployé.
TEST — Les tests automatisés valident la fonctionnalité et détectent les régressions. Les auditeurs s’en soucient car les preuves de test démontrent la diligence raisonnable en assurance qualité.
SCAN — Les scanners de sécurité vérifient les vulnérabilités, les erreurs de configuration et les risques de licence. Les auditeurs s’en soucient car c’est un contrôle principal pour identifier les faiblesses connues avant le déploiement.
APPROVE — Des gates d’approbation humaines ou automatisées décident si le changement se poursuit. Les auditeurs s’en soucient car l’application de l’approbation est la pierre angulaire de la séparation des fonctions.
DEPLOY — L’artefact est publié en production via un processus automatisé et reproductible. Les auditeurs s’en soucient car les contrôles de déploiement déterminent si des changements non autorisés peuvent atteindre la production.
MONITOR — Les systèmes en production détectent les anomalies, les problèmes de performance et les événements de sécurité. Les auditeurs s’y intéressent car la surveillance boucle la rétroaction et permet la détection des incidents.

Point clé : Un pipeline bien conçu rend la sécurité obligatoire. Un pipeline mal conçu rend la sécurité optionnelle.

L’architecture du pipeline détermine si les contrôles de sécurité sont obligatoires (appliqués par conception) ou optionnels (dépendants de la discipline individuelle). Cette distinction est essentielle pour les auditeurs : un pipeline bien conçu fait de la conformité une propriété du système, pas un projet périodique.

Besoin de définitions ? Consultez notre Glossaire pour des explications en langage clair des termes techniques.

Pourquoi les auditeurs doivent comprendre la livraison logicielle

Les réglementations exigent désormais explicitement des organisations qu’elles gouvernent leurs systèmes de livraison logicielle :

DORA (Digital Operational Resilience Act) — traite les pipelines CI/CD comme des systèmes ICT soumis à la gestion des risques, aux tests et à la supervision des tiers
NIS2 — exige la sécurité de la chaîne d’approvisionnement, le signalement des incidents et des mesures de gestion des risques qui impliquent directement la livraison logicielle
ISO 27001 — Les contrôles de l’Annexe A couvrent le développement des systèmes, la gestion des changements et les relations avec les fournisseurs
SOC 2 — Les critères de services de confiance pour la gestion des changements (CC8), l’accès logique (CC6) et les opérations système (CC7) touchent tous le CI/CD
PCI DSS v4.0 — L’exigence 6 impose des pratiques de développement sécurisé et la gestion des vulnérabilités

Le tableau suivant met en correspondance des exigences réglementaires précises avec ce qu’elles imposent pour la livraison logicielle :

Réglementation	Article / exigence	Ce qu’elle impose pour la livraison logicielle
DORA	Art. 9	Le cadre de gestion des risques TIC doit couvrir les systèmes CI/CD, y compris les capacités de protection, de détection et de réponse
DORA	Art. 21	La gestion des changements TIC doit être contrôlée, testée et approuvée — directement applicable à la gouvernance des pipelines
DORA	Art. 28	La gestion des risques TIC liés aux tiers s’étend aux fournisseurs cloud, aux outils SaaS et aux prestataires de services de pipeline
NIS2	Art. 21	Les mesures de gestion des risques doivent traiter la sécurité de la chaîne d’approvisionnement, le traitement des vulnérabilités et les pratiques de développement sécurisé
ISO 27001	A.8.25	Cycle de développement sécurisé — la sécurité doit être intégrée dès la conception du processus de développement
ISO 27001	A.8.28	Pratiques de codage sécurisé — le code doit être développé, revu et testé selon des normes de sécurité
ISO 27001	A.8.29	Tests de sécurité en développement et en recette — les tests doivent vérifier que les exigences de sécurité sont respectées
SOC 2	CC6	Contrôles d’accès logiques et physiques — restreindre qui peut modifier les configurations de pipeline et déployer en production
SOC 2	CC7	Exploitation des systèmes — surveillance, détection et réponse aux incidents pour l’infrastructure CI/CD
SOC 2	CC8	Gestion des changements — les changements doivent être autorisés, testés et approuvés avant leur mise en œuvre
PCI DSS	Req. 6	Développer et maintenir des systèmes sécurisés — comprend le codage sécurisé, la gestion des vulnérabilités et les contrôles de changement
PCI DSS	Req. 8	Identifier les utilisateurs et authentifier les accès — MFA et contrôles d’accès pour les systèmes de pipeline et de déploiement
PCI DSS	Req. 10	Journaliser et surveiller tous les accès — pistes d’audit pour l’activité des pipelines, les déploiements et les changements de configuration

Si la livraison logicielle n’est pas dans le périmètre de votre audit, vous passez peut-être à côté d’une surface de contrôle critique.

Les 5 points que tout auditeur devrait vérifier

Quel que soit le cadre réglementaire, ces cinq domaines constituent le socle de l’assurance d’audit CI/CD :

1. Intégrité du pipeline

Les configurations de pipeline peuvent-elles être modifiées sans approbation ? Les étapes sont-elles obligatoires ou contournables ? Existe-t-il des preuves d’une exécution inaltérable ?

Preuves à demander : les fichiers de configuration du pipeline (YAML/JSON) stockés sous contrôle de version, les journaux d’audit des modifications de définition du pipeline, les règles de protection de branche empêchant les modifications directes.
Signal d’alerte : les définitions de pipeline peuvent être modifiées directement dans l’interface de l’outil CI/CD sans contrôle de version ni approbation — ce qui signifie que toute personne disposant d’un accès peut supprimer discrètement des étapes de sécurité.
Analyse approfondie : Core CI/CD Security Controls

2. Contrôles d’accès et séparation des tâches

La même personne peut-elle écrire du code et le déployer en production ? Les rôles privilégiés sont-ils protégés par MFA ? Des revues d’accès sont-elles réalisées ?

Preuves à demander : la matrice de contrôle d’accès basé sur les rôles (RBAC) pour les outils CI/CD, les journaux d’application du MFA, les enregistrements de revues d’accès périodiques, la preuve que le déploiement requiert un approbateur différent de l’auteur du code.
Signal d’alerte : un même compte utilisateur dispose à la fois des autorisations « merge to main » et « deploy to production » sans aucune approbation secondaire requise.
Analyse approfondie : Comment les auditeurs examinent réellement les pipelines CI/CD

3. Gestion des secrets

Les identifiants sont-ils stockés dans un coffre-fort centralisé ? Sont-ils renouvelés automatiquement ? Des secrets peuvent-ils apparaître dans les journaux ou le code ?

Preuves à demander : la configuration du coffre-fort et les politiques d’accès, les calendriers de rotation des secrets, la configuration du masquage des journaux, les résultats d’analyse des outils de détection de secrets (par ex. GitLeaks, TruffleHog).
Signal d’alerte : des identifiants sont codés en dur dans les fichiers de configuration du pipeline ou dans des variables d’environnement visibles dans les journaux de construction.
Analyse approfondie : Glossaire — gestion des secrets

4. Provenance des artefacts

Les artefacts déployés sont-ils signés et traçables jusqu’à une exécution précise du pipeline ? Des artefacts non signés ou non analysés peuvent-ils atteindre la production ?

Preuves à demander : les certificats de signature d’artefacts et les politiques de vérification, la nomenclature logicielle (SBOM) des déploiements récents, les signatures d’images de conteneurs, les règles de politique en tant que code qui bloquent les artefacts non signés.
Signal d’alerte : les conteneurs de production sont récupérés depuis un registre public sans vérification de signature ni analyse de vulnérabilités.
Analyse approfondie : Glossaire — SBOM (nomenclature logicielle)

5. Application de l’approbation des changements

Les revues de pull requests sont-elles obligatoires ? Les approbations sont-elles journalisées ? Des changements d’urgence peuvent-ils contourner les contrôles sans exceptions documentées ?

Preuves à demander : les règles de protection de branche exigeant des approbations, les journaux d’audit de fusion indiquant l’identité des relecteurs, la documentation de la procédure de changement d’urgence, les journaux d’exceptions avec justification et revue post-incident.
Signal d’alerte : la fonction « admin override » est utilisée régulièrement pour contourner les revues obligatoires, sans documentation d’exception ni audit de suivi.
Analyse approfondie : Guide pratique du jour de l’audit

Parcours de lecture

Choisissez le parcours qui correspond le mieux à votre rôle et à vos objectifs :

Si vous débutez dans l’audit CI/CD :

Glossaire — apprenez d’abord la terminologie
Ce guide — comprenez la structure et les concepts clés
Contrôles de sécurité CI/CD essentiels — les contrôles indispensables que tout pipeline devrait avoir
Comment les auditeurs examinent réellement les pipelines CI/CD — méthodologie de revue pratique

Si vous évaluez plusieurs cadres :

Architecture de double conformité — comment satisfaire efficacement des exigences qui se chevauchent
Matrice de recouvrement ISO 27001 vs DORA vs NIS2 — comparaison côte à côte des exigences de contrôle
Analyse du recouvrement NIS2 vs DORA — cartographie détaillée des obligations communes et distinctes

Si vous préparez un audit :

Comment ce site est organisé

Cadres réglementaires — DORA, NIS2 et des analyses approfondies par réglementation
Audit et gouvernance — ce que les auditeurs évaluent, les modèles de gouvernance, les niveaux de maturité
Architecture — le CI/CD comme système d’application, modèles de maturité
Gouvernance de la sécurité applicative — SDLC sécurisé, cadres de gestion des risques
Modèles opérationnels DevSecOps — rôles, responsabilités, cadres opérationnels
Glossaire — définitions en langage clair des termes techniques

Pour des orientations de mise en œuvre technique (code, configurations, installation des outils), visitez notre site partenaire secure-pipelines.com.

Référence rapide

Ressources fréquemment utilisées sur l’ensemble du site :

Glossaire — définitions en langage clair des termes CI/CD et de sécurité
Constats d’audit fréquents — top 10 — les défaillances de contrôle CI/CD les plus fréquentes rencontrées par les auditeurs
Briefing d’audit pour dirigeants — synthèse de haut niveau pour la direction et le reporting au conseil
Répertoire complet des ressources — index complet de tous les guides, listes de vérification et documents de référence

Ce site est conçu pour renforcer votre confiance dans l’évaluation des environnements CI/CD. Chaque article est rédigé de votre point de vue — contrôles, preuves et vérification. Aucun code requis.