NIS2 Article 21(2)(e) : développement sécurisé et gestion des vulnérabilités pour les MSP

Une bibliothèque de journalisation que votre client n'a jamais sciemment choisie, jamais installée volontairement et qu'il ne saurait nommer de mémoire publie une CVE critique un vendredi après-midi. Elle se cache trois couches sous un agent de supervision que vous avez déployé pour lui il y a dix-huit mois. L'horloge qui compte n'est pas celle de l'avis de l'éditeur — c'est celle qu'un auditeur déclenche lorsqu'il demande à quelle vitesse vous l'avez su, à quelle vitesse vous avez agi, et où est la preuve.

C'est précisément ce scénario que l'Article 21(2)(e) de NIS2 vise à empêcher. C'est la mesure que la plupart des consultants négligent parce qu'elle ressemble à un problème de développeurs. Elle ne l'est pas. C'est un problème de chaîne d'approvisionnement et de maintenance, et pour les MSP, l'une des mesures les plus difficiles à prouver.

L'Article 21(2)(e) couvre tout ce que vous construisez, achetez et maintenez

Les dix mesures de gestion des risques de l'Article 21(2) constituent l'ossature de la conformité NIS2. L'attention se porte surtout sur les plus visibles — MFA, sauvegardes, notification d'incident. La mesure (e) est plus discrète et plus large : « la 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. »

Lisez-la lentement. Trois verbes — acquisition, développement, maintenance — plus une obligation permanente de traiter et de divulguer les vulnérabilités. Elle s'applique que vous écriviez du code, que vous revendiez une plateforme ou que vous mainteniez simplement le logiciel d'un autre à jour. Aucune dérogation pour « nous ne développons rien ». Si vous maintenez les systèmes d'un client, la moitié maintenance de cette mesure vous appartient.

Article 21 — 10 Mesures de Cybersécurité NIS2
🛡️
Article 21
10 Mesures de Cybersécurité
📊
Gouvernance & Stratégie
1Analyse des risques & politiques de sécurité de l'information
6Évaluation de l'efficacité des mesures de sécurité
🚨
Incidents & Continuité
2Gestion des incidents & notification
3Continuité des activités & reprise après sinistre
🔗
Chaîne d'approvisionnement & Systèmes
4Sécurité de la chaîne d'approvisionnement
5Sécurité dans le développement des systèmes d'information
🔐
Contrôles Techniques
8Cryptographie & chiffrement
10Authentification multifacteur & communications sécurisées
👥
Personnel & Actifs
7Cyber-hygiène & formation
9Sécurité RH & contrôle d'accès

Pour la cartographie complète des liens entre (e) et les neuf autres mesures, voyez notre présentation des dix mesures de l'Article 21.

Ce que « acquisition, développement et maintenance sécurisés » signifie en pratique

Décomposez la mesure en les trois choses qu'elle demande réellement.

L'acquisition signifie choisir logiciels et fournisseurs avec la sécurité comme critère de sélection, pas comme arrière-pensée. Cela suppose une évaluation documentée des fournisseurs : l'éditeur suit-il des pratiques de développement sécurisé, publie-t-il des avis, s'engage-t-il à divulguer les vulnérabilités de son produit ? Un « nous utilisons des fournisseurs réputés » en une ligne ne survit pas à un audit.

Le développement signifie que tout ce que vous construisez — un portail client, un script d'automatisation, une intégration sur mesure — passe par un cycle de vie sécurisé. Normes de codage sécurisé, revue de code, tests de sécurité avant déploiement et un processus pour les vulnérabilités trouvées après la mise en production. Vous n'avez pas besoin d'un document SDLC de 40 pages. Vous avez besoin d'un processus reproductible que vous pouvez montrer.

La maintenance, c'est là que vivent la plupart des MSP. Elle signifie appliquer les correctifs, gérer les changements et tenir un inventaire exact de ce qui est déployé et où. Vous ne pouvez pas corriger ce que vous ne voyez pas, et vous ne pouvez pas prouver que vous avez corrigé sans registres.

Construisez-vous, ou maintenez-vous seulement ? Les contrôles diffèrent

La mesure s'applique à tous ceux dans le périmètre, mais le poids se déplace selon ce que vous faites. Utilisez la logique de décision ci-dessous pour déterminer quels contrôles portent le plus de risque d'audit pour votre activité.

La NIS2 s'applique-t-elle à votre organisation ?
1
Votre organisation opère-t-elle dans un secteur essentiel ou important (énergie, transport, santé, infrastructure numérique, etc.) ?
Oui▼
Non▼
2
Votre organisation compte-t-elle 50 employés ou plus, ou réalise-t-elle un chiffre d'affaires annuel supérieur à 10 millions d'euros ?
✗
La NIS2 ne s'applique pas directement à votre organisation.
Oui▼
Non▼
✓
La NIS2 s'applique à votre organisation en tant qu'entité essentielle ou importante.
3
Votre organisation est-elle un opérateur d'infrastructure critique ou un prestataire de services de confiance qualifié ?
Oui▼
!
La NIS2 pourrait s'appliquer à votre organisation — consultez un juriste pour confirmer votre statut.
1
Votre organisation opère-t-elle dans un secteur essentiel ou important (énergie, transport, santé, infrastructure numérique, etc.) ?
Oui ↓Non →
2
Votre organisation compte-t-elle 50 employés ou plus, ou réalise-t-elle un chiffre d'affaires annuel supérieur à 10 millions d'euros ?
Oui ↓Non →
3
Votre organisation est-elle un opérateur d'infrastructure critique ou un prestataire de services de confiance qualifié ?
Oui ↓Non →
✗
La NIS2 ne s'applique pas directement à votre organisation.
✓
La NIS2 s'applique à votre organisation en tant qu'entité essentielle ou importante.
!
La NIS2 pourrait s'appliquer à votre organisation — consultez un juriste pour confirmer votre statut.
S'applique
Possiblement applicable
Ne s'applique pas

Si vous ne faites que maintenir des logiciels tiers, votre exposition tient à l'exactitude de l'inventaire, aux SLA de correctifs et aux registres de changements. Si vous développez quoi que ce soit orienté client, ajoutez le codage sécurisé, la revue de code et les tests avant publication à la liste. Si vous revendez ou regroupez les plateformes d'autres éditeurs, vos contrôles d'acquisition — vérification des fournisseurs et clauses de divulgation — deviennent la première chose qu'un auditeur sonde. Cartographiez honnêtement vos services avant de bâtir l'ensemble de contrôles.

Gestion des vulnérabilités : réception, tri et SLA de correctifs

La gestion des vulnérabilités est une boucle, pas un projet. Elle a trois parties mobiles.

La réception, c'est la façon dont les vulnérabilités vous parviennent — avis des éditeurs, votre propre scan, tests d'intrusion tiers et un canal permettant à des tiers de signaler une faille dans quelque chose que vous exploitez. S'il manque cette dernière boîte, il vous manque un contrôle que la directive nomme explicitement.

Le tri, c'est la façon dont vous classez ce qui arrive. Gravité plus exposition plus exploitabilité, noté de la même manière à chaque fois pour que deux ingénieurs arrivent au même résultat.

La remédiation, c'est le correctif, lié à une horloge de niveau de service. NIS2 ne prescrit pas de délais de correction, aussi le marché a-t-il adopté une norme de fait que les acheteurs inscrivent désormais dans les contrats : critique sous 24–48 heures, élevé sous 7 jours, moyen sous 30 jours, faible sous 90 — avec un processus d'exception documenté pour les cas où vous ne pouvez vraiment pas corriger à temps. Ce processus d'exception compte autant que le SLA. Un auditeur ne cherche pas un dossier parfait. Il cherche un dossier défendable.

Le piège pour les MSP : vous devez produire ces registres par client, au moment de l'audit, sur demande. Un scan qui ne vit que dans un tableau de bord n'est pas une preuve. Une trace datée et exportable, si.

Divulgation coordonnée des vulnérabilités et la EUVD

Traiter vos propres vulnérabilités, c'est la moitié de la mesure. L'autre moitié, c'est la divulgation — et NIS2 a bâti un canal formel pour cela.

En vertu de l'Article 12, chaque État membre désigne un CSIRT comme coordinateur d'un programme national de divulgation coordonnée des vulnérabilités (CVD). Ce CSIRT agit comme intermédiaire de confiance entre celui qui signale une faille et l'éditeur dont le produit la porte. Il contacte les parties concernées, soutient le déclarant et négocie les délais de divulgation — y compris dans les cas épineux où une vulnérabilité touche des produits dans plusieurs pays à la fois.

Tout cela est alimenté par la European Vulnerability Database (EUVD), maintenue par l'ENISA, qui exploite un registre de vulnérabilités en tant qu'autorité de numérotation CVE (CNA) officielle depuis janvier 2024. Pour un MSP, la EUVD est une seconde source de vérité aux côtés des avis des éditeurs — et savoir s'en servir fait désormais partie du métier. Nous couvrons le volet pratique dans notre guide EUVD pour les MSP.

L'enseignement pratique : vous avez besoin d'un moyen publié permettant à quelqu'un de signaler une vulnérabilité dans un produit ou un service que vous exploitez, et d'une décision sur votre participation au processus CVD national. Les deux sont auditables. Aucun n'est facultatif si vous êtes dans le périmètre.

Quand la faille d'un fournisseur devient la responsabilité de votre client

C'est ici que la mesure (e) cesse d'être abstraite. Une vulnérabilité dans le produit d'un fournisseur ne reste pas confinée. Elle se propage en cascade — du fournisseur à vous, à votre client, aux clients de celui-ci — et les obligations de chaîne d'approvisionnement de NIS2 (mesure (d)) font que la responsabilité voyage avec elle.

Escalade des sanctions NIS2 — Au-delà de l'amende
!
Déclencheur
Non-conformité détectée ou incident survenu
Une autorité de contrôle identifie une lacune de conformité ou une organisation ne respecte pas les exigences NIS2
Les autorités peuvent imposer
▼
Sanctions non financières
1
Ordres de mise en conformité avec délais contraignants
2
Audits de sécurité obligatoires à vos frais
3
Divulgation publique des violations
4
Instructions contraignantes sur des mesures de sécurité spécifiques
Escalade vers
▼
Conséquences opérationnelles et personnelles
1
Suspension de certifications ou licences d'exploitation
2
Interdiction temporaire de fonctions de direction pour les individus
3
Désignation publique des personnes physiques responsables
Déclencheur
Non financier
Opérationnel / personnel

Si un composant que vous avez déployé porte une faille critique non corrigée et qu'un client est compromis à travers elle, « le fournisseur aurait dû nous prévenir » n'est pas une défense. La directive attend que vous ayez évalué ce fournisseur, contractualisé la divulgation et disposé d'un processus pour agir dès l'arrivée de l'avis. C'est pourquoi acquisition et gestion des vulnérabilités forment une seule mesure et non deux — la faiblesse entre par ce que vous avez acheté et se gère par ce que vous faites ensuite. Notre présentation de la sécurité de la chaîne d'approvisionnement détaille le volet contractuel.

La preuve qu'un auditeur demandera réellement

La mesure (e) se juge sur les traces écrites, pas sur les intentions. Ayez celles-ci prêtes, par client le cas échéant :

Un inventaire des logiciels et des fournisseurs à jour, pas un tableur de l'an dernier. Des évaluations de fournisseurs montrant que la sécurité était un critère de sélection. Une politique de correctifs avec des SLA fondés sur la gravité, plus les journaux prouvant que vous les avez respectés — et les registres d'exception là où vous ne l'avez pas fait. Une gestion des changements liant chaque changement à une approbation. Un canal de réception et de divulgation des vulnérabilités qui existe et est surveillé. Et, si vous développez, des notes SDLC sécurisées : normes de codage, preuves de revue, résultats de tests avant publication.

Rien de tout cela n'est exotique. Tout cela fait la différence entre réussir un audit et expliquer, après un incident, pourquoi les registres n'existent pas. La mesure (f) — évaluer si vos contrôles fonctionnent vraiment — se pose directement sur celle-ci ; voyez notre guide de la boucle d'audit pour saisir le lien entre les deux.

Commencez par ce que vous pouvez voir

La plupart des MSP réalisent déjà 60 % de cette mesure — ils corrigent, ils suivent les changements, ils choisissent des fournisseurs corrects. L'écart tient presque toujours à la preuve et au canal de divulgation, pas au travail sous-jacent. Le moyen le plus rapide de trouver vos lacunes précises est de regarder vos contrôles de maintenance et d'acquisition à travers le prisme de l'Article 21(2)(e) et de marquer ce que vous pourriez remettre à un auditeur aujourd'hui par rapport à ce que vous devriez rassembler à la hâte.

Si vous voulez que cet écart soit cartographié pour vous, lancez un NIS2 quick scan gratuit — il indique par mesure exactement où se situe votre posture de développement sécurisé et de gestion des vulnérabilités face à la directive.

La mesure (e) n'est pas la partie la plus voyante de NIS2. C'est celle qui a le plus de chances de se révéler mince quand un auditeur tire le fil, précisément parce qu'elle a l'air du travail d'un autre. Pour un MSP, c'est le vôtre.