ISO 27001 et sécurité CI/CD

ISO 27001 : le cadre fondamental pour la sécurité de l’information dans la livraison logicielle

ISO/IEC 27001 est le système de management de la sécurité de l’information (SMSI) le plus largement adopté dans le monde. Pour les organisations opérant dans des secteurs réglementés, la certification ISO 27001 sert fréquemment de base sur laquelle des obligations de conformité supplémentaires — telles que DORA, NIS2, SOC 2 ou PCI DSS — sont superposées. Lorsque les pipelines CI/CD constituent l’épine dorsale de la livraison logicielle, ils entrent pleinement dans le périmètre du SMSI et doivent être gouvernés avec la même rigueur que toute autre installation de traitement de l’information.

Cette page hub fournit un guide complet pour aligner les contrôles de sécurité CI/CD avec les exigences ISO 27001:2022, préparer les audits de certification et constituer une base de preuves qui satisfait les évaluateurs externes.

Aperçu ISO 27001:2022

ISO/IEC 27001:2022 spécifie les exigences pour établir, mettre en œuvre, maintenir et améliorer continuellement un SMSI. La norme suit une approche basée sur les risques : les organisations identifient les risques de sécurité de l’information, sélectionnent les contrôles appropriés pour traiter ces risques et démontrent une efficacité continue par la surveillance et la mesure.

La norme se compose de deux éléments principaux :

  • Clauses 4 à 10 (exigences du système de management) : Elles définissent la structure de gouvernance — contexte de l’organisation, engagement de la direction, planification, support, exploitation, évaluation des performances et amélioration. Elles sont obligatoires pour la certification.
  • Annexe A (contrôles de référence) : Un catalogue de 93 contrôles organisés en quatre thèmes — Organisationnel, Personnel, Physique et Technologique. Les organisations sélectionnent les contrôles applicables via une Déclaration d’Applicabilité (DdA) basée sur leur évaluation des risques.

La certification est accordée par des organismes de certification accrédités à l’issue d’un processus d’audit en deux étapes, avec des audits de surveillance continus et un cycle de recertification complet tous les trois ans.

Pourquoi le CI/CD est dans le périmètre du SMSI

Les systèmes CI/CD ne sont pas des outils périphériques — ce sont des installations de traitement de l’information qui manipulent directement certains des actifs informationnels les plus sensibles de l’organisation. Les pipelines traitent le code source, gèrent les identifiants et secrets, produisent et stockent les artefacts de build, orchestrent les déploiements vers les environnements de production et génèrent des données opérationnelles qui constituent des preuves du fonctionnement des contrôles.

Sous ISO 27001, tout système qui traite, stocke ou transmet des actifs informationnels dans le périmètre défini du SMSI doit être soumis à des contrôles appropriés. Les pipelines CI/CD répondent à chaque élément de cette définition. Les exclure du périmètre créerait une lacune inacceptable dans le SMSI, et les auditeurs expérimentés examineront spécifiquement si l’infrastructure de livraison a été traitée de manière appropriée.

De plus, les pipelines CI/CD représentent une surface d’attaque à fort impact. Un pipeline compromis peut injecter du code malveillant en production, exfiltrer des secrets ou contourner tous les autres contrôles de sécurité de l’organisation. Le processus d’évaluation des risques devrait reconnaître cela et garantir que des contrôles proportionnés sont appliqués.

Contrôles clés de l’Annexe A pour les environnements CI/CD

La révision 2022 de l’Annexe A a restructuré les contrôles en quatre thèmes. Les contrôles suivants sont particulièrement pertinents pour la sécurité CI/CD et doivent être traités explicitement dans la Déclaration d’Applicabilité.

A.5 — Contrôles organisationnels

  • A.5.1 Politiques de sécurité de l’information : L’organisation doit maintenir un ensemble de politiques de sécurité de l’information, approuvées par la direction, couvrant les opérations CI/CD — y compris l’utilisation acceptable, le contrôle d’accès, la gestion des changements et le développement sécurisé.
  • A.5.8 Sécurité de l’information dans la gestion de projet : Les exigences de sécurité doivent être intégrées aux projets de livraison logicielle dès le début, garantissant que la sécurité du pipeline est conçue dès l’origine et non ajoutée après coup.
  • A.5.19–A.5.23 Relations avec les fournisseurs : Les composants CI/CD tiers — y compris les plateformes SaaS de pipeline, les runners partagés, les dépendances open source, les images de base de conteneurs et les plugins externes — doivent être gouvernés par des politiques de sécurité fournisseur, des évaluations de risques et une surveillance continue. Cela inclut le maintien d’un SBOM et la réalisation d’analyses SCA.

A.6 — Contrôles relatifs au personnel

  • A.6.1 Vérification des antécédents : Le personnel ayant accès aux systèmes CI/CD et aux identifiants de déploiement en production devrait faire l’objet d’une vérification appropriée des antécédents.
  • A.6.3 Sensibilisation, éducation et formation à la sécurité de l’information : Les développeurs, ingénieurs DevOps et équipes de plateforme doivent recevoir une formation de sécurité spécifique à leur rôle couvrant les pratiques de codage sécurisé, la sécurité des pipelines et les exigences du SMSI de l’organisation.

A.7 — Contrôles physiques

  • A.7.1–A.7.4 Sécurité physique : Lorsque des runners auto-hébergés ou une infrastructure de build existent sur site, les contrôles d’accès physique doivent être documentés et appliqués. Pour le CI/CD hébergé dans le cloud, l’organisation doit vérifier que son fournisseur maintient des contrôles physiques adéquats (généralement via l’assurance fournisseur).

A.8 — Contrôles technologiques

C’est le domaine de contrôle le plus étendu pour les environnements CI/CD. Plusieurs contrôles introduits ou restructurés dans la révision 2022 sont directement applicables :

  • A.8.2 Droits d’accès privilégiés : Les comptes de service des pipelines, les identifiants de déploiement et l’accès administratif aux plateformes CI/CD doivent suivre le principe du moindre privilège, avec des revues d’accès régulières.
  • A.8.4 Accès au code source : Les dépôts de code source doivent être protégés par des contrôles d’accès appropriés, des règles de protection de branche et une journalisation d’audit.
  • A.8.9 Gestion de la configuration : Les configurations de pipeline, les définitions d’infrastructure-as-code et les paramètres d’environnement doivent être gérés via le contrôle de version avec suivi des changements et workflows d’approbation.
  • A.8.15 Journalisation : Toutes les activités CI/CD — builds, tests, déploiements, changements d’accès, modifications de configuration — doivent être journalisées avec suffisamment de détails et conservées selon la politique de conservation du SMSI.
  • A.8.16 Activités de surveillance : Les systèmes CI/CD doivent être surveillés pour détecter les comportements anormaux, les changements non autorisés et les événements de sécurité, avec des alertes dirigées vers le personnel approprié.
  • A.8.25 Cycle de développement sécurisé : L’organisation doit définir et appliquer un cycle de développement sécurisé qui intègre les activités de sécurité — modélisation des menaces, exigences de sécurité, revue de conception sécurisée, tests de sécurité — dans le workflow CI/CD.
  • A.8.28 Codage sécurisé : Des pratiques de codage sécurisé doivent être établies, incluant les exigences de revue de code, l’utilisation de bibliothèques approuvées et l’application automatisée via les portes de pipeline.
  • A.8.29 Tests de sécurité en développement et acceptation : SAST, DAST, SCA et autres tests de sécurité doivent être intégrés aux pipelines avec des critères de réussite/échec définis et des preuves de remédiation.
  • A.8.31 Séparation des environnements de développement, test et production : Les environnements doivent être correctement séparés avec des contrôles d’accès distincts, des identifiants séparés et des processus de promotion contrôlés entre les étapes.
  • A.8.32 Gestion des changements : Tous les changements aux configurations de pipeline, processus de déploiement et systèmes de production doivent suivre un processus documenté de gestion des changements avec des approbations appropriées et une capacité de retour en arrière.

Le processus d’audit de certification

La certification ISO 27001 implique un audit initial structuré en deux étapes, suivi d’une surveillance continue et d’une recertification :

Étape 1 — Revue documentaire

L’organisme de certification examine la documentation du SMSI pour sa complétude et sa conformité. Pour les environnements CI/CD, les auditeurs vérifieront si les systèmes de pipeline sont inclus dans la déclaration de périmètre, si l’évaluation des risques couvre les menaces de livraison logicielle et si la Déclaration d’Applicabilité traite les contrôles pertinents de l’Annexe A. Ils examineront également les politiques couvrant le développement sécurisé, la gestion des changements, le contrôle d’accès et la gestion des fournisseurs en lien avec le pipeline de livraison.

Étape 2 — Preuves et efficacité

L’auditeur vérifie que les contrôles documentés sont mis en œuvre et fonctionnent efficacement. Pour le CI/CD, cela signifie démontrer que les configurations de pipeline appliquent les politiques déclarées, que les logs fournissent des preuves du fonctionnement des contrôles, que les revues d’accès ont été effectuées et que les résultats des tests de sécurité montrent une gestion active des vulnérabilités. Les auditeurs peuvent demander des démonstrations en direct, des échantillons de logs d’exécution de pipeline, des enregistrements de revue d’accès et des preuves de réponse aux incidents.

Audits de surveillance

Réalisés annuellement entre les cycles de certification, les audits de surveillance échantillonnent des contrôles spécifiques pour vérifier la conformité continue. Les auditeurs peuvent se concentrer sur les domaines où des non-conformités ont été précédemment identifiées, ou sur les contrôles particulièrement pertinents pour le profil de risque de l’organisation — y compris les contrôles CI/CD si l’environnement de livraison logicielle constitue une part importante du périmètre du SMSI.

Recertification

Tous les trois ans, un audit complet de recertification est réalisé. Il s’agit essentiellement d’une répétition du processus des étapes 1 et 2 et offre l’occasion de démontrer que le SMSI a mûri, que les enseignements des audits précédents ont été intégrés et que les contrôles restent efficaces à mesure que l’environnement CI/CD évolue.

Ce que les auditeurs recherchent dans les environnements CI/CD

Les auditeurs ISO 27001 expérimentés évaluant les environnements CI/CD se concentrent sur quatre domaines clés :

  1. Politiques documentées : Des politiques et procédures écrites qui traitent spécifiquement de la sécurité CI/CD — pas des politiques IT génériques qui omettent de mentionner l’infrastructure de livraison logicielle.
  2. Contrôles appliqués : Des preuves techniques que les politiques sont appliquées — des règles de protection de branche qui empêchent les fusions non approuvées, des portes de pipeline qui bloquent les déploiements sans tests de sécurité, des contrôles d’accès qui restreignent le déploiement en production au personnel autorisé.
  3. Preuves d’efficacité : Des logs et rapports générés par le système démontrant que les contrôles fonctionnent de manière cohérente — pas seulement qu’ils ont été configurés une fois. Les auditeurs recherchent les historiques d’exécution de pipeline, les enregistrements de revue d’accès, les délais de remédiation des vulnérabilités et la documentation de réponse aux incidents.
  4. Amélioration continue : Des preuves que l’organisation examine l’efficacité des contrôles, tire des leçons des incidents et quasi-incidents, met à jour l’évaluation des risques à mesure que l’environnement CI/CD change et met en œuvre des améliorations à travers le cycle Planifier-Faire-Vérifier-Agir.

Non-conformités courantes dans les évaluations CI/CD

Les non-conformités suivantes sont fréquemment identifiées lors des audits ISO 27001 des organisations avec des pipelines CI/CD :

  • Absence de preuves de gestion des changements : Les changements de pipeline sont effectués sans workflows d’approbation documentés, ou les preuves d’approbation n’existent que dans des fils de discussion email plutôt que dans des enregistrements imposés par le système.
  • Revues d’accès insuffisantes : L’accès aux plateformes CI/CD, aux identifiants de déploiement et aux systèmes de gestion des secrets n’est pas revu périodiquement, entraînant une accumulation de privilèges et des comptes orphelins.
  • Absence d’intégration des tests de sécurité : Malgré des politiques exigeant des tests de sécurité, les outils SAST/DAST/SCA ne sont pas intégrés aux pipelines, ou leurs résultats ne sont pas traités avec des délais de remédiation définis.
  • Gestion insuffisante des fournisseurs : Les composants CI/CD tiers — plugins, images de conteneurs, plateformes SaaS — sont adoptés sans évaluation des risques fournisseur ni surveillance continue.
  • Chevauchement d’environnements : Les environnements de développement, test et production partagent des identifiants, comptes de service ou infrastructure sans séparation appropriée.
  • Journalisation incomplète : Les activités de pipeline sont journalisées de manière incohérente, la conservation des logs ne respecte pas la politique du SMSI, ou les logs manquent de détails suffisants pour l’analyse forensique.
  • Traitement des risques manquant : Les risques spécifiques au CI/CD (attaques de la chaîne d’approvisionnement, compromission de pipeline, fuite de secrets) ne sont pas identifiés dans le registre des risques ou n’ont pas de plans de traitement définis.

Articles approfondis

Explorez des conseils détaillés sur des aspects spécifiques de la conformité ISO 27001 dans les environnements CI/CD :

Contenu associé

Références inter-référentiels

Les contrôles ISO 27001 chevauchent fréquemment les exigences d’autres référentiels réglementaires. Les organisations poursuivant plusieurs certifications peuvent tirer parti d’un ensemble de contrôles unifié :