Cette cartographie d’audit orientée conformité relie les contrôles fondamentaux de sécurité CI/CD aux référentiels réglementaires et d’assurance qui régissent le plus souvent les pipelines de livraison réglementés : ISO 27001, SOC 2, DORA, la directive NIS2 et PCI DSS.
Elle vise à soutenir les audits internes, les évaluations externes et la préparation réglementaire dans les environnements d’entreprise — de la certification de sécurité de l’information à la gestion du risque TIC, en passant par les obligations liées aux infrastructures critiques et la sécurité des paiements.
Plutôt que de traiter chaque référentiel isolément, la cartographie regroupe les mêmes contrôles de pipeline sous-jacents — identité et accès, gestion des secrets, intégrité des artefacts, intégrations tierces, journalisation et gouvernance des changements — et montre où chacun satisfait les exigences d’un référentiel donné. Un contrôle unique bien mené répond fréquemment à plusieurs référentiels à la fois, ce qui constitue la base pratique d’une approche unifiée de la conformité où les preuves sont recueillies une fois puis réutilisées d’une évaluation à l’autre.
ISO 27001
ISO/IEC 27001:2022 évalue si les contrôles CI/CD fonctionnent au sein d’un système de management de la sécurité de l’information (SMSI) opérationnel, et pas seulement si un paramètre d’outil existe. Les auditeurs attendent une responsabilité des contrôles documentée, une déclaration d’applicabilité exacte et des preuves que les contrôles sont surveillés et améliorés dans le temps. Pour les pipelines, les références les plus pertinentes de l’annexe A relèvent du contrôle d’accès, du développement sécurisé et des relations avec les fournisseurs. Attentes en matière de preuves : la déclaration d’applicabilité, les enregistrements de revue des accès, les procédures de développement sécurisé et les journaux montrant que chaque contrôle s’est exécuté comme décrit.
| Domaine | Contrôle | ISO 27001 (annexe A) | Oui | Non |
|---|---|---|---|---|
| IAM | Moindre privilège appliqué aux comptes de service CI/CD | A.8.2 / A.5.15 | ⬜ | ⬜ |
| IAM | Séparation entre identités humaines et identités de pipeline | A.6.3 | ⬜ | ⬜ |
| IAM | Accès basé sur les rôles pour la configuration du pipeline | A.5.18 | ⬜ | ⬜ |
| IAM | MFA appliquée aux administrateurs CI/CD | A.5.17 | ⬜ | ⬜ |
| IAM | Approbation requise pour les actions privilégiées du pipeline | A.5.19 | ⬜ | ⬜ |
| Secrets | Secrets non stockés dans la gestion de code source | A.8.12 | ⬜ | ⬜ |
| Secrets | Injection des secrets à l’exécution | A.8.24 | ⬜ | ⬜ |
| Secrets | Secrets limités à leur environnement | A.5.15 | ⬜ | ⬜ |
| Secrets | Rotation régulière des secrets | A.8.15 | ⬜ | ⬜ |
| Secrets | Valeurs des secrets exclues des journaux | A.8.16 | ⬜ | ⬜ |
| Intégrité des artefacts | Environnements de build CI/CD durcis | A.8.20 | ⬜ | ⬜ |
| Intégrité des artefacts | Signature des artefacts appliquée | A.8.23 | ⬜ | ⬜ |
| Intégrité des artefacts | Provenance reliant code, pipeline et artefact | A.8.9 | ⬜ | ⬜ |
| Intégrité des artefacts | Les dépôts d’artefacts imposent l’immuabilité | A.8.10 | ⬜ | ⬜ |
| Intégrité des artefacts | Promotion limitée aux artefacts de confiance | A.8.21 | ⬜ | ⬜ |
| Intégrations tierces | Plugins CI/CD tiers formellement approuvés | A.5.22 | ⬜ | ⬜ |
| Intégrations tierces | Intégrations épinglées à des versions précises | A.8.8 | ⬜ | ⬜ |
| Intégrations tierces | Vérification de l’intégrité des actions externes | A.8.23 | ⬜ | ⬜ |
| Intégrations tierces | Restriction des plugins maintenus par la communauté | A.5.23 | ⬜ | ⬜ |
| Intégrations tierces | Surveillance de l’usage des intégrations | A.8.16 | ⬜ | ⬜ |
| Journalisation et surveillance | Activité du pipeline CI/CD intégralement journalisée | A.8.15 | ⬜ | ⬜ |
| Journalisation et surveillance | Les journaux incluent les approbations et les contrôles de sécurité | A.8.14 | ⬜ | ⬜ |
| Journalisation et surveillance | Collecte centralisée des journaux | A.8.16 | ⬜ | ⬜ |
| Journalisation et surveillance | Conservation des journaux conforme à la politique | A.5.34 | ⬜ | ⬜ |
| Journalisation et surveillance | Les preuves soutiennent l’audit et les investigations | A.5.31 | ⬜ | ⬜ |
| Changements et gouvernance | Changements revus et approuvés via le pipeline | A.8.32 | ⬜ | ⬜ |
| Changements et gouvernance | Séparation entre les rôles de build et de déploiement | A.6.3 | ⬜ | ⬜ |
| Changements et gouvernance | Application des politiques via des portes automatisées | A.5.19 | ⬜ | ⬜ |
| Changements et gouvernance | Exceptions formellement approuvées et journalisées | A.5.31 | ⬜ | ⬜ |
| Changements et gouvernance | Gouvernance CI/CD revue périodiquement | A.5.36 | ⬜ | ⬜ |
SOC 2
SOC 2 évalue les contrôles CI/CD au regard des critères des services de confiance (Trust Services Criteria), principalement les critères communs (la série CC) pour la sécurité. Parce que SOC 2 est une attestation portant sur une période, les auditeurs attendent la preuve que chaque contrôle a fonctionné de manière cohérente sur toute la fenêtre de revue, et non une simple capture d’écran ponctuelle. L’échantillonnage est la norme : un évaluateur peut sélectionner plusieurs mises en production et retracer, pour chacune, les approbations, les analyses et les enregistrements de déploiement. Attentes en matière de preuves : les tickets de gestion des changements, les journaux d’approbation, les enregistrements d’exceptions et les sorties de surveillance couvrant toute la période d’audit.
| Domaine | Contrôle | SOC 2 (critères communs) | Oui | Non |
|---|---|---|---|---|
| IAM | Moindre privilège appliqué aux comptes de service CI/CD | CC6.1 | ⬜ | ⬜ |
| IAM | Séparation entre identités humaines et identités de pipeline | CC6.3 | ⬜ | ⬜ |
| IAM | Accès basé sur les rôles pour la configuration du pipeline | CC6.2 | ⬜ | ⬜ |
| IAM | MFA appliquée aux administrateurs CI/CD | CC6.1 | ⬜ | ⬜ |
| IAM | Approbation requise pour les actions privilégiées du pipeline | CC7.2 | ⬜ | ⬜ |
| Secrets | Secrets non stockés dans la gestion de code source | CC6.1 | ⬜ | ⬜ |
| Secrets | Injection des secrets à l’exécution | CC6.7 | ⬜ | ⬜ |
| Secrets | Secrets limités à leur environnement | CC6.2 | ⬜ | ⬜ |
| Secrets | Rotation régulière des secrets | CC6.1 | ⬜ | ⬜ |
| Secrets | Valeurs des secrets exclues des journaux | CC7.2 | ⬜ | ⬜ |
| Intégrité des artefacts | Environnements de build CI/CD durcis | CC6.6 | ⬜ | ⬜ |
| Intégrité des artefacts | Signature des artefacts appliquée | CC7.3 | ⬜ | ⬜ |
| Intégrité des artefacts | Provenance reliant code, pipeline et artefact | CC7.2 | ⬜ | ⬜ |
| Intégrité des artefacts | Les dépôts d’artefacts imposent l’immuabilité | CC6.5 | ⬜ | ⬜ |
| Intégrité des artefacts | Promotion limitée aux artefacts de confiance | CC6.6 | ⬜ | ⬜ |
| Intégrations tierces | Plugins CI/CD tiers formellement approuvés | CC6.3 | ⬜ | ⬜ |
| Intégrations tierces | Intégrations épinglées à des versions précises | CC7.3 | ⬜ | ⬜ |
| Intégrations tierces | Vérification de l’intégrité des actions externes | CC7.3 | ⬜ | ⬜ |
| Intégrations tierces | Restriction des plugins maintenus par la communauté | CC6.6 | ⬜ | ⬜ |
| Intégrations tierces | Surveillance de l’usage des intégrations | CC7.2 | ⬜ | ⬜ |
| Journalisation et surveillance | Activité du pipeline CI/CD intégralement journalisée | CC7.2 | ⬜ | ⬜ |
| Journalisation et surveillance | Les journaux incluent les approbations et les contrôles de sécurité | CC7.3 | ⬜ | ⬜ |
| Journalisation et surveillance | Collecte centralisée des journaux | CC7.2 | ⬜ | ⬜ |
| Journalisation et surveillance | Conservation des journaux conforme à la politique | CC7.4 | ⬜ | ⬜ |
| Journalisation et surveillance | Les preuves soutiennent l’audit et les investigations | CC2.2 | ⬜ | ⬜ |
| Changements et gouvernance | Changements revus et approuvés via le pipeline | CC8.1 | ⬜ | ⬜ |
| Changements et gouvernance | Séparation entre les rôles de build et de déploiement | CC6.3 | ⬜ | ⬜ |
| Changements et gouvernance | Application des politiques via des portes automatisées | CC7.2 | ⬜ | ⬜ |
| Changements et gouvernance | Exceptions formellement approuvées et journalisées | CC2.3 | ⬜ | ⬜ |
| Changements et gouvernance | Gouvernance CI/CD revue périodiquement | CC1.2 | ⬜ | ⬜ |
DORA
Le règlement sur la résilience opérationnelle numérique (DORA) inscrit le CI/CD dans les obligations de gestion du risque TIC et de risque lié aux tiers d’une entité financière relevant de son périmètre. Son accent porte sur la résilience, la traçabilité et la supervision des prestataires TIC plutôt que sur des clauses numérotées ; les références ci-dessous relient donc les contrôles aux thèmes de DORA. Les superviseurs attendent que les pipelines soient couverts par le cadre de risque TIC, avec une résilience testée et une responsabilité claire des prestataires. Attentes en matière de preuves : la documentation du risque TIC, le registre d’informations relatif aux prestataires tiers, ainsi que les résultats des tests de résilience et de sortie.
| Domaine | Contrôle | DORA (domaine TIC) | Oui | Non |
|---|---|---|---|---|
| IAM | Moindre privilège appliqué aux comptes de service CI/CD | Gestion du risque TIC | ⬜ | ⬜ |
| IAM | Séparation entre identités humaines et identités de pipeline | Gouvernance | ⬜ | ⬜ |
| IAM | Accès basé sur les rôles pour la configuration du pipeline | Contrôle d’accès | ⬜ | ⬜ |
| IAM | MFA appliquée aux administrateurs CI/CD | Sécurité TIC | ⬜ | ⬜ |
| IAM | Approbation requise pour les actions privilégiées du pipeline | Gestion des changements | ⬜ | ⬜ |
| Secrets | Secrets non stockés dans la gestion de code source | Sécurité TIC | ⬜ | ⬜ |
| Secrets | Injection des secrets à l’exécution | Gestion du risque TIC | ⬜ | ⬜ |
| Secrets | Secrets limités à leur environnement | Gouvernance | ⬜ | ⬜ |
| Secrets | Rotation régulière des secrets | Sécurité TIC | ⬜ | ⬜ |
| Secrets | Valeurs des secrets exclues des journaux | Surveillance | ⬜ | ⬜ |
| Intégrité des artefacts | Environnements de build CI/CD durcis | Résilience TIC | ⬜ | ⬜ |
| Intégrité des artefacts | Signature des artefacts appliquée | Chaîne d’approvisionnement | ⬜ | ⬜ |
| Intégrité des artefacts | Provenance reliant code, pipeline et artefact | Traçabilité | ⬜ | ⬜ |
| Intégrité des artefacts | Les dépôts d’artefacts imposent l’immuabilité | Sécurité TIC | ⬜ | ⬜ |
| Intégrité des artefacts | Promotion limitée aux artefacts de confiance | Gestion des changements | ⬜ | ⬜ |
| Intégrations tierces | Plugins CI/CD tiers formellement approuvés | Risque lié aux tiers | ⬜ | ⬜ |
| Intégrations tierces | Intégrations épinglées à des versions précises | Chaîne d’approvisionnement | ⬜ | ⬜ |
| Intégrations tierces | Vérification de l’intégrité des actions externes | Sécurité TIC | ⬜ | ⬜ |
| Intégrations tierces | Restriction des plugins maintenus par la communauté | Gestion des risques | ⬜ | ⬜ |
| Intégrations tierces | Surveillance de l’usage des intégrations | Surveillance | ⬜ | ⬜ |
| Journalisation et surveillance | Activité du pipeline CI/CD intégralement journalisée | Surveillance | ⬜ | ⬜ |
| Journalisation et surveillance | Les journaux incluent les approbations et les contrôles de sécurité | Gouvernance | ⬜ | ⬜ |
| Journalisation et surveillance | Collecte centralisée des journaux | Gestion du risque TIC | ⬜ | ⬜ |
| Journalisation et surveillance | Conservation des journaux conforme à la politique | Tenue des registres | ⬜ | ⬜ |
| Journalisation et surveillance | Les preuves soutiennent l’audit et les investigations | Conformité | ⬜ | ⬜ |
| Changements et gouvernance | Changements revus et approuvés via le pipeline | Gestion des changements | ⬜ | ⬜ |
| Changements et gouvernance | Séparation entre les rôles de build et de déploiement | Gouvernance | ⬜ | ⬜ |
| Changements et gouvernance | Application des politiques via des portes automatisées | Sécurité TIC | ⬜ | ⬜ |
| Changements et gouvernance | Exceptions formellement approuvées et journalisées | Conformité | ⬜ | ⬜ |
| Changements et gouvernance | Gouvernance CI/CD revue périodiquement | Supervision | ⬜ | ⬜ |
Directive NIS2
La directive NIS2 impose aux entités essentielles et importantes de gérer le risque de cybersécurité dans l’ensemble de leurs activités, y compris les systèmes de livraison logicielle qui construisent et expédient les changements en production. L’article 21(2) énumère les mesures de base de gestion des risques et l’article 23 régit la notification des incidents — les deux se rattachent nettement aux contrôles CI/CD d’accès, de chaîne d’approvisionnement et de journalisation. Les auditeurs attendent que le CI/CD figure explicitement parmi les mesures de gestion des risques de l’organisation, avec une responsabilité de la direction. Attentes en matière de preuves : la politique de gestion des risques faisant référence au pipeline, les mesures de sécurité de la chaîne d’approvisionnement et les procédures documentées de traitement des incidents.
| Domaine | Contrôle | NIS2 (article) | Oui | Non |
|---|---|---|---|---|
| IAM | Moindre privilège appliqué aux comptes de service CI/CD | Art. 21(2)(b) | ⬜ | ⬜ |
| IAM | Séparation des identités humaines et des identités de pipeline | Art. 21(2)(d) | ⬜ | ⬜ |
| IAM | RBAC appliqué aux systèmes CI/CD | Art. 21(2)(b) | ⬜ | ⬜ |
| IAM | MFA appliquée aux administrateurs CI/CD | Art. 21(2)(a) | ⬜ | ⬜ |
| IAM | Les actions privilégiées requièrent une approbation | Art. 21(2)(d) | ⬜ | ⬜ |
| Secrets | Secrets non stockés dans le code source | Art. 21(2)(a) | ⬜ | ⬜ |
| Secrets | Injection des secrets à l’exécution | Art. 21(2)(a) | ⬜ | ⬜ |
| Secrets | Identifiants limités à leur environnement | Art. 21(2)(b) | ⬜ | ⬜ |
| Secrets | Rotation régulière des secrets | Art. 21(2)(c) | ⬜ | ⬜ |
| Secrets | Secrets exclus des journaux | Art. 21(2)(a) | ⬜ | ⬜ |
| Intégrité des artefacts | Environnements de build CI/CD durcis | Art. 21(2)(e) | ⬜ | ⬜ |
| Intégrité des artefacts | Signature des artefacts appliquée | Art. 21(2)(e) | ⬜ | ⬜ |
| Intégrité des artefacts | Provenance et traçabilité des artefacts | Art. 21(2)(e) | ⬜ | ⬜ |
| Intégrité des artefacts | Les dépôts d’artefacts sont immuables | Art. 21(2)(a) | ⬜ | ⬜ |
| Intégrité des artefacts | Seuls les artefacts de confiance sont promus | Art. 21(2)(d) | ⬜ | ⬜ |
| Intégrations tierces | Outils CI/CD tiers formellement approuvés | Art. 21(2)(e) | ⬜ | ⬜ |
| Intégrations tierces | Actions tierces épinglées à des versions | Art. 21(2)(e) | ⬜ | ⬜ |
| Intégrations tierces | Intégrité des composants CI/CD externes vérifiée | Art. 21(2)(e) | ⬜ | ⬜ |
| Intégrations tierces | Plugins communautaires restreints | Art. 21(2)(b) | ⬜ | ⬜ |
| Intégrations tierces | Activité des intégrations surveillée | Art. 21(2)(c) | ⬜ | ⬜ |
| Journalisation et surveillance | Activité du pipeline CI/CD intégralement journalisée | Art. 21(2)(c) | ⬜ | ⬜ |
| Journalisation et surveillance | Les journaux incluent les approbations et les événements de sécurité | Art. 21(2)(c) | ⬜ | ⬜ |
| Journalisation et surveillance | Journalisation centralisée activée | Art. 21(2)(c) | ⬜ | ⬜ |
| Journalisation et surveillance | Conservation des journaux conforme à la politique | Art. 21(2)(c) | ⬜ | ⬜ |
| Journalisation et surveillance | Les journaux CI/CD soutiennent l’investigation des incidents | Art. 23 | ⬜ | ⬜ |
| Changements et gouvernance | CI/CD inclus dans la gestion du risque de cybersécurité | Art. 21 | ⬜ | ⬜ |
| Changements et gouvernance | Séparation des tâches appliquée | Art. 21(2)(d) | ⬜ | ⬜ |
| Changements et gouvernance | Approbations de changement appliquées via les pipelines | Art. 21(2)(d) | ⬜ | ⬜ |
| Changements et gouvernance | Exceptions formellement approuvées et documentées | Art. 21(2)(b) | ⬜ | ⬜ |
| Changements et gouvernance | Posture de sécurité CI/CD revue périodiquement | Art. 21(2)(f) | ⬜ | ⬜ |
PCI DSS
PCI DSS s’applique partout où le CI/CD construit ou déploie des systèmes relevant du périmètre de l’environnement des données de titulaires de cartes (CDE). L’exigence 6 (logiciel sécurisé et contrôle des changements), les exigences 7 et 8 (accès) et l’exigence 10 (journalisation) portent la plupart des obligations pertinentes pour le pipeline. Un évaluateur de sécurité qualifié (QSA) teste les contrôles directement pour chaque système du périmètre et n’acceptera pas une simple déclaration de politique. Attentes en matière de preuves : les enregistrements de contrôle des changements, les configurations d’accès et les journaux centralisés conservés pendant la période requise.
| Domaine | Contrôle | PCI DSS (exigence) | Oui | Non |
|---|---|---|---|---|
| IAM | Moindre privilège appliqué aux comptes de service CI/CD | Req. 7.2 | ⬜ | ⬜ |
| IAM | Séparation des identités humaines et des identités de pipeline | Req. 7.1 | ⬜ | ⬜ |
| IAM | RBAC appliqué aux systèmes CI/CD | Req. 7.2 | ⬜ | ⬜ |
| IAM | MFA appliquée aux administrateurs CI/CD | Req. 8.4 | ⬜ | ⬜ |
| IAM | Les actions privilégiées requièrent une approbation | Req. 6.4 | ⬜ | ⬜ |
| Secrets | Secrets non stockés dans le code source | Req. 3.4 | ⬜ | ⬜ |
| Secrets | Injection des secrets à l’exécution | Req. 3.6 | ⬜ | ⬜ |
| Secrets | Identifiants limités à leur environnement | Req. 7.2 | ⬜ | ⬜ |
| Secrets | Rotation régulière des secrets | Req. 3.6.4 | ⬜ | ⬜ |
| Secrets | Secrets exclus des journaux | Req. 10.5 | ⬜ | ⬜ |
| Intégrité des artefacts | Environnements de build CI/CD durcis | Req. 6.2 | ⬜ | ⬜ |
| Intégrité des artefacts | Signature des artefacts appliquée | Req. 6.3 | ⬜ | ⬜ |
| Intégrité des artefacts | Provenance et traçabilité des artefacts | Req. 6.4 | ⬜ | ⬜ |
| Intégrité des artefacts | Les dépôts d’artefacts sont immuables | Req. 6.4 | ⬜ | ⬜ |
| Intégrité des artefacts | Seuls les artefacts de confiance sont promus | Req. 6.4 | ⬜ | ⬜ |
| Intégrations tierces | Outils CI/CD tiers formellement approuvés | Req. 12.8 | ⬜ | ⬜ |
| Intégrations tierces | Actions tierces épinglées à des versions | Req. 6.3 | ⬜ | ⬜ |
| Intégrations tierces | Intégrité des composants CI/CD externes vérifiée | Req. 6.2 | ⬜ | ⬜ |
| Intégrations tierces | Plugins communautaires restreints | Req. 6.2 | ⬜ | ⬜ |
| Intégrations tierces | Activité des intégrations surveillée | Req. 10.4 | ⬜ | ⬜ |
| Journalisation et surveillance | Activité du pipeline CI/CD intégralement journalisée | Req. 10.2 | ⬜ | ⬜ |
| Journalisation et surveillance | Les journaux incluent les approbations et les événements de sécurité | Req. 10.3 | ⬜ | ⬜ |
| Journalisation et surveillance | Journalisation centralisée activée | Req. 10.5 | ⬜ | ⬜ |
| Journalisation et surveillance | Conservation des journaux conforme à la politique | Req. 10.7 | ⬜ | ⬜ |
| Journalisation et surveillance | Les journaux CI/CD soutiennent l’investigation des incidents | Req. 12.10 | ⬜ | ⬜ |
| Changements et gouvernance | CI/CD inclus dans la gestion du risque de cybersécurité | Req. 12.2 | ⬜ | ⬜ |
| Changements et gouvernance | Séparation des tâches appliquée | Req. 7.1 | ⬜ | ⬜ |
| Changements et gouvernance | Approbations de changement appliquées via les pipelines | Req. 6.4 | ⬜ | ⬜ |
| Changements et gouvernance | Exceptions formellement approuvées et documentées | Req. 12.3 | ⬜ | ⬜ |
| Changements et gouvernance | Posture de sécurité CI/CD revue périodiquement | Req. 12.11 | ⬜ | ⬜ |
Utiliser cette cartographie lors d’un audit
La cartographie est la plus efficace lorsqu’elle est traitée comme un document de travail vivant tout au long d’un cycle d’audit plutôt que comme une référence statique. Le flux de travail pratique consiste à prouver une fois chaque contrôle de pipeline, puis à réutiliser cette preuve pour chaque référentiel qu’il satisfait.
- Partez du contrôle, pas du référentiel : prouvez une fois le contrôle de pipeline, puis lisez en transversale chaque référence de référentiel applicable.
- Utilisez les colonnes Oui/Non comme une évaluation d’écart en direct, et notez l’emplacement de la preuve (export de journal, configuration, ticket) en regard de chaque contrôle.
- Pour les audits internes ISO 27001 et les évaluations de préparation SOC 2, joignez la cartographie complétée au dossier d’audit.
- Pour les preuves de risque TIC DORA et les mesures de gestion des risques NIS2, utilisez-la pour démontrer que le pipeline est couvert par le référentiel plus large.
- Pour les évaluations des exigences 6 et 10 de PCI DSS, reliez chaque contrôle aux systèmes précis du périmètre dans l’environnement des données de titulaires de cartes.
- Rejouez la cartographie chaque fois que les pipelines, l’outillage ou le périmètre changent, et revoyez-la périodiquement à mesure que les pratiques de livraison évoluent.
Erreurs de cartographie fréquentes
La plupart des constats formulés contre une cartographie de ce type proviennent d’une poignée d’erreurs récurrentes. Les surveiller avant le début des travaux sur le terrain fait la différence entre une évaluation fluide et une liste d’exceptions.
- Cartographier un contrôle sur une clause sans détenir la preuve qu’il fonctionne réellement — une référence n’est pas une preuve.
- S’appuyer sur des captures d’écran ponctuelles là où le référentiel (SOC 2, DORA) attend des preuves couvrant une période.
- Considérer un Oui comme permanent ; les contrôles dérivent à mesure que les pipelines sont reconfigurés et que les permissions changent.
- Confondre politique et application — une règle documentée qu’un administrateur de pipeline peut contourner en silence ne satisfera pas un évaluateur.
- Laisser la référence de preuve vide, de sorte qu’un contrôle ne puisse pas être retracé jusqu’à sa preuve pendant les travaux sur le terrain.
- Recopier des références de référentiel sans confirmer le périmètre — par exemple appliquer PCI DSS à des systèmes hors du CDE, ou citer des contrôles de l’annexe A marqués hors périmètre dans la déclaration d’applicabilité.
Conclusion
Utilisée de manière cohérente, cette cartographie transforme un ensemble épars de paramètres de pipeline en un récit de contrôles défendable et transversal aux référentiels. Les mêmes contrôles CI/CD bien menés — moindre privilège, secrets gérés, artefacts signés, changements gouvernés et journaux complets — satisfont le cœur des cinq référentiels ; les différences tiennent surtout à la façon dont chacun attend que la preuve soit présentée et sur quelle période. Maintenir la cartographie comme un document vivant est ce qui garde une organisation prête pour l’audit entre les évaluations plutôt que dans la précipitation pendant celles-ci.
