NIS 2 (Directive (UE) 2022/2555) énumère dix mesures de gestion des risques cybernétiques à l'Art. 21(2), et la plupart des comptes-rendus de conformité les abordent comme des questions de politique et de processus : une politique de sécurité de l'information, une procédure de gestion des incidents, un plan de continuité d'activité. Cela est exact pour la plupart des mesures. Cela reste incomplet pour celle qui est déterminée par ce qu'une équipe livre effectivement : l'Art. 21(2)(e), la sécurité dans l'acquisition, le développement et la maintenance des réseaux et systèmes d'information, y compris la gestion et la divulgation des vulnérabilités.
Ce guide s'adresse aux développeurs dont l'organisation est concernée par NIS 2, qu'il s'agisse d'une entité essentielle ou importante au sens de la directive, ou d'un fournisseur travaillant pour l'une d'entre elles, et qui souhaitent savoir quelle partie de cette mesure une revue de pull request peut effectivement détecter, distinctement des mesures de cybersécurité de base et de chaîne d'approvisionnement déjà couvertes par le hub du cadre.
À qui ce guide s'adresse, et la règle de taille
NIS 2 s'applique aux entités de taille moyenne et grande selon la règle de taille (généralement, 50 employés ou plus, ou un chiffre d'affaires annuel et un total de bilan annuel tous deux supérieurs à 10 millions d'euros) opérant dans les secteurs listés dans les Annexes I et II de la directive : énergie, transport, banque, santé, et infrastructures numériques parmi d'autres dans l'Annexe I ; services postaux, produits chimiques, alimentation, et fabrication parmi d'autres dans l'Annexe II. Le secteur seul ne détermine pas si une entité est essentielle ou importante : dans l'Annexe I, une grande entité répondant à la règle de taille est généralement classée « essentielle » et une entité moyenne généralement « importante » ; une entité de l'Annexe II répondant à la règle de taille est généralement classée « importante », qu'elle soit moyenne ou grande, la taille ne la divise pas davantage comme c'est le cas dans l'Annexe I ; et un ensemble plus restreint d'entités (certains fournisseurs d'infrastructures numériques, administrations publiques, et quelques autres catégories spéciales) sont incluses dans le champ d'application, et parfois classées essentielles, indépendamment de leur taille, par nom plutôt que par la règle de taille. Que votre organisation, ou le client pour lequel vous développez un logiciel, soit essentielle, importante ou hors champ est une question de classification juridique pour votre équipe de conformité ou juridique, et non quelque chose qu'une revue de code peut décider. Si cette discussion n'a pas encore eu lieu, tenez-la avant de considérer ce guide comme un programme de conformité.
Ce guide suppose que la question de classification est déjà résolue et que l'organisation est concernée. Il ne remplace pas le cadre de gestion des risques que la directive exige, ni les obligations de gestion des incidents (Art. 21(2)(b)) et de signalement des incidents (Art. 23), ni la responsabilité de l'organe de direction (Art. 20). Il traite de la seule mesure de l'Art. 21(2) qui peut être altérée dans une diff.
La mesure qui apparaît effectivement dans une diff : l'Art. 21(2)(e)
Deux des dix mesures de l'Art. 21(2) ont déjà leurs propres pages de contrôle dans le code sur ce site : la sécurité de la chaîne d'approvisionnement (Art. 21(2)(d), une dépendance non épinglée ou non vérifiée) et l'hygiène cybernétique de base (Art. 21(2)(g), une vulnérabilité connue non corrigée). Le point (e), la sécurité dans l'acquisition, le développement et la maintenance des réseaux et systèmes d'information, est une autre facette : il couvre la manière dont le logiciel est construit et la manière dont les vulnérabilités sont détectées et divulguées, et non les dépendances que vous intégrez ou les correctifs que vous appliquez par la suite.
En pratique, cela correspond à deux habitudes d'ingénierie. Premièrement, les tests de sécurité qu'un processus de développement exécute avant qu'un changement ne soit livré : une porte d'analyse statique, une étape de revue de sécurité obligatoire, une vérification de dépendance ou de fuzzing qui doit réussir. Deuxièmement, un canal de divulgation des vulnérabilités fonctionnel pour le logiciel une fois en production : un contact sécurité, un point de réception publié pour un rapport externe, un moyen pour quiconque trouve une faille de vous en informer. L'un ou l'autre peut être compromis dans une seule pull request : une porte est désactivée pour débloquer une livraison, ou une nouvelle surface accessible depuis l'extérieur est livrée sans canal de divulgation associé.
Exemple concret : la porte désactivée pour respecter un délai
Une équipe est sous pression pour livrer un nouveau point de terminaison d'API accessible au public, la première surface client de l'entreprise accessible depuis Internet. La pull request qui ajoute ce point de terminaison inclut également une modification sans rapport en une ligne : la porte de sécurité d'analyse statique obligatoire du dépôt, qui doit normalement réussir avant la fusion, est marquée comme non bloquante avec un commentaire faisant référence à un ticket de suivi. Le point de terminaison lui-même est bien conçu, avec une validation des entrées et des vérifications d'authentification qui passent une lecture humaine. Le ticket de suivi mentionné dans le commentaire n'existe pas, et rien dans la PR ne rétablit la porte en mode bloquant une fois la livraison effectuée. Par ailleurs, l'entreprise n'a pas de contact sécurité, de fichier security.txt, ni de point de réception publié pour les rapports de vulnérabilités : seuls des outils internes étaient exposés auparavant, donc personne n'en avait besoin.
Examinée uniquement en tant que fonctionnalité, cette PR est acceptable : le point de terminaison fonctionne, les tests passent, le délai est respecté. Examinée par rapport à l'Art. 21(2)(e), elle représente deux problèmes à la fois. Elle affaiblit les tests de sécurité que le processus de développement est censé exécuter avant que le code ne soit livré, sans exception ciblée ni plan de rétablissement, ce qui correspond exactement à la moitié de la mesure relative à l'acquisition et au développement. Et c'est le moment où l'absence de canal de divulgation des vulnérabilités de l'entreprise cesse d'être une lacune théorique pour devenir une lacune réelle : il existe désormais une surface accessible depuis l'extérieur et aucun moyen pour quiconque trouve une faille de l'en informer, ce qui correspond à la moitié relative à la divulgation. Aucun de ces problèmes ne concerne la justesse du code du point de terminaison. Les deux concernent le fait que le processus et l'organisation respectent toujours la mesure qui supposait que la porte restait activée et qu'un canal de divulgation existait quelque part.
Un constat qui cite l'Art. 21(2)(e) ne décide pas si la porte aurait dû être désactivée pour une raison valable, ne rédige pas la politique de divulgation, ni n'exécute pas le test de sécurité lui-même. Il rend le changement visible tant que la PR est encore ouverte, afin que l'auteur ou un relecteur puisse soit rétablir la porte avec une exception suivie, soit signaler que l'organisation a besoin d'un canal de divulgation avant que ce point de terminaison ne devienne la porte d'entrée pour un rapport sans destination.
Que rechercher lors d'une revue sans devenir juriste NIS 2
Lorsque une pull request modifie la configuration CI, demandez si elle désactive, affaiblit ou contourne une étape de test de sécurité obligatoire, et si oui, si la même PR (ou une PR liée) documente pourquoi et quand elle sera rétablie. Une porte désactivée sans plan de rétablissement est un indicateur de l'Art. 21(2)(e). Lorsque une pull request ajoute un nouveau point de terminaison, service ou intégration accessible depuis l'extérieur, demandez si un canal de divulgation des vulnérabilités pour celui-ci existe déjà au niveau de l'organisation ; s'il existe, la nouvelle surface l'hérite et rien de plus n'est nécessaire ; s'il n'existe pas, il s'agit d'une lacune à signaler, même si c'est une correction organisationnelle ponctuelle plutôt qu'une correction par PR.
Il s'agit d'une demande plus restreinte que la mesure complète. Elle ne couvre pas si votre documentation de cycle de développement est complète ou si votre processus de gestion des vulnérabilités répond à tous les éléments décrits par la directive ; ce sont des questions de processus pour la personne responsable de votre programme NIS 2. Elle couvre les deux endroits où une pull request peut discrètement annuler le travail déjà accompli par ce programme.
Où heygrc intervient, et la limite de l'honnêteté
heygrc est conçu pour analyser chaque pull request par rapport aux cadres que vous avez sélectionnés, y compris NIS 2 lorsqu'il est activé, et pour identifier le point qu'un changement semble toucher, par exemple l'Art. 21(2)(e) pour une porte de sécurité désactivée ou un nouveau point de terminaison sans canal de divulgation visible, l'Art. 21(2)(d) pour une dépendance non épinglée, l'Art. 21(2)(g) pour un correctif retenu. Le constat est un commentaire de revue avec la clause jointe, afin que l'auteur et le relecteur décident en toute connaissance de cause. Il ne certifie pas la conformité NIS 2, ne rédige pas votre politique de divulgation des vulnérabilités, n'exécute pas vos tests de sécurité, ne classe pas votre entité, ni ne dépose les rapports d'incidents que l'Art. 23 exige. Ces tâches restent des responsabilités humaines et organisationnelles.
Si votre équipe exécute déjà un outil SAST ou de qualité de code sur la même pull request, conservez-le. Cet outil vérifie si le code lui-même est correct et sûr. L'Art. 21(2)(e) vérifie si le processus autour du code, la porte qui devait s'exécuter et le canal utilisé pour signaler une faille, tient toujours. Le point de terminaison ci-dessus peut passer tous les contrôles de qualité et laisser la mesure plus faible qu'elle ne l'était. Exécutez les deux couches ; aucune ne remplace l'autre.