Le développement de logiciels est-il couvert par la NIS2 ?
L'activité de développement de logiciels ne figure pas en tant que telle dans les annexes de la directive NIS2. Il n'existe pas de secteur appelé « développeurs de logiciels ». En revanche, on y trouve des catégories connexes : l'informatique en nuage et les services en nuage relèvent de l'infrastructure numérique, tandis que les services TIC gérés et les services de sécurité gérés relèvent des services TIC. Si vous développez des logiciels sur mesure pour des clients sans fournir vous-même un service en nuage ou un service géré, il est probable que vous ne releviez pas directement de la directive.
Cela ne signifie pas que le développement de logiciels reste en dehors du champ d'application. Trois éléments déterminent ensemble votre situation : la nature précise de ce que vous fournissez (secteur), la taille de votre organisation et la question de savoir si vos clients sont eux-mêmes soumis à la directive. Ce dernier point touche en pratique beaucoup plus de sociétés de développement que le premier.
Secteur : ce que les annexes prévoient et ne prévoient pas
La directive distingue les secteurs essentiels (annexe I) et les secteurs importants (annexe II). L'infrastructure numérique et les services TIC figurent à l'annexe I, cette dernière catégorie visant spécifiquement les parties qui gèrent ou surveillent l'environnement TIC d'autrui — pensez aux fournisseurs de services gérés. Si vous proposez un produit SaaS où vous gérez l'infrastructure pour les clients, ou si vous proposez en plus de votre logiciel la gestion, la surveillance ou l'hébergement, vous vous rapprochez de cette catégorie. Si vous proposez uniquement une application que le client gère et héberge lui-même, c'est différent.
La classification ne tient pas tant à la façon dont vous vous présentez qu'à ce que vous faites réellement pour le client. Deux entreprises qui s'appellent toutes deux « développeur de logiciels » peuvent donc avoir des résultats différents dès lors que l'une d'elles assume également la gestion. Un test structuré selon le secteur, la taille et la position dans la chaîne d'approvisionnement vous donnera plus rapidement une réponse que n'importe quelle discussion informelle sur des listes de contrôle. déterminer votre position en quelques questions
Taille : le seuil s'applique aussi si le secteur correspond
Même si votre activité relève d'une catégorie mentionnée, il existe des seuils de taille : la directive fait une distinction entre les moyennes et grandes entreprises, avec des résultats différents pour les petites organisations. Une petite équipe de développement qui propose par hasard aussi l'hébergement ne relève pas automatiquement de la même catégorie qu'un grand fournisseur de services en nuage. Les seuils exacts et les exceptions qui s'y appliquent sont énoncés dans la directive et sa transposition nationale ; ce n'est pas quelque chose sur lequel vous devriez vous prononcer sur la base d'une règle empirique.
Position dans la chaîne d'approvisionnement : être touché sans être vous-même soumis à l'obligation
C'est là que réside l'aspect pratique pour la plupart des sociétés de logiciels. L'obligation de diligence (article 21) oblige les entités essentielles et importantes à évaluer également la sécurité de leurs fournisseurs. Si vous développez un logiciel pour un hôpital, une entreprise énergétique ou une commune, il est probable que ce client vous envoie un questionnaire de sécurité sur votre processus de développement — indépendamment de la question de savoir si vous relevez vous-même de la directive.
Ces questionnaires ne portent guère sur des principes politiques abstraits. Ils demandent concrètement comment vous identifiez et corrigez les vulnérabilités, comment les correctifs sont livrés au client et qui dans votre entreprise a accès au code source et à l'environnement de production. Lorsqu'on reçoit ces questions pour la première fois, on l'expérimente souvent comme une surprise qui met le contrat sous pression ; avec un ensemble de réponses établi, cela va beaucoup plus vite la deuxième fois. les sujets qui ont été sélectionnés selon chaque situation
Deux couches de sécurité : le produit et la chaîne de développement
Dans le développement logiciel, deux questions s'entrecroisent, et il est utile de les distinguer. La première porte sur ce que vous construisez : existe-t-il un processus pour détecter et corriger les failles de sécurité dans le code, les dépendances et les bibliothèques sont-elles documentées, et à quelle vitesse une mise à jour de sécurité parvient-elle au client ? La seconde porte sur la façon dont vous construisez : qui a accès au dépôt de code source, comment le pipeline CI/CD est-il sécurisé, et qui est autorisé à déployer réellement en production ?
Un questionnaire de sécurité d'un donneur d'ordre touche généralement ces deux niveaux à la fois, même si le client lui-même ne les distingue pas. Les autorités de contrôle et les donneurs d'ordre examinent lors de telles questions s'il existe un processus identifiable et si ce processus est documenté, et non seulement l'intention derrière.
Ce que vous pouvez faire maintenant
Le fait que le développement logiciel relève de la directive NIS2 dans votre cas dépend donc du service précis que vous fournissez, de la taille de votre organisation et du secteur dans lequel opèrent vos clients. Il n'existe pas de réponse unique « oui » ou « non » pour l'ensemble du secteur, et l'évaluation finale de votre situation relève d'un juriste ou de l'autorité de contrôle, non d'un article de blog.
Ce qui est possible, c'est de vérifier dans laquelle des trois positions vous vous trouvez — vous-même soumis aux obligations, touché par le biais d'un client, ou pour l'instant non touché — et de là déterminer quelles questions vous pouvez attendre. Vous en saurez plus sur la façon dont cette classification est établie et sur les sources utilisées sur la page sur la méthode de travail. Si vous souhaitez établir cette première classification pour votre propre entreprise, cela peut se faire en quelques minutes, sans qu'un compte soit nécessaire. les questions les plus fréquemment posées sur la classification donnent un aperçu supplémentaire de la façon dont d'autres sociétés de développement abordent la même question.