NIS2 Article 23 : Vue d’ensemble des exigences de signalement d’incidents
NIS2 Article 23 impose des obligations strictes de notification d’incidents aux entités essentielles et importantes. Les organisations doivent signaler les incidents significatifs à leur CSIRT national ou autorité compétente dans des délais stricts :
- Alerte précoce : Dans les 24 heures suivant la prise de connaissance d’un incident significatif
- Notification d’incident : Dans les 72 heures, fournissant une évaluation initiale incluant la sévérité et l’impact
- Rapport final : Dans un délai d’un mois, incluant une description détaillée, l’analyse de la cause racine et les mesures d’atténuation appliquées
Pour les organisations qui livrent ou maintiennent des logiciels via des pipelines CI/CD, les journaux de pipeline et les enregistrements de déploiement deviennent des preuves critiques lors de l’investigation des incidents et du signalement réglementaire. Les auditeurs et responsables conformité doivent s’assurer que les environnements de pipeline sont configurés pour produire et conserver les preuves nécessaires pour répondre à ces obligations.
Comment les journaux de pipeline CI/CD servent de preuves d’incidents
Lorsqu’un incident de sécurité survient — qu’il s’agisse d’un déploiement compromis, d’une violation de la chaîne d’approvisionnement ou d’un changement de code non autorisé — les enquêteurs doivent reconstituer exactement ce qui s’est passé, quand et par qui. Les pipelines CI/CD sont particulièrement bien positionnés pour fournir ces preuves car ils se situent à l’intersection des changements de code, des processus de build, des scans de sécurité et des déploiements en production.
Les preuves de pipeline permettent aux organisations de :
- Établir des chronologies : Déterminer précisément quand un changement malveillant ou défectueux est entré dans le processus de livraison
- Identifier le périmètre : Comprendre quels artefacts, environnements et services ont été affectés
- Démontrer la diligence raisonnable : Montrer aux régulateurs que les contrôles appropriés (revues de code, scans de sécurité, barrières d’approbation) étaient en place et fonctionnels
- Supporter l’analyse de cause racine : Retracer l’incident jusqu’à son origine — qu’il s’agisse d’une dépendance compromise, d’un pipeline mal configuré ou d’une erreur humaine
Catégories de preuves pipeline requises
Chronologies de déploiement
Enregistrements complets de chaque déploiement indiquant quand il a eu lieu, vers quel environnement et le résultat (succès, échec, rollback). Ces enregistrements doivent inclure des horodatages synchronisés avec une source de temps fiable.
Journaux de changements
Enregistrements liant chaque déploiement à des changements de code spécifiques, incluant les identifiants de commit, les descriptions de changements et l’auteur de chaque changement. Les journaux de changements doivent démontrer une chaîne ininterrompue du commit au déploiement en production.
Enregistrements d’approbation
Preuves que les approbations humaines requises ont été obtenues avant le déploiement. Cela inclut les approbations de revue de code, les validations du comité consultatif des changements (CAB) le cas échéant, et toute autorisation de changement d’urgence avec justification a posteriori.
Résultats des scans de sécurité
Enregistrements des barrières de sécurité automatisées incluant l’analyse statique, le scan de vulnérabilités des dépendances, le scan d’images de conteneurs et tout autre contrôle de sécurité intégré au pipeline. Les résultats doivent montrer ce qui a été scanné, les découvertes et si le pipeline a continué ou a été arrêté.
Provenance des artefacts
Enregistrements établissant l’origine et l’intégrité des artefacts déployés. Cela inclut les journaux de build montrant comment les artefacts ont été construits, les sommes de contrôle ou signatures vérifiant l’intégrité des artefacts et les enregistrements indiquant quel code source et quelles dépendances ont été utilisés.
Exigences de rétention des preuves
NIS2 ne spécifie pas une période de rétention obligatoire unique pour toutes les preuves. Cependant, les considérations suivantes s’appliquent :
- Le rapport final d’incident est dû dans un mois, donc toutes les preuves doivent être disponibles au moins pendant cette période
- Les autorités compétentes peuvent demander des informations supplémentaires lors d’enquêtes de suivi, ce qui peut s’étendre bien au-delà de la période de signalement initiale
- Les transpositions des États membres peuvent imposer des exigences de rétention spécifiques — les organisations doivent vérifier leur législation nationale de transposition
- Comme base prudente, les organisations devraient conserver les preuves de pipeline pendant un minimum de 24 mois pour couvrir les délais d’enquête, les suivis réglementaires et les éventuelles procédures judiciaires
Mapping type d’incident vers preuves pipeline
| Type d’incident | Preuves pipeline requises | Période de rétention recommandée |
|---|---|---|
| Déploiement compromis (code malveillant atteint la production) | Chronologie complète de déploiement ; journaux de commits et changements pour la release affectée ; enregistrements d’approbation ; résultats de scans de sécurité (surtout les barrières contournées) ; provenance et vérification d’intégrité des artefacts | Minimum 24 mois |
| Compromission de la chaîne d’approvisionnement (dépendance ou image de base malveillante) | SBOM pour les builds affectés ; journaux de mise à jour des dépendances ; provenance des artefacts ; journaux d’accès aux registres ; enregistrements d’évaluation des fournisseurs | Minimum 24 mois ; conserver les SBOM pour la durée de vie du logiciel affecté |
| Accès non autorisé à l’infrastructure pipeline | Journaux d’authentification et d’accès au pipeline ; historique de configuration RBAC ; enregistrements de vérification MFA ; journaux d’actions administratives | Minimum 24 mois |
| Exposition de données via les journaux ou artefacts pipeline | Journaux d’exécution de pipeline (pour identifier quelles données ont été exposées) ; journaux d’audit de gestion des secrets ; journaux d’accès au stockage des artefacts | Minimum 24 mois ; peut être étendu selon les exigences de l’autorité de protection des données |
| Altération de pipeline (modification non autorisée de la configuration pipeline) | Historique des changements de configuration du pipeline ; journaux d’accès à l’administration du pipeline ; journaux de commits pour les fichiers pipeline-as-code ; enregistrements d’approbation des changements de pipeline | Minimum 24 mois |
| Échec de déploiement causant une interruption de service | Journaux de déploiement incluant les détails d’erreur ; enregistrements de rollback ; journaux de changements ; résultats de tests pré-déploiement ; résultats de contrôle de santé post-déploiement | Minimum 18 mois |
Checklist auditeur : Préparation aux incidents dans les environnements CI/CD
Utilisez cette checklist pour évaluer si l’environnement CI/CD d’une organisation est préparé à supporter les obligations de signalement d’incidents NIS2 :
Génération de preuves
- ☐ Les journaux de pipeline capturent le cycle de vie complet : déclenchement, build, scan, approbation, déploiement et résultat
- ☐ Chaque déploiement est lié à un ensemble spécifique de changements de code et d’approbations
- ☐ Les résultats de scans de sécurité sont enregistrés et conservés indépendamment des interfaces d’outils de pipeline
- ☐ Les enregistrements de provenance des artefacts (entrées de build, sommes de contrôle, signatures) sont générés pour chaque release
- ☐ Les horodatages de tous les composants de pipeline sont synchronisés avec une source de temps commune et fiable
Intégrité des preuves
- ☐ Les journaux de pipeline sont stockés dans un stockage en ajout seul ou immuable
- ☐ L’intégrité des journaux peut être vérifiée (par ex. via des sommes de contrôle ou un chaînage cryptographique)
- ☐ L’accès au stockage des journaux est restreint et audité séparément
- ☐ Les administrateurs de pipeline ne peuvent pas supprimer ou modifier les journaux historiques
Rétention des preuves
- ☐ Une politique de rétention documentée existe couvrant les preuves de pipeline CI/CD
- ☐ Les périodes de rétention respectent ou dépassent les minimums recommandés (24 mois comme base)
- ☐ La rétention est appliquée automatiquement — pas dépendante d’une intervention manuelle
- ☐ Les preuves restent accessibles et lisibles tout au long de la période de rétention (pérennité du format)
Intégration de la réponse aux incidents
- ☐ Le plan de réponse aux incidents référence explicitement les preuves de pipeline CI/CD et comment y accéder
- ☐ Les rôles et responsabilités pour la collecte de preuves pipeline pendant les incidents sont définis
- ☐ L’organisation a testé sa capacité à récupérer et analyser les preuves pipeline en conditions d’incident
- ☐ Des chemins d’escalade existent pour les incidents provenant ou affectant le pipeline CI/CD
Préparation au signalement
- ☐ L’organisation peut produire une chronologie de déploiement pour tout service donné dans la fenêtre d’alerte précoce de 24 heures
- ☐ Les procédures d’analyse de cause racine incluent la revue des journaux de pipeline comme étape standard
- ☐ Les modèles de rapports pour les autorités compétentes incluent des sections pour les preuves liées aux pipelines
Ressources connexes
Pour la bibliothèque complète de ressources de conformité NIS2, visitez notre Hub de conformité NIS2.
Pour une vue d’ensemble des principes d’architecture de sécurité NIS2 et leur application à la livraison logicielle, consultez Architecture de sécurité NIS2 expliquée.
Connexe pour les auditeurs
- Glossaire — Définitions en langage clair des termes techniques
- Architecture de sécurité NIS2
- Conformité continue via CI/CD
- Comment les auditeurs examinent le CI/CD
Nouveau dans l’audit CI/CD ? Commencez par notre Guide de l’auditeur.
