En tant que société de logiciels, vous recevez de plus en plus souvent un questionnaire de sécurité d'un client soumis à la Loi sur la cybersécurité. Cette même obligation de diligence qui oblige votre client envers vous vous oblige vous-même à quelque chose : évaluer lesquels de vos propres fournisseurs ont une incidence sur la sécurité de ce que vous construisez et livrez. Une politique de sélection des fournisseurs est le moyen de rendre cette évaluation reproductible, plutôt que de repenser à chaque fois en qui vous faites confiance.
En bref : vous commencez par un aperçu de qui se trouve dans votre chaîne de développement et dans votre logiciel livré, vous classez ces fournisseurs selon le risque qu'ils représentent, et vous établissez par catégorie les exigences que vous posez et comment vous les vérifiez. Cet aperçu et ce classement constituent ensemble la politique de sélection des fournisseurs.
Deux types de fournisseurs, un point faible
En développement logiciel, deux chaînes d'approvisionnement s'entrelacent, ce qui rend une politique de sélection des fournisseurs plus complexe que pour une entreprise qui n'achète que des biens physiques.
La première chaîne est votre chaîne de développement : le gestionnaire de code source, le pipeline CI/CD, l'environnement cloud sur lequel vous travaillez, les outils de test et de déploiement. Un point faible ici affecte d'abord votre propre exploitation.
La deuxième chaîne est ce qui se retrouve dans votre produit : les bibliothèques open source, les API de tiers, les composants achetés. Un point faible ici n'affecte pas seulement vous, mais aussi chaque client qui utilise votre logiciel. Cette distinction est précisément là où de nombreuses politiques de sélection des fournisseurs sont insuffisantes : l'attention se porte sur la première chaîne parce qu'elle est visible dans le travail quotidien, tandis que la deuxième chaîne ne devient souvent visible que lorsque quelque chose se passe mal.
Inventaire : commencez par ce qui fonctionne déjà
Une politique de sélection des fournisseurs ne commence pas par un modèle, mais par une liste. Pour le développement logiciel, cela signifie au minimum : les fournisseurs de cloud que vous utilisez, les gestionnaires de paquets et les registres que votre processus de construction utilise, les API externes que votre produit appelle, et lesquels de ces tiers peuvent accéder au code, aux secrets ou aux données de production.
Pour chaque fournisseur, la question n'est pas seulement ce qu'il fait, mais ce qui se passe s'il s'arrête ou est compromis. Un gestionnaire de paquets d'où proviennent des centaines de dépendances pèse différemment qu'un logiciel de facturation qui fonctionne indépendamment de la chaîne de développement.
Classement des risques : tous les fournisseurs ne méritent pas la même attention
Après l'inventaire, vient un classement, généralement en deux ou trois niveaux. Les fournisseurs ayant accès au code source, aux secrets ou aux environnements de production exigent les exigences les plus strictes : authentification forte, journalisation, un point de contact fixe en cas d'incident. Les fournisseurs qui ne contribuent qu'indirectement, comme un outil de gestion de projet, exigent moins.
La directive et la loi nationale n'imposent pas de classement fixe ; les autorités de surveillance examinent si les mesures sont proportionnées au risque. Cela signifie que le classement que vous choisissez doit être justifiable : pourquoi ce fournisseur relève de la catégorie lourde et pas celui-là.
Ce que vous demandez et ce que vous répondez vous-même
Une politique de sélection des fournisseurs fonctionne dans les deux sens. Vers l'extérieur, vous l'utilisez pour poser des questions à vos propres fournisseurs : comment gèrent-ils les vulnérabilités, ont-ils un processus d'authentification multifacteur, à quelle vitesse vous signalent-ils un incident. Vers l'intérieur, elle constitue la base de ce que vous répondez vous-même aux questionnaires de vos clients, car un client qui vous évalue veut souvent savoir si vous avez pris conscience de votre propre chaîne d'approvisionnement.
Ces deux aspects sont liés : une politique de fournisseurs que vous rédigez uniquement pour vous-même ne correspond généralement pas aux questions que vous recevez de vos clients. Si vous mettez en place la politique dès le départ en tenant compte de ce que demande un acheteur, vous n'aurez pas besoin de la réécrire par la suite.
Documenter : de la politique à la preuve
Une politique qui n'existe que dans un document textuel est difficile à justifier au moment où un client ou une autorité de contrôle la demande. Une approche plus pratique consiste à tenir un registre actif : par fournisseur, la catégorie de risque, l'évaluation la plus récente, le document justificatif tel qu'une déclaration, un certificat ou une réponse à votre propre questionnaire, et qui au sein de votre organisation surveille ce fournisseur.
Un tel registre n'a pas besoin d'être volumineux pour être utile. Pour une entreprise de logiciels ayant quelques fournisseurs critiques, un tableau avec quelques colonnes suffit généralement, pour autant qu'il soit maintenu à jour lors d'un changement de fournisseur ou d'un renouvellement de contrat.
Souhaitez-vous d'abord savoir si votre organisation est elle-même soumise à l'obligation de diligence, ou uniquement affectée par vos clients ? effectuez le contrôle gratuit en quelques questions et lisez sur la page couvrant tous les sujets comment l'évaluation des fournisseurs est liée aux autres obligations. Curieux de savoir d'où proviennent les informations sur cette plateforme et à quel point elles sont à jour ? Cela est expliqué sur la page sur le fonctionnement. Si vous souhaitez transformer le registre des fournisseurs en un dossier contenant des documents justificatifs et des responsables, vous trouverez sur la page des abonnements ce qui est nécessaire pour cela.