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 leçon explique ce mécanisme, montre où il se cache dans un projet, pourquoi il est au cœur des attaques de la chaîne d'approvisionnement logicielle (supply chain), et comment le garder sous contrôle.
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 d'équipes mesurent, et que la leçon sécurité de la supply chain logicielle a posée comme point de départ du module.
- Définir la confiance transitive et la chaîne de délégation qu'elle crée.
- Repérer où elle se cache : dépendances logicielles, fournisseurs cloud, autorités de certification, images de base.
- Comprendre pourquoi elle rend possibles les attaques de la supply chain, illustrées par des incidents réels.
- Appliquer trois réflexes pour la maîtriser : réduire, vérifier, surveiller.
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, qui fait confiance à d'autres, et de proche en proche vous dépendez 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.
Vous n'avez évalué que le premier maillon, mais votre exposition est celle de la chaîne entière. Une dépendance directe que vous avez auditée en tire vingt autres jamais examinées ; un fournisseur SaaS certifié sous-traite son stockage à un tiers dont vous ignorez le nom. Votre risque réel est fixé par le maillon le plus faible derrière ce que vous avez vérifié.
En informatique, cette chaîne est rarement visible et souvent très longue. Un logiciel moderne assemble des morceaux venus de partout, et chaque morceau en assemble d'autres. La confiance placée dans le produit final se propage vers des dizaines, parfois des centaines, d'auteurs inconnus.
Où la confiance transitive se cache-t-elle ?
Section intitulée « Où la confiance transitive se cache-t-elle ? »La confiance transitive est partout dès qu'on construit un système à partir de briques existantes. Quatre endroits la concentrent, chacun avec son vecteur d'attaque propre ; chaque terme est défini à sa première apparition.
Les dépendances logicielles sont le cas le plus courant. Une dépendance est du code écrit par d'autres que votre application réutilise, par exemple une bibliothèque pour gérer les dates. Le piège vient des dépendances transitives, les dépendances de vos dépendances : vous en choisissez dix, et vous vous retrouvez avec des centaines de briques dont vous ignorez jusqu'au nom.
Les fournisseurs cloud forment une deuxième couche. En faisant confiance à un fournisseur, vous héritez de sa propre chaîne : ses sous-traitants (maintenance des centres de données, réseau, surveillance). Une faille chez l'un d'eux 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 garantit, par un certificat, qu'un site est bien celui qu'il prétend être. Votre navigateur fait confiance à une liste d'autorités : si l'une d'elles signe un faux certificat, des sites frauduleux peuvent passer pour légitimes.
Les images de base concernent les conteneurs. Une image de base est le point de départ sur lequel on construit, par exemple un système Linux minimal. En partant d'elle, vous faites confiance à celui qui l'a préparée, aux mainteneurs de chaque programme qu'elle contient et au registre qui la distribue.
Pourquoi est-ce un risque majeur ?
Section intitulée « Pourquoi est-ce un risque majeur ? »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 jusqu'à vous. C'est le principe des attaques de la supply chain logicielle.
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. Ici, le cadeau 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 code piégé est un logiciel malveillant (malware). La page sur les logiciels malveillants détaille ce qu'il cherche à faire une fois exécuté : voler des secrets, ouvrir une porte dérobée, miner de la cryptomonnaie. Le danger ne vient pas d'une brique mal choisie, mais d'une brique de confiance détournée.
Que montrent les incidents réels ?
Section intitulée « Que montrent les incidents réels ? »Trois incidents publics illustrent chacun une façon de détourner la confiance transitive. Ils sont documentés et servent de cas d'école dans la profession ; aucun ne demandait à la victime une erreur, seulement d'avoir fait confiance à une brique populaire.
| Incident | Ce qui s'est passé | Ce qu'il montre |
|---|---|---|
| event-stream (npm, 2018) | Le mainteneur cède le projet à un inconnu, qui ajoute une dépendance malveillante, flatmap-stream, visant un portefeuille de cryptomonnaie | Un changement de mainteneur suffit à empoisonner une dépendance transitive |
| ua-parser-js (npm, 2021) | Le compte du mainteneur est piraté et des versions piégées sont publiées, avec un mineur de cryptomonnaie et un voleur de mots de passe | Un compte compromis publie au nom d'un auteur de confiance |
| xz-utils (2024, CVE-2024-3094) | Un contributeur gagne la confiance du projet pendant plus de deux ans, puis insère une porte dérobée visant le démon SSH de certaines distributions Linux | L'attaque peut viser la confiance humaine, sur des années |
Comment maîtriser la confiance transitive ?
Section intitulée « Comment maîtriser la confiance transitive ? »On ne supprime pas la confiance transitive : réutiliser du code et des services 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 couvrent 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 tirent peu de dépendances transitives : c'est le principe de minimisation, qui réduit aussi la surface d'attaque.
Le deuxième réflexe est de vérifier chaque maillon. La signature numérique prouve qu'une brique vient bien de son auteur et n'a pas été modifiée, comme un cachet de cire intact ; la leçon Signer et vérifier avec Cosign la met en pratique. Le SBOM (Software Bill of Materials, la liste des ingrédients) recense toutes les briques, directes et transitives : voir la leçon SBOM.
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é. Figer les versions dans un fichier de verrouillage, filtrer ce qui entre (leçon Contrôler l'entrée des dépendances) et s'alerter des nouvelles dépendances permettent de réagir vite. La confiance n'est jamais acquise : elle se réévalue.
Un scénario concret
Section intitulée « Un scénario concret »Une petite équipe développe une application web avec quinze bibliothèques directes, ce qui lui paraît raisonnable. Ces quinze briques en tirent des centaines d'autres : plus de trois cents dépendances transitives, écrites par des dizaines d'auteurs que l'équipe ne connaît pas.
Un attaquant repère une brique enfouie très loin dans cette chaîne. Il pirate le compte de la personne qui la maintient et publie une nouvelle version qui contient, en plus des fonctions habituelles, quelques lignes malveillantes, exactement le schéma de ua-parser-js. La brique continue de fonctionner normalement.
L'application 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é, s'exécute pendant la construction, vole les secrets du projet et les envoie à l'attaquant. Des versions figées dans un fichier de verrouillage, un SBOM comparé d'une construction à l'autre et une alerte sur toute dépendance nouvelle auraient fait repérer la nouveauté avant les dégâts.
Quels pièges éviter ?
Section intitulée « Quels pièges éviter ? »Certaines habitudes très répandues renforcent la confiance transitive sans qu'on s'en rende compte. Chacune repose sur une intuition rassurante mais fausse, et chacune a sa parade.
Le premier piège est la confiance par popularité : croire qu'une brique massivement utilisée est forcément propre. Les trois incidents ci-dessus concernaient des briques très répandues ; la popularité attire les attaquants, elle ne rassure pas.
Le deuxième piège est la confiance par certification : penser qu'un label de sécurité couvre toute la chaîne d'un fournisseur. Une certification vaut pour un périmètre défini, à un instant donné, et ne garantit ni les sous-traitants ni l'absence de faille apparue depuis.
Le troisième piège est la confiance figée : l'accorder une fois et ne plus jamais la remettre en question. Les mainteneurs passent la main, comme pour event-stream, et les comptes se font pirater : une confiance jamais réévaluée finit par être injustifiée.
Le dernier piège est l'oubli des dépendances transitives : surveiller les seules briques choisies soi-même. C'est 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, par changement de mainteneur (event-stream), compte piraté (ua-parser-js) ou infiltration patiente (xz-utils).
- Vérifiez plutôt que de croire : signatures et SBOM disent d'où vient chaque brique et ce qu'elle contient.
- La confiance n'est jamais définitive : réduisez les maillons, figez les versions, surveillez les changements.
- Ce concept nourrit tout un modèle de menaces : le modèle de menaces SOCLE relie ces vecteurs aux contrôles qui protègent votre organisation.
Contrôle de connaissances
Section intitulée « Contrôle de connaissances »Vérifiez que vous avez retenu l'essentiel de ce guide. Les questions portent uniquement sur ce qui vient d'être expliqué ici.
Contrôle de connaissances
Validez vos connaissances avec ce quiz interactif
Informations
- Le chronomètre démarre au clic sur Démarrer
- Questions à choix multiples, vrai/faux et réponses courtes
- Vous pouvez naviguer entre les questions
- Les résultats détaillés sont affichés à la fin
Lance le quiz et démarre le chronomètre
Vérification
(0/0)Score par domaine
Un domaine regroupe plusieurs guides et reçoit plusieurs questions : son score est plus fiable qu'un score par thème, qui porte souvent sur une seule question.
Bilan
Points forts
Aucun sujet réussi à 80 % sur au moins deux questions pour l’instant.
Points faibles
Aucun sujet sous le seuil de réussite.
À faire ensuite
Des indices pour retenter votre chance ?
Continuer le cours : SBOM : l'inventaire de ce qu'on livre
Nouveau quiz complet avec des questions aléatoires
Retravailler uniquement les questions ratées
Retour à la liste des certifications