Quelles questions une entreprise de logiciels reçoit-elle dans une liste de contrôle NIS2 ?
Si vous développez des logiciels pour un client qui relève lui-même de la directive NIS2 — ou de la loi sur la cybersécurité aux Pays-Bas — vous recevrez presque certainement un questionnaire de sécurité. Les questions qu'il contient portent toujours sur deux aspects du développement de logiciels : la sécurité de ce que vous livrez et la sécurité de l'environnement dans lequel vous le créez. Ce deuxième point distingue ces questionnaires de ceux destinés, par exemple, à une entreprise d'installation ou à un prestataire de services généraux.
Le cœur est toujours le même : quelqu'un peut-il accéder au système de votre client via votre code source, votre environnement de construction ou votre compte auprès d'un gestionnaire de packages, et que faites-vous pour l'empêcher ou le détecter rapidement. Quiconque peut répondre à ces deux questions est déjà bien avancé dans la liste.
Pourquoi le logiciel est une catégorie distincte
Chez la plupart des fournisseurs, un client examine ce qui se passe au sein de votre entreprise : qui a accès à quels systèmes, comment testez-vous une sauvegarde. Chez un éditeur de logiciels, il y a une couche supplémentaire : ce que vous envoyez de votre entreprise vers celle du client. Il peut s'agir d'une mise à jour, d'une connexion API ou de code s'exécutant directement dans leur environnement. C'est pourquoi un client pose des questions plus approfondies qu'avec un fournisseur qui n'utilise que l'automatisation de bureau.
Questions sur le produit : ce que vous livrez
Une grande partie du questionnaire porte sur le logiciel lui-même. Utilisez-vous des bibliothèques et des composants externes, et en tenez-vous un inventaire — souvent désignés comme une liste des composants logiciels. Comment gérez-vous une vulnérabilité découverte dans l'un de ces composants, et dans quel délai publiez-vous une mise à jour. Le code est-il examiné par une deuxième personne avant sa mise en ligne. Testez-vous les failles connues avant la livraison, et qui effectue ce test.
En dessous, il y a souvent encore une question sur la notification : si quelqu'un en dehors de votre entreprise découvre une vulnérabilité dans votre logiciel, existe-t-il un moyen de vous le signaler, et qu'advient-il de cette notification. Ce n'est pas une obligation juridique découlant directement de la directive NIS2 en tant que fournisseur, mais les clients le demandent en pratique parce qu'ils doivent pouvoir le justifier auprès de leur propre autorité de contrôle.
Questions sur l'environnement de développement : comment vous construisez
Le deuxième bloc porte sur l'environnement dans lequel le logiciel est créé. Qui a accès au code source, et cet accès est-il personnel ou partagé. L'authentification multifacteur est-elle activée sur l'environnement de construction et de livraison. Une modification est-elle automatiquement testée avant d'aller en production, et quelqu'un peut-il contourner cette étape. Qui gère les clés et les certificats utilisés pour signer le logiciel, et où sont-ils stockés.
Également très récurrent : comment gérez-vous les ordinateurs portables et les comptes des développeurs qui travaillent dans cet environnement, surtout s'ils travaillent à distance. Et : conservez-vous des journaux de qui a modifié quoi dans le code ou le pipeline, et pendant combien de temps. Ce dernier point s'inscrit dans le cadre plus large de ce qu'on appelle la journalisation des incidents, mais appliqué à l'environnement de développement lui-même.
Ce qu'un client peut et ne peut pas vous demander
La liste peut porter sur la sécurité de votre produit et de votre processus de développement dans la mesure où cela affecte le risque du client. Les questions sur l'ensemble de votre organisation interne, votre politique en matière de ressources humaines indépendamment de ce contexte, ou les parties de votre entreprise sans lien avec le logiciel livré n'en font pas partie. Le lieu exact de cette limite varie selon le contrat et le secteur, et c'est quelque chose à clarifier dans la discussion avec le client, pas quelque chose à laisser passer en silence.
Comment construire cela correctement une seule fois
La plupart de ces questions ne constituent pas un instantané mais un ensemble permanent qui revient auprès de presque chaque client, avec simplement une formulation différente. Celui qui enregistre les réponses une fois par mesure — avec une pièce justificative et un responsable — n'a qu'à les copier et les adapter à la liste de questions suivante. avec quelques questions qui montrent si et comment vous êtes concerné vous voyez d'abord où vous en êtes, et dans l'aperçu par sujet vous trouverez l'élaboration des mesures individuelles telles que la gestion des accès et l'enregistrement des incidents. Si vous avez des doutes sur une question spécifique dans une liste que vous avez reçue, la liste des questions fréquemment posées fournit souvent déjà une première orientation, et une explication sur les sources de nos informations montre comment nous tenons nos sources à jour.
Si vous souhaitez d'abord vérifier par vous-même si et comment votre entreprise se situe à cet égard, effectuez alors l'évaluation rapide gratuite ou consultez la base de connaissances. Les deux peuvent être consultés sans compte et donnent une première indication factuelle — pas un jugement sur votre situation spécifique, pour laquelle vous pouvez toujours vous adresser à un juriste ou à l'autorité compétente pour votre secteur en cas de doute.