Introduction : pourquoi A.14 est le contrôle fondamental pour CI/CD
L’Annexe A.14 — Acquisition, développement et maintenance des systèmes — est le domaine de contrôle le plus pertinent pour les organisations exploitant des pipelines CI/CD. Il régit directement la manière dont les systèmes sont développés, modifiés, testés et acceptés en production. Pour les auditeurs et les responsables conformité, c’est dans A.14 que vous trouverez la plus grande densité d’exigences de contrôle spécifiques à CI/CD et, souvent, la plus grande densité de non-conformités.
Cette analyse approfondie examine chaque sous-contrôle A.14 dans le contexte des pipelines CI/CD, fournissant des orientations claires sur ce à quoi ressemble la conformité, quelles preuves sont requises et ce qui constitue un signal d’alerte lors d’un audit.
A.14.1 — Exigences de sécurité des systèmes d’information
A.14.1.1 — Analyse et spécification des exigences de sécurité de l’information
Ce que cela signifie pour CI/CD : Avant tout développement ou acquisition de système, les exigences de sécurité doivent être définies. Dans un contexte CI/CD, cela signifie que les exigences de sécurité sont spécifiées avant le début du développement et sont traçables à travers le pipeline — de la définition des exigences à la vérification du déploiement.
Preuves démontrant la conformité :
- Exigences de sécurité documentées dans les user stories, critères d’acceptation ou spécifications dédiées d’exigences de sécurité
- Traçabilité des exigences de sécurité vers les cas de test appliqués par le pipeline
- Registres montrant que les exigences de sécurité ont été revues et approuvées avant le début du développement
À quoi ressemble la non-conformité : Les exigences de sécurité sont absentes, informelles ou ajoutées rétroactivement après le développement. Aucun lien entre les exigences énoncées et la vérification automatisée dans le pipeline.
A.14.1.2 — Sécurisation des services applicatifs sur les réseaux publics
Ce que cela signifie pour CI/CD : Les applications déployées via des pipelines CI/CD vers des environnements accessibles au public doivent disposer de contrôles d’intégrité des données, de confidentialité et de non-répudiation. Le pipeline lui-même doit vérifier que les configurations TLS, les contrôles de sécurité des API et les mécanismes d’authentification sont correctement configurés avant le déploiement.
Preuves démontrant la conformité :
- Étapes de pipeline vérifiant la configuration TLS et la validité des certificats
- Vérifications automatisées des en-têtes de sécurité et de la sécurité du transport
- Registres de vérification de la configuration de sécurité avant le déploiement public
À quoi ressemble la non-conformité : Applications déployées sur des réseaux publics sans vérification automatisée de la configuration de sécurité. Pas de vérifications pré-déploiement pour la sécurité du transport.
A.14.1.3 — Protection des transactions des services applicatifs
Ce que cela signifie pour CI/CD : Lorsque les applications gèrent des transactions, le pipeline doit inclure la vérification que les contrôles d’intégrité transactionnelle (transmission complète, validation du routage, intégrité des messages, confidentialité) sont en place et testés.
Preuves démontrant la conformité :
- Suites de tests d’intégration couvrant les scénarios d’intégrité transactionnelle exécutées dans le pipeline
- Registres des résultats de tests de sécurité transactionnelle conservés avec l’historique d’exécution du pipeline
À quoi ressemble la non-conformité : Applications gérant des transactions déployées sans tests d’intégration des contrôles de sécurité transactionnelle.
A.14.2 — Sécurité dans les processus de développement et de support
A.14.2.1 — Politique de développement sécurisé
Ce que cela signifie pour CI/CD : L’organisation doit disposer d’une politique documentée régissant les pratiques de développement sécurisé. Dans les environnements CI/CD, cette politique doit couvrir les processus automatisés de build et de déploiement, les contrôles de sécurité des pipelines et l’intégration des tests de sécurité dans le pipeline de livraison.
Preuves démontrant la conformité :
- Politique de développement sécurisé approuvée couvrant explicitement les processus CI/CD
- Registres de revue de politique montrant des mises à jour régulières
- Preuves de communication de la politique à tous les utilisateurs et administrateurs de pipeline
- Registres de formation du personnel impliqué dans la gestion des pipelines
À quoi ressemble la non-conformité : La politique de développement sécurisé existe mais ne fait aucune référence aux pipelines CI/CD ou aux processus automatisés. La politique n’a pas été revue depuis l’adoption de CI/CD.
A.14.2.2 — Procédures de contrôle des changements système
Ce que cela signifie pour CI/CD : C’est un contrôle pivot pour CI/CD. Tous les changements de systèmes doivent suivre des procédures formelles de contrôle des changements. En CI/CD, le pipeline est le mécanisme de contrôle des changements — mais il doit appliquer des procédures documentées incluant les exigences d’approbation, l’évaluation d’impact, la vérification des tests et la capacité de rollback.
Preuves démontrant la conformité :
- Procédures de contrôle des changements référençant le pipeline CI/CD comme mécanisme d’application
- Configurations de pipeline montrant les portes d’approbation obligatoires avant le déploiement en production
- Pistes d’audit de tous les changements incluant qui a initié, qui a approuvé, ce qui a été testé et le résultat du déploiement
- Preuves que les procédures de changements d’urgence sont définies et suivies (avec approbation rétrospective)
À quoi ressemble la non-conformité : Les développeurs peuvent pousser des changements directement en production en contournant le pipeline. Pas de portes d’approbation dans le pipeline. Les changements d’urgence n’ont pas de processus de revue rétrospective.
A.14.2.3 — Revue technique des applications après des changements de plateforme d’exploitation
Ce que cela signifie pour CI/CD : Lorsque la plateforme sous-jacente change (mises à jour du système d’exploitation, mises à niveau du middleware, changements d’infrastructure), les applications doivent être revues et testées. Les pipelines CI/CD doivent déclencher des tests de régression lorsque les dépendances de plateforme changent.
Preuves démontrant la conformité :
- Procédure documentée d’évaluation d’impact des changements de plateforme
- Registres des exécutions de tests de régression déclenchés par des changements de plateforme
- Preuves que les images de base et les dépendances de plateforme du pipeline sont versionnées avec suivi des changements
À quoi ressemble la non-conformité : Les changements de plateforme sont effectués sans déclencher de tests de régression applicatifs. Pas de suivi des versions des dépendances de plateforme dans le pipeline.
A.14.2.4 — Restrictions sur les modifications des progiciels
Ce que cela signifie pour CI/CD : Les modifications des progiciels fournis par des tiers doivent être contrôlées et limitées. En CI/CD, cela couvre les modifications de composants open-source, les dépendances forkées et les intégrations tierces personnalisées.
Preuves démontrant la conformité :
- Politique définissant quand la modification de paquets tiers est permise
- Registres d’approbation pour toute modification de paquets tiers
- Contrôles de pipeline détectant et signalant les paquets modifiés (vérification d’intégrité, validation de checksum)
- Évaluations d’impact sur la notification et le support du fournisseur pour les paquets modifiés
À quoi ressemble la non-conformité : Les paquets tiers sont régulièrement forkés ou modifiés sans approbation formelle. Pas de vérification d’intégrité dans le pipeline pour les modifications de paquets.
A.14.2.5 — Principes d’ingénierie de systèmes sécurisés
Ce que cela signifie pour CI/CD : L’organisation doit établir, documenter et appliquer des principes d’ingénierie sécurisée à tout développement de système. Le pipeline CI/CD doit appliquer ces principes par des vérifications automatisées — revues d’architecture, validation des patterns de sécurité et vérification de conformité.
Preuves démontrant la conformité :
- Principes d’ingénierie sécurisée documentés applicables aux systèmes livrés par CI/CD
- Vérifications appliquées par le pipeline validant l’adhérence aux principes d’ingénierie
- Registres de revue d’architecture pour les nouveaux systèmes entrant dans le pipeline
- Preuves que les principes d’ingénierie sécurisée sont revus et mis à jour périodiquement
À quoi ressemble la non-conformité : Les principes d’ingénierie sécurisée existent sur le papier mais ne sont pas appliqués par le pipeline. Pas de vérification automatisée des patterns d’architecture de sécurité.
A.14.2.6 — Environnement de développement sécurisé
Ce que cela signifie pour CI/CD : Les environnements de développement — y compris les environnements de build CI/CD — doivent être sécurisés et protégés. Les agents de build, les dépôts d’artefacts et les plateformes d’orchestration de pipeline sont des environnements de développement nécessitant des contrôles de sécurité appropriés.
Preuves démontrant la conformité :
- Contrôles de sécurité appliqués aux environnements de build CI/CD (segmentation réseau, contrôle d’accès, durcissement)
- Preuves d’isolation des environnements de build (agents de build éphémères, isolation par conteneur)
- Registres de contrôle d’accès pour l’infrastructure de développement et de build
- Standards de durcissement appliqués à l’infrastructure de la plateforme CI/CD
À quoi ressemble la non-conformité : Les environnements de build partagent l’infrastructure avec la production sans isolation. Les agents de build sont persistants avec un état accumulé et sans reconstruction périodique. Pas de standards de durcissement pour l’infrastructure CI/CD.
A.14.2.7 — Développement externalisé
Ce que cela signifie pour CI/CD : Lorsque le développement est externalisé, l’organisation doit superviser et surveiller l’activité. En CI/CD, cela signifie que les développeurs externalisés doivent utiliser le pipeline de l’organisation (pas le leur), et leurs contributions sont soumises aux mêmes contrôles automatisés et processus d’approbation.
Preuves démontrant la conformité :
- Exigences contractuelles pour les développeurs externalisés d’utiliser le pipeline CI/CD de l’organisation
- Registres de contrôle d’accès montrant que les développeurs externalisés ont un accès approprié (limité) au pipeline
- Preuves d’exigences de revue de code pour les contributions externalisées
- Registres de surveillance de l’activité pipeline des développeurs externalisés
À quoi ressemble la non-conformité : Les développeurs externalisés utilisent leurs propres processus de build et de déploiement. Les contributions externalisées contournent les contrôles standard du pipeline ou les exigences de revue de code.
A.14.2.8 — Tests de sécurité du système
Ce que cela signifie pour CI/CD : Les tests de sécurité doivent être effectués pendant le développement. Les pipelines CI/CD doivent intégrer des tests de sécurité automatisés — analyse statique, analyse des vulnérabilités des dépendances, tests dynamiques — comme des étapes de pipeline obligatoires qui ne peuvent pas être contournées.
Preuves démontrant la conformité :
- Configurations de pipeline montrant les étapes de tests de sécurité obligatoires
- Résultats de tests de sécurité conservés avec chaque exécution de pipeline
- Preuves que les échecs de tests de sécurité bloquent la progression vers la production
- Registres de mises à jour et de maintenance des règles des outils de tests de sécurité
À quoi ressemble la non-conformité : Les tests de sécurité existent mais sont optionnels ou uniquement consultatifs. Les résultats des tests ne sont pas conservés. Les échecs de tests de sécurité peuvent être contournés sans justification documentée.
A.14.2.9 — Tests d’acceptation du système
Ce que cela signifie pour CI/CD : Des programmes et critères de tests d’acceptation doivent être établis. Le pipeline CI/CD doit appliquer les critères d’acceptation avant le déploiement en production — incluant les portes d’acceptation fonctionnelles, de performance et de sécurité.
Preuves démontrant la conformité :
- Critères d’acceptation définis pour chaque étape de déploiement
- Configurations de pipeline appliquant les portes d’acceptation
- Registres des résultats de tests d’acceptation pour chaque déploiement en production
- Preuves que les critères d’acceptation sont revus et approuvés par les parties prenantes appropriées
À quoi ressemble la non-conformité : Pas de critères d’acceptation formels définis. Le pipeline permet le déploiement sans vérification d’acceptation. Les tests d’acceptation sont manuels et appliqués de manière incohérente.
Tableau de mapping des sous-contrôles A.14
| Sous-contrôle A.14 | Implémentation CI/CD | Preuves requises | Signaux d’alerte |
|---|---|---|---|
| A.14.1.1 Exigences de sécurité | Exigences de sécurité tracées vers les cas de test du pipeline | Spécifications d’exigences ; registres de traçabilité ; mappings de cas de test | Pas d’exigences de sécurité définies avant le début du développement |
| A.14.1.2 Services sur réseau public | Vérifications de configuration de sécurité pré-déploiement | Résultats de vérification automatisée TLS et en-têtes de sécurité | Déploiements publics sans vérification de configuration de sécurité |
| A.14.1.3 Protection des transactions | Tests d’intégrité transactionnelle dans le pipeline | Résultats de tests d’intégration couvrant les scénarios transactionnels | Systèmes transactionnels déployés sans tests d’intégrité |
| A.14.2.1 Politique de développement sécurisé | Politique régissant les pratiques de sécurité CI/CD | Politique approuvée ; registres de revue ; preuves de communication | Politique ne mentionnant pas CI/CD ; pas de revue depuis l’adoption du pipeline |
| A.14.2.2 Contrôle des changements | Pipeline comme mécanisme d’application du contrôle des changements | Configurations des portes d’approbation ; pistes d’audit des changements ; registres de changements d’urgence | Pushs directs en production possibles ; pas de portes d’approbation |
| A.14.2.3 Revue des changements de plateforme | Tests de régression déclenchés par les changements de dépendances de plateforme | Registres de changements de plateforme ; résultats de tests de régression | Mises à jour de plateforme sans tests de régression applicatifs |
| A.14.2.4 Restrictions de modification des paquets | Vérification d’intégrité pour les paquets tiers | Approbations de modifications de paquets ; résultats de vérification d’intégrité | Paquets forkés sans approbation ; pas de vérifications d’intégrité |
| A.14.2.5 Principes d’ingénierie sécurisée | Vérifications d’architecture et de patterns de sécurité appliquées par le pipeline | Principes documentés ; résultats de vérification automatisée | Principes existant sur papier seulement ; pas d’application par le pipeline |
| A.14.2.6 Environnement de développement sécurisé | Environnements de build durcis et isolés | Registres de durcissement ; preuves d’isolation ; journaux d’accès | Infrastructure partagée ; agents de build persistants ; pas de durcissement |
| A.14.2.7 Développement externalisé | Les développeurs externalisés utilisent le pipeline de l’organisation | Contrats ; registres d’accès ; journaux de surveillance ; registres de revue de code | Développeurs externes contournant le pipeline ; pas de surveillance |
| A.14.2.8 Tests de sécurité | Étapes de tests de sécurité automatisés obligatoires | Configurations de pipeline ; résultats de tests ; registres de maintenance des outils | Tests de sécurité optionnels ; résultats non conservés ; contournements faciles |
| A.14.2.9 Tests d’acceptation | Portes d’acceptation appliquées par le pipeline | Critères d’acceptation ; configurations des portes ; résultats de tests par déploiement | Pas de critères d’acceptation ; tests manuels uniquement ; application incohérente |
Comment A.14 se connecte aux autres contrôles de l’Annexe A
A.14 ne fonctionne pas de manière isolée. Une gouvernance CI/CD efficace nécessite de comprendre comment A.14 intersecte avec d’autres domaines de contrôle :
- A.9 (Contrôle d’accès) — Le contrôle des changements A.14.2.2 dépend des contrôles d’accès A.9 pour s’assurer que seul le personnel autorisé peut approuver et déclencher les déploiements. Les défaillances du contrôle d’accès compromettent l’ensemble du cadre de contrôle des changements.
- A.12 (Sécurité des opérations) — Les exigences d’environnement de développement sécurisé A.14.2.6 s’alignent avec les procédures opérationnelles A.12. Les exigences de journalisation sous A.12 fournissent la piste d’audit nécessaire pour vérifier la conformité du contrôle des changements A.14.
- A.15 (Relations avec les fournisseurs) — Les restrictions de paquets A.14.2.4 et le développement externalisé A.14.2.7 se connectent directement à la gestion des fournisseurs A.15. Les composants tiers dans le pipeline sont à la fois une préoccupation de développement (A.14) et une préoccupation de risque fournisseur (A.15).
Checklist de vérification de l’auditeur pour A.14
Lors de l’audit de la conformité A.14 dans les environnements CI/CD, vérifiez les points suivants :
- ☐ La politique de développement sécurisé traite explicitement des pipelines CI/CD et des processus automatisés
- ☐ Les exigences de sécurité sont définies avant le développement et traçables vers la vérification du pipeline
- ☐ Les procédures de contrôle des changements référencent le pipeline CI/CD comme mécanisme d’application
- ☐ Le pipeline inclut des portes d’approbation obligatoires avant le déploiement en production
- ☐ Toutes les exécutions de pipeline produisent des pistes d’audit immuables (qui, quoi, quand, résultat)
- ☐ Les étapes de tests de sécurité sont obligatoires et ne peuvent être contournées sans justification documentée
- ☐ Les échecs de tests de sécurité bloquent la progression du déploiement
- ☐ Les critères d’acceptation sont définis, approuvés et appliqués par le pipeline
- ☐ Les environnements de build sont isolés, durcis et soumis au contrôle d’accès
- ☐ Le développement externalisé est soumis aux mêmes contrôles de pipeline que le développement interne
- ☐ Les modifications de paquets tiers sont formellement approuvées et vérifiées en intégrité
- ☐ Les changements de plateforme déclenchent des tests de régression
- ☐ Des procédures de changements d’urgence existent avec des exigences de revue rétrospective
- ☐ Les preuves sont conservées conformément à la politique de rétention de l’organisation
Lectures complémentaires
Ressources connexes pour les auditeurs
- Glossaire — Définitions en langage clair des termes techniques
- Conformité continue via CI/CD
- Checklist de préparation à l’audit
- Contrôles de sécurité CI/CD fondamentaux
Nouveau dans l’audit CI/CD ? Commencez par notre Guide de l’auditeur.
