Un client qui relève de l'obligation de diligence requise en vertu de NIS2 doit être en mesure de démontrer qu'il connaît les risques présents dans sa propre chaîne d'approvisionnement. Le logiciel que vous développez pour ce client fait partie de cette chaîne. En pratique, cela se traduit par des exigences contractuelles qui touchent deux aspects à la fois : le produit que vous livrez et la manière dont vous le produisez. Les deux éléments sont repris dans le texte du contrat, souvent en annexe du contrat d'achat.
Le point clé est simple à retenir : le client ne demande pas seulement si le logiciel fonctionne, mais aussi si vous pouvez démontrer comment il reste sécurisé, qui peut y accéder et ce qui se passe en cas de problème. C'est un changement par rapport au passé, lorsque la fonctionnalité et le délai de livraison étaient souvent les seuls sujets de discussion.
Exigences concernant le produit que vous livrez
L'exigence contractuelle la plus courante concerne la composition du logiciel lui-même. Les clients demandent de plus en plus souvent un aperçu des bibliothèques utilisées et des composants à source ouvert, appelé liste des composants logiciels. La raison en est qu'une vulnérabilité dans un composant sous-jacent est tout aussi risquée qu'une erreur dans votre propre code, et qu'un client souhaite pouvoir examiner ces risques sans lire le code source lui-même.
Par ailleurs, les exigences concernent la manière dont les vulnérabilités du logiciel sont détectées et corrigées, et dans quel délai. Cela peut impliquer des analyses automatisées des faiblesses connues, une procédure fixe pour les correctifs, ou la question de savoir qui peut signaler une vulnérabilité et où elle doit être adressée. Pour les logiciels existants, on demande parfois aussi la durée du support : pendant combien de temps une version reçoit-elle des mises à jour de sécurité.
Exigences concernant votre propre pipeline de développement
Un deuxième ensemble d'exigences ne porte pas sur le produit, mais sur le processus de sa création : le pipeline de développement. Pensez à qui a accès au code source et à l'environnement dans lequel le logiciel est construit et testé, comment les modifications sont contrôlées avant leur mise en production, et s'il existe une séparation entre un environnement de test, d'acceptation et de production. L'utilisation de l'authentification multifacteur pour les développeurs ayant accès au code source ou aux systèmes de compilation apparaît également dans les contrats, tout comme la question de savoir qui gère les clés et les identifiants d'accès associés au déploiement de logiciels.
Certains clients demandent également la provenance du logiciel que vous utilisez vous-même pour construire : le compilateur, les outils de compilation, les paquets téléchargés pendant la compilation. Ceci s'inscrit dans une prise de conscience plus large qu'une attaque ne peut pas seulement passer par le produit final, mais aussi par l'usine où il est fabriqué.
Pourquoi ces exigences sont formulées précisément de cette manière
L'obligation de diligence requise qui sous-tend tout cela oblige une organisation assujettie à évaluer et à maîtriser les risques dans sa propre chaîne d'approvisionnement. La manière dont cela est précisément mis en œuvre varie d'un pays à l'autre selon la loi nationale transposant la directive européenne, et selon le secteur dans lequel opère le client. Ce qui constitue une exigence stricte dans un contrat reste une question facultative dans un autre contrat. Si vous voulez savoir comment cette obligation est structurée au fond, vous la trouverez dans l'explication de chaque obligation dans notre base de connaissances.
Il est important de se rappeler que c'est le client qui pose ces exigences parce qu'il est lui-même soumis à la surveillance, et non parce que les entreprises de logiciels relèvent en tant que telles de la directive. Que cela soit appliqué et à quel niveau de rigueur dans votre cas dépend du secteur et de la taille de ce client spécifique. Pour votre situation personnelle, le texte de la loi nationale ou l'avis d'un juriste est le point de départ approprié, non pas une estimation générale.
Ce que cela signifie pour votre préparation
La plupart de ces exigences peuvent être bien satisfaites avec un peu de préparation, et la réponse que vous rédigez une fois peut être réutilisée à chaque fois auprès d'un nouveau client. Une liste des composants utilisés, une brève description de votre contrôle d'accès et une procédure fixe pour les correctifs ne sont pas des documents que vous devez réinventer pour chaque contrat.
Souhaitez-vous d'abord voir si et comment cela affecte votre entreprise, alors la vérification qui détermine votre position dans la chaîne en quelques questions vous donne une première orientation, sans qu'il soit nécessaire d'avoir un compte. Pour les questions que les clients posent concrètement et la manière dont nous vous aidons, lisez la suite sur la page des questions fréquemment posées ou consultez comment nous étayons les informations sur la plateforme.
La base de connaissances gratuite et la vérification vous donnent une première impression sans engagements. Si vous souhaitez ensuite traduire concrètement les exigences contractuelles en un dossier évolutif avec des preuves et des réponses clés en main aux questionnaires, c'est le moment d'examiner ce qu'un abonnement y ajoute.