Développement et acquisition sécurisés NIS 2 au titre de l'article 21, paragraphe 2, point e)
NIS 2 dispose que vous devez sécuriser les systèmes lors de l'acquisition, du développement et de la maintenance. L'article 21, paragraphe 2, point e), est le cadre général. Le §6 du CIR (UE) 2024/2690 le divise en dix sous-sections. L'Allemagne l'inscrit en droit national par le §30(2)(5) BSIG.
La version courte
L'article 21, paragraphe 2, point e), est l'obligation cadre pour la sécurité tout au long du cycle de vie informatique. Pas seulement le code. Pas seulement les correctifs. Tout le parcours : acheter un système, le construire, le configurer, le modifier, le tester, le corriger, l'exploiter, le mettre hors service. La même règle s'applique dans toute l'UE.
Le CIR (UE) 2024/2690 complète le détail. Le §6 de l'annexe comporte dix sous-sections (§6.1 à §6.10) qui opérationnalisent l'obligation. Cette page couvre le volet développement et changement : acquisition (§6.1), le cycle de développement sécurisé (§6.2), la gestion de la configuration (§6.3), la gestion des changements (§6.4), les tests de sécurité (§6.5) et la gestion des correctifs (§6.6). La sécurité réseau, la segmentation, l'antimaliciel et la gestion des vulnérabilités (§6.7 à §6.10) font l'objet de pages distinctes.
L'Allemagne inscrit la même règle en droit national par le §30(2)(5) BSIG. Le libellé reprend presque mot pour mot le texte de l'UE. Cette page parcourt la directive, le règlement de mise en œuvre de l'UE et la transposition allemande dans cet ordre.
Article 21, paragraphe 2, point e), de la directive NIS 2 (2022/2555)
Sécurité de l'acquisition, du développement et de la maintenance des réseaux et des systèmes d'information, y compris le traitement et la divulgation des vulnérabilités.
Il s'agit du point e) de la liste des dix mesures de cybersécurité que chaque entité essentielle et importante doit mettre en place. C'est le seul point de la liste qui s'étend explicitement du bon de commande à la fin de vie.
CIR (UE) 2024/2690, annexe §6
Mesures de sécurité relatives à l'acquisition, au développement et à la maintenance des réseaux et des systèmes d'information (article 21, paragraphe 2, point e), de la directive (UE) 2022/2555).
Parce qu'il s'agit d'un règlement (et non d'une directive), il constitue un droit de l'UE directement contraignant. Aucune transposition nationale n'est nécessaire. Il s'applique aux fournisseurs DNS, aux registres TLD, aux fournisseurs de cloud, aux centres de données, aux fournisseurs de services gérés et aux autres secteurs énumérés à son annexe. Le §6 comporte dix sous-sections numérotées qui nomment chacune une obligation spécifique.
§30(2)(5) BSIG (Allemagne)
Sécurité de l'acquisition, du développement et de la maintenance des systèmes informatiques, y compris le traitement et la divulgation des vulnérabilités.
L'Allemagne reprend le texte de l'UE presque mot pour mot. « Systèmes informatiques » au lieu de « réseaux et systèmes d'information » est une question de formulation, pas de sens. Le BSI pointe vers les modules IT-Grundschutz CON.8 (développement logiciel) et OPS.1.1.3 (gestion des correctifs et des changements) comme voie pratique.
Inscrivez des exigences de sécurité dans chaque achat
Avant d'acheter un produit ou un service informatique, vous écrivez ce qu'il doit faire en matière de sécurité. Authentification, journalisation, prise en charge des mises à jour, divulgation des vulnérabilités, région d'hébergement, lieu où résident les données. Ensuite, vous validez que le fournisseur respecte effectivement les exigences. Cela incombe à l'entité acheteuse, pas au fournisseur. « Nous utilisons du SaaS » ne transfère pas l'obligation.
Exploitez un cycle de développement sécurisé
Les exigences de sécurité sont analysées lors de la spécification et de la conception. Des principes de codage sécurisé s'appliquent, y compris la sécurité dès la conception et les architectures zéro confiance. Les environnements de développement eux-mêmes sont sécurisés. Les tests de sécurité ont lieu avant la mise en production. Les données de test sont traitées avec soin, et non copiées depuis la production. L'ensemble du cycle de vie est documenté, pas seulement une ou deux pratiques.
Appliquez les correctifs dans un délai approprié, après les avoir testés
Les correctifs de sécurité sont appliqués dans un délai approprié (le texte du CIR), en fonction de la gravité de la vulnérabilité. Les correctifs sont testés avant la mise en production. Les correctifs d'urgence sont documentés. « Quand l'équipe a le temps » n'est pas un délai. Choisissez une cadence, écrivez-la, prouvez que vous vous y tenez.
La sécurité de l'acquisition à la mise hors service
Le §6 ne concerne pas le développement au sens étroit. Il couvre l'ensemble du cycle de vie : comment vous choisissez ce que vous achetez, comment vous construisez, comment vous configurez, comment vous testez, comment vous corrigez, comment vous modifiez, comment vous retirez. Un Mittelstand qui achète 95 pour cent de ses logiciels reste tout de même soumis au §6.1 (exigences d'acquisition) et au §6.6 (gestion des correctifs). Vous ne pouvez pas vous exonérer du cycle de vie sous prétexte que vous n'écrivez pas de code.
Discipline du changement : aucun changement de production non tracé
Le §6.4 est sans ambiguïté : les changements apportés à la production sont gérés, documentés et examinés. Les changements d'urgence sont également documentés, simplement après coup au lieu d'avant. Un changement sans ticket, sans approbateur et sans plan de retour arrière ne satisfait pas à l'exigence, même s'il fonctionne. Les auditeurs confrontent le journal des changements au système de tickets. S'ils ne peuvent pas reconstituer qui a changé quoi et quand, le contrôle n'est pas en place.
BSI / IT-Grundschutz CON.8 + OPS.1.1.3
Le BSI fait correspondre le §30(2)(5) BSIG à deux modules Grundschutz. CON.8 « Software-Entwicklung » couvre le volet SDLC : exigences, codage sécurisé, test, mise en production. OPS.1.1.3 « Patch- und Änderungsmanagement » couvre le volet changement et correctifs. Si vous suivez CON.8 et OPS.1.1.3, vous êtes dans le périmètre de ce qu'exige le §30 BSIG.
ENISA Technical Implementation Guidance
L'ENISA, l'agence de cybersécurité de l'UE, publie une Technical Implementation Guidance (TIG) qui prend le texte abstrait du §6 du CIR et vous montre quoi faire en pratique. Elle fait correspondre chaque sous-section aux contrôles ISO/IEC 27001:2022 (A.8.25 à A.8.32 sur le développement sécurisé, A.5.20 à A.5.23 sur les relations avec les fournisseurs), de sorte que les certifications existantes vous donnent une longueur d'avance.
Lois nationales de transposition
Chaque État membre a sa propre loi de transposition (Pays-Bas : Cyberbeveiligingswet, Autriche : NISG, Belgique : NIS2-Wet). Les obligations au titre de l'article 21, paragraphe 2, point e), sont les mêmes parce que la directive fixe une norme unique à l'échelle de l'UE. Ce qui diffère : le cadre national vers lequel le régulateur pointe comme voie pratique.
Nous utilisons du SaaS, donc le développement sécurisé est l'affaire du fournisseur.
À moitié vrai. Le fournisseur possède le code. Vous restez tout de même soumis au §6.1 : des exigences de sécurité documentées pour chaque produit ou service informatique que vous achetez, plus la validation que le fournisseur les respecte. Authentification, journalisation, prise en charge des mises à jour, localisation des données, notification des violations. Si votre dossier d'acquisition est vide, l'obligation n'est pas remplie, même si le fournisseur est excellent.
Nous faisons des revues de code, donc le volet SDLC est couvert.
La revue de code est une pratique parmi d'autres. Le §6.2 exige que l'ensemble du cycle de vie soit documenté : exigences de sécurité lors de la spécification, principes de codage sécurisé (y compris la sécurité dès la conception et le zéro confiance), environnements de développement sécurisés, procédures de tests de sécurité avant la mise en production, traitement soigneux des données de test. Une seule pratique posée sur un processus non documenté ne satisfait pas à la section.
Nous appliquons les correctifs quand l'équipe a le temps.
Le §6.6 exige un délai approprié lié à la gravité, plus des tests avant la mise en production et une documentation pour les correctifs d'urgence. « Quand il y a le temps » n'est pas un délai. Choisissez une cadence (par exemple, critique sous 72 heures, élevée sous 14 jours), écrivez-la, prouvez que vous vous y tenez dans le journal des changements. Un auditeur reconstituera votre historique de correctifs à partir du système de tickets.
La plupart des systèmes informatiques du Mittelstand allemand ressemblent à ceci : 90 pour cent de logiciels fournisseurs (ERP, paie, messagerie, partage de fichiers, CRM), un peu de colle d'intégration, des scripts internes occasionnels. Pour ce profil, le gros effort du §6 n'est pas le SDLC. C'est l'acquisition du §6.1 et la gestion des correctifs du §6.6.
Rédigez le modèle d'exigences de sécurité une fois. Authentification, journalisation, divulgation des vulnérabilités, prise en charge des mises à jour, région d'hébergement, exportation des données, notification des violations. Appliquez-le à chaque nouvelle acquisition et à chaque renouvellement. Associez-le à une cadence de correctifs écrite (critique / élevée / moyenne avec un délai chacune) et à un journal des changements que tout le monde utilise. Cela couvre l'essentiel du §6 pour un Mittelstand typique sans recruter de spécialiste de la sécurité logicielle.
Nous avons intégré les exigences d'acquisition du §6.1, la documentation SDLC du §6.2, le journal des changements du §6.4 et la cadence de correctifs du §6.6 dans le module PRO de la plateforme. Vous remplissez le modèle d'acquisition une fois et le réutilisez. Chaque nouveau produit ou service informatique passe par la même liste de vérification de sécurité avec une approbation.
Le journal des changements et la cadence de correctifs s'exécutent sur la même piste d'audit que le reste de la plateforme : ticket, approbateur, plan de retour arrière, fichier de preuve. Les changements d'urgence reçoivent le formulaire après coup. Vous ne tenez pas de journal de conformité distinct. Lorsqu'un auditeur demande comment vous avez corrigé une CVE, la réponse est une seule requête, pas trois feuilles de calcul.
- Directive (UE) 2022/2555 (NIS 2), article 21, paragraphe 2, point e) — eur-lex.europa.eu/eli/dir/2022/2555/oj
- Règlement d'exécution (UE) 2024/2690 de la Commission (CIR), annexe §6 — eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- Loi sur le BSI (BSIG), §30(2)(5) tel que modifié par la loi de mise en œuvre de NIS2 et de renforcement de la cybersécurité
- Modules IT-Grundschutz du BSI CON.8 « Software-Entwicklung » et OPS.1.1.3 « Patch- und Änderungsmanagement »
- ENISA Technical Implementation Guidance pour le CIR (UE) 2024/2690 (au mois de mai 2026)