NIS2 Article 23 impose des obligations strictes de notification d’incidents aux entit\u00e9s essentielles et importantes. Les organisations doivent signaler les incidents significatifs \u00e0 leur CSIRT national ou autorit\u00e9 comp\u00e9tente dans des d\u00e9lais stricts :<\/p>\n
Pour les organisations qui livrent ou maintiennent des logiciels via des pipelines CI\/CD, les journaux de pipeline et les enregistrements de d\u00e9ploiement deviennent des preuves critiques<\/strong> lors de l’investigation des incidents et du signalement r\u00e9glementaire. Les auditeurs et responsables conformit\u00e9 doivent s’assurer que les environnements de pipeline sont configur\u00e9s pour produire et conserver les preuves n\u00e9cessaires pour r\u00e9pondre \u00e0 ces obligations.<\/p>\n Lorsqu’un incident de s\u00e9curit\u00e9 survient \u2014 qu’il s’agisse d’un d\u00e9ploiement compromis, d’une violation de la cha\u00eene d’approvisionnement ou d’un changement de code non autoris\u00e9 \u2014 les enqu\u00eateurs doivent reconstituer exactement ce qui s’est pass\u00e9, quand et par qui. Les pipelines CI\/CD sont particuli\u00e8rement bien positionn\u00e9s pour fournir ces preuves car ils se situent \u00e0 l’intersection des changements de code, des processus de build, des scans de s\u00e9curit\u00e9 et des d\u00e9ploiements en production.<\/p>\n Les preuves de pipeline permettent aux organisations de :<\/p>\n Enregistrements complets de chaque d\u00e9ploiement indiquant quand il a eu lieu, vers quel environnement et le r\u00e9sultat (succ\u00e8s, \u00e9chec, rollback). Ces enregistrements doivent inclure des horodatages synchronis\u00e9s avec une source de temps fiable.<\/p>\n Enregistrements liant chaque d\u00e9ploiement \u00e0 des changements de code sp\u00e9cifiques, incluant les identifiants de commit, les descriptions de changements et l’auteur de chaque changement. Les journaux de changements doivent d\u00e9montrer une cha\u00eene ininterrompue du commit au d\u00e9ploiement en production.<\/p>\n Preuves que les approbations humaines requises ont \u00e9t\u00e9 obtenues avant le d\u00e9ploiement. Cela inclut les approbations de revue de code, les validations du comit\u00e9 consultatif des changements (CAB) le cas \u00e9ch\u00e9ant, et toute autorisation de changement d’urgence avec justification a posteriori.<\/p>\n Enregistrements des barri\u00e8res de s\u00e9curit\u00e9 automatis\u00e9es incluant l’analyse statique, le scan de vuln\u00e9rabilit\u00e9s des d\u00e9pendances, le scan d’images de conteneurs et tout autre contr\u00f4le de s\u00e9curit\u00e9 int\u00e9gr\u00e9 au pipeline. Les r\u00e9sultats doivent montrer ce qui a \u00e9t\u00e9 scann\u00e9, les d\u00e9couvertes et si le pipeline a continu\u00e9 ou a \u00e9t\u00e9 arr\u00eat\u00e9.<\/p>\n Enregistrements \u00e9tablissant l’origine et l’int\u00e9grit\u00e9 des artefacts d\u00e9ploy\u00e9s. Cela inclut les journaux de build montrant comment les artefacts ont \u00e9t\u00e9 construits, les sommes de contr\u00f4le ou signatures v\u00e9rifiant l’int\u00e9grit\u00e9 des artefacts et les enregistrements indiquant quel code source et quelles d\u00e9pendances ont \u00e9t\u00e9 utilis\u00e9s.<\/p>\n NIS2 ne sp\u00e9cifie pas une p\u00e9riode de r\u00e9tention obligatoire unique pour toutes les preuves. Cependant, les consid\u00e9rations suivantes s’appliquent :<\/p>\nComment les journaux de pipeline CI\/CD servent de preuves d’incidents<\/h2>\n
\n
Cat\u00e9gories de preuves pipeline requises<\/h2>\n
Chronologies de d\u00e9ploiement<\/h3>\n
Journaux de changements<\/h3>\n
Enregistrements d’approbation<\/h3>\n
R\u00e9sultats des scans de s\u00e9curit\u00e9<\/h3>\n
Provenance des artefacts<\/h3>\n
Exigences de r\u00e9tention des preuves<\/h2>\n
\n
Mapping type d’incident vers preuves pipeline<\/h2>\n