La confiance transitive, c'est le fait d'hériter automatiquement du risque de tout ce dont dépend une chose en laquelle vous avez confiance. Si vous faites confiance à un fournisseur, et que ce fournisseur s'appuie sur d'autres briques, vous faites implicitement confiance à ces briques aussi, sans les connaître. Cette page explique ce mécanisme avec des mots simples, montre où il se cache dans un projet informatique, pourquoi il est au cœur des attaques dites de supply chain (la chaîne d'approvisionnement du logiciel), et comment le garder sous contrôle. Elle s'adresse à toute personne curieuse de sécurité, sans prérequis technique.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »Le mot « transitif » vient des mathématiques : si A est lié à B, et B à C, alors A est lié à C. Appliqué à la confiance, cela donne une propagation invisible que peu de gens mesurent. Concrètement, vous saurez :
- Définir la confiance transitive avec une analogie simple, sans jargon.
- Repérer où elle se cache : dépendances logicielles, fournisseurs cloud, autorités de certification, images de base.
- Comprendre pourquoi elle rend possible les attaques supply chain, où un code malveillant se glisse dans une brique de confiance.
- Appliquer trois réflexes pour la maîtriser : réduire, vérifier, surveiller.
- Relier ce concept aux menaces concrètes décrites dans les logiciels malveillants, le panorama des menaces et le modèle de menaces SOCLE.
Qu'est-ce que la confiance transitive
Section intitulée « Qu'est-ce que la confiance transitive »La confiance transitive est la confiance que vous accordez sans le vouloir, par ricochet. Vous faites confiance à quelqu'un, cette personne fait confiance à d'autres, et de proche en proche vous vous retrouvez à dépendre d'acteurs que vous n'avez jamais choisis. La règle tient en une phrase : si A fait confiance à B, et B fait confiance à C, alors A dépend de C sans le savoir.
Prenons une analogie du quotidien. Vous prêtez la clé de votre appartement à un ami de confiance. Cet ami, sans vous le dire, la confie à son cousin pour arroser vos plantes. Le cousin en fait un double qu'il oublie dans un bar. Vous n'avez jamais rencontré ce cousin, ni le bar, pourtant la sécurité de votre logement dépend désormais d'eux. C'est exactement la confiance transitive : votre risque n'est plus fixé par la personne que vous connaissez, mais par le maillon le plus faible de toute la chaîne derrière elle.
En informatique, cette chaîne est rarement visible et souvent très longue. Un logiciel moderne n'est presque jamais écrit entièrement par ceux qui le livrent. Il assemble des morceaux venus de partout, et chaque morceau en assemble d'autres. La confiance que vous placez dans le produit final se propage silencieusement vers des dizaines, parfois des centaines, d'auteurs inconnus.
Où elle se cache
Section intitulée « Où elle se cache »La confiance transitive n'est pas un cas rare : elle est partout dès qu'on construit un système à partir de briques existantes. Voici les quatre endroits où elle se loge le plus souvent, avec une définition simple de chaque terme.
Les dépendances logicielles sont le cas le plus courant. Une dépendance est un bout de code écrit par quelqu'un d'autre que votre application réutilise plutôt que de le réécrire, par exemple une bibliothèque (un ensemble de fonctions prêtes à l'emploi) pour gérer les dates ou envoyer des e-mails. Le piège vient des dépendances transitives : les dépendances de vos dépendances. Vous en choisissez dix, mais chacune en tire d'autres, et vous vous retrouvez avec des centaines de briques dont vous ignorez jusqu'au nom.
Les fournisseurs cloud forment une deuxième couche. Un fournisseur cloud loue de la puissance informatique et du stockage à distance. En lui faisant confiance, vous héritez de sa propre chaîne : ses sous-traitants, les entreprises auxquelles il délègue une partie du travail (maintenance des centres de données, réseau, surveillance). Une faille chez l'un de ces sous-traitants peut vous toucher, même si votre fournisseur direct est irréprochable.
Les autorités de certification sont plus discrètes mais essentielles. Une autorité de certification est un tiers de confiance qui garantit qu'un site web est bien celui qu'il prétend être, grâce à un certificat (une sorte de carte d'identité numérique). Votre navigateur fait confiance à une liste d'autorités ; vous héritez donc de leur sérieux. Si l'une d'elles se fait berner et signe un faux certificat, des sites frauduleux peuvent se faire passer pour légitimes.
Les images de base concernent surtout les conteneurs (des paquets qui embarquent une application et tout ce dont elle a besoin pour tourner). Une image de base est le point de départ tout prêt sur lequel on construit, par exemple un système Linux minimal fourni par un éditeur. En partant de cette image, vous faites confiance à celui qui l'a préparée, aux mainteneurs de chaque programme qu'elle contient, et au dépôt public qui la distribue.
Pourquoi c'est un risque majeur (attaques supply chain)
Section intitulée « Pourquoi c'est un risque majeur (attaques supply chain) »La confiance transitive devient dangereuse parce qu'un attaquant n'a pas besoin de forcer votre porte : il lui suffit de compromettre un maillon en amont, et le poison descend tout seul jusqu'à vous. C'est le principe des attaques de la supply chain logicielle, la chaîne d'approvisionnement du code.
L'image la plus juste est celle du cheval de Troie. Plutôt que d'attaquer la ville de front, l'assaillant cache ses soldats dans un cadeau que les habitants font entrer eux-mêmes. En sécurité informatique, le cadeau, c'est une mise à jour d'une bibliothèque populaire que des milliers de projets installent sans se méfier. Le code malveillant profite de la confiance déjà accordée pour s'exécuter au cœur de systèmes qui n'auraient jamais laissé entrer un inconnu.
Ce type de code piégé porte un nom : ce sont des logiciels malveillants (malwares). La page dédiée aux logiciels malveillants détaille comment un cheval de Troie se dissimule dans une dépendance et ce qu'il cherche à faire une fois exécuté (voler des secrets, ouvrir une porte dérobée, miner de la cryptomonnaie). L'important à retenir ici : le danger ne vient pas d'une brique que vous auriez mal choisie, mais d'une brique de confiance détournée à votre insu.
Comment le maîtriser
Section intitulée « Comment le maîtriser »On ne supprime pas la confiance transitive : réutiliser du code et des services existants est ce qui rend l'informatique moderne possible. On la maîtrise en gardant la chaîne courte, vérifiée et sous surveillance. Trois réflexes suffisent à couvrir l'essentiel.
Le premier réflexe est de réduire les dépendances. Moins il y a de maillons, moins il y a de portes d'entrée. Avant d'ajouter une bibliothèque, demandez-vous si vous en avez vraiment besoin, et préférez celles qui traînent peu de dépendances transitives derrière elles. C'est le principe de minimisation, qui consiste à ne garder que le strict nécessaire, et qui rejoint la réduction de la surface d'attaque, l'ensemble des points par lesquels on pourrait vous attaquer.
Le deuxième réflexe est de vérifier chaque maillon au lieu de faire confiance à l'aveugle. Deux outils simples aident ici. La signature numérique est un sceau cryptographique qui prouve qu'une brique vient bien de son auteur et n'a pas été modifiée en route, comme un cachet de cire intact sur une lettre. Le SBOM (Software Bill of Materials, la « liste des ingrédients » de votre logiciel) recense toutes les briques utilisées, directes et transitives, pour que vous sachiez enfin ce que vous embarquez vraiment.
Le troisième réflexe est de surveiller dans le temps. Une brique sûre aujourd'hui peut être compromise demain : un mainteneur change, un compte est piraté, une entreprise est rachetée. Garder un inventaire à jour, s'alerter des nouvelles dépendances qui apparaissent et suivre les incidents publics permet de réagir vite. La confiance n'est jamais acquise une fois pour toutes ; elle se réévalue régulièrement.
Un scénario concret
Section intitulée « Un scénario concret »Imaginons une petite équipe qui développe une application web. Elle choisit quinze bibliothèques directes, ce qui lui paraît raisonnable. En réalité, ces quinze briques en tirent des centaines d'autres : au total, plus de trois cents dépendances transitives, écrites par des dizaines d'auteurs répartis dans plusieurs pays. L'équipe n'a jamais entendu parler de la plupart d'entre eux.
Un attaquant repère une brique enfouie très loin dans cette chaîne, une dépendance d'une dépendance d'une dépendance. Il parvient à pirater le compte de la personne qui la maintient, puis publie une nouvelle version qui contient, en plus des fonctions habituelles, quelques lignes malveillantes. Rien d'alarmant en apparence : la brique continue de fonctionner normalement.
L'application de l'équipe est configurée pour récupérer automatiquement les dernières versions. À la mise à jour suivante, le code piégé descend jusqu'à elle sans que personne ne l'ait décidé. Il s'exécute au moment où l'application se construit, vole les mots de passe et clés secrets du projet, et les envoie à l'attaquant. L'équipe ne connaissait même pas l'existence de cette brique, pourtant elle lui faisait pleinement confiance. Un inventaire à jour et des versions figées auraient permis de repérer la nouveauté suspecte avant qu'elle ne fasse des dégâts.
Pièges courants
Section intitulée « Pièges courants »Certaines habitudes très répandues renforcent la confiance transitive sans qu'on s'en rende compte. Les connaître aide à ne pas tomber dedans.
Le premier piège est la confiance par popularité : croire qu'une brique massivement utilisée est forcément propre. Des bibliothèques téléchargées des millions de fois ont déjà été compromises. La popularité attire les attaquants, elle ne rassure pas.
Le deuxième piège est la confiance par certification : penser qu'un fournisseur affichant un label de sécurité couvre toute sa chaîne. Une certification vaut pour un périmètre défini, à un instant donné, et ne garantit ni le sérieux des sous-traitants ni l'absence de faille apparue depuis.
Le troisième piège est la confiance figée : accorder sa confiance une fois et ne plus jamais la remettre en question. Les mainteneurs passent la main, les comptes se font pirater, les contextes changent. Une confiance jamais réévaluée finit par être injustifiée.
Le dernier piège est l'oubli des dépendances transitives : surveiller uniquement les briques que l'on a choisies soi-même et ignorer tout ce qui se cache derrière. C'est justement dans ces profondeurs invisibles, loin des regards, que les attaques se logent le plus volontiers.
À retenir
Section intitulée « À retenir »-
La confiance se propage toute seule : faire confiance à une brique, c'est faire confiance à toute la chaîne cachée derrière elle.
-
Le maillon le plus faible fixe votre risque, pas l'acteur que vous connaissez et avez choisi.
-
Les dépendances transitives sont le point aveugle : une application ordinaire hérite de centaines de briques dont elle ignore l'existence.
-
Les attaques supply chain exploitent cette confiance en glissant un logiciel malveillant dans une brique déjà validée, façon cheval de Troie.
-
Vérifiez plutôt que de croire : signatures numériques et SBOM disent d'où vient chaque brique et ce qu'elle contient.
-
La confiance n'est jamais définitive : réduisez le nombre de maillons, gardez un inventaire à jour et surveillez les changements.
-
Ce concept nourrit tout un modèle de menaces : le modèle de menaces SOCLE relie ces vecteurs supply chain aux contrôles concrets qui protègent votre organisation.