Vous faites confiance à votre fournisseur cloud. Ce fournisseur fait confiance à ses sous-traitants. Ces sous-traitants font confiance à leurs propres dépendances. Sans le savoir, vous avez accordé votre confiance à des dizaines d’entités que vous ne connaissez pas. La confiance transitive décrit cette propagation automatique : si A fait confiance à B, et B fait confiance à C, alors A fait implicitement confiance à C.
En résumé : La confiance transitive propage automatiquement la confiance (et donc les risques) à travers les chaînes de dépendances. Compromettre un maillon suffit à compromettre tous ceux qui lui font confiance, directement ou indirectement.
L’erreur de la confiance héritée
Section intitulée « L’erreur de la confiance héritée »Une erreur fréquente consiste à accorder sa confiance sans considérer les dépendances de l’entité de confiance.
Exemples de raisonnements dangereux :
- “Ce package npm est très populaire, il est forcément sûr”
- “Notre fournisseur est certifié ISO 27001, donc ses sous-traitants aussi”
- “L’API est sécurisée, pas besoin de vérifier ce qu’elle appelle derrière”
- “Le développeur est de confiance, donc son code aussi”
- “On utilise une image Docker officielle, elle est forcément propre”
Chaque confiance accordée hérite des risques de toute la chaîne :
- Les vulnérabilités des dépendances deviennent vos vulnérabilités
- Les compromissions en amont se propagent en aval
- Les failles de vos fournisseurs impactent votre sécurité
- Les erreurs de configuration d’un tiers affectent votre système
Le mécanisme de la confiance transitive
Section intitulée « Le mécanisme de la confiance transitive »La chaîne de confiance
Section intitulée « La chaîne de confiance »La confiance se propage comme une chaîne :
Vous → Fournisseur Cloud → Hyperviseur → Firmware → Fabricant CPU ↓Application → Framework → Librairies → Dépendances transitives ↓CI/CD → Registry → Images de base → Packages systèmeChaque flèche représente une relation de confiance. Chaque maillon peut être compromis.
L’effet d’amplification
Section intitulée « L’effet d’amplification »| Niveau | Entités de confiance directe | Entités de confiance transitive |
|---|---|---|
| Application | 10 dépendances | 200+ dépendances transitives |
| Infrastructure | 3 fournisseurs | 50+ sous-traitants |
| CI/CD | 5 outils | 100+ plugins et intégrations |
Une application Node.js moyenne a 10-20 dépendances directes mais 200-500 dépendances transitives. Chacune est un vecteur d’attaque potentiel.
La métaphore du réseau social
Section intitulée « La métaphore du réseau social »Imaginez que vous acceptez comme ami quelqu’un sur un réseau social, et que cette personne partage automatiquement tout ce que ses amis lui envoient. En acceptant un ami, vous vous exposez au contenu de tous ses amis, et des amis de ses amis. Un seul compte compromis dans cette chaîne peut vous atteindre.
Les vecteurs de propagation
Section intitulée « Les vecteurs de propagation »Supply chain logicielle
Section intitulée « Supply chain logicielle »Les dépendances sont le vecteur principal de confiance transitive :
| Attaque | Mécanisme | Impact |
|---|---|---|
| Typosquatting | Package au nom similaire (lodash → lodahs) | Code malveillant exécuté |
| Dependency confusion | Package privé remplacé par un public | Exfiltration de données |
| Maintainer takeover | Compte du mainteneur compromis | Mise à jour malveillante |
| Build compromise | CI/CD du projet compromis | Artefact infecté |
Cas réels :
- event-stream (2018) : un mainteneur a transféré son package npm à un attaquant qui a injecté du code volant des bitcoins
- ua-parser-js (2021) : package avec 7 millions de téléchargements hebdomadaires compromis pour miner de la crypto
- SolarWinds (2020) : mise à jour légitime infectée, 18 000 organisations impactées
Fournisseurs et sous-traitants
Section intitulée « Fournisseurs et sous-traitants »La confiance accordée à un fournisseur s’étend à sa chaîne :
Votre entreprise ↓ (contrat, SLA)Fournisseur SaaS ↓ (hébergement)Cloud Provider ↓ (infrastructure)Datacenter ↓ (maintenance)Sous-traitant physiqueUne faille chez le sous-traitant du datacenter peut compromettre vos données, même si votre fournisseur SaaS est irréprochable.
Authentification fédérée
Section intitulée « Authentification fédérée »L’authentification déléguée crée des chaînes de confiance :
| Configuration | Chaîne de confiance |
|---|---|
| ”Se connecter avec Google” | Vous → Google → compte utilisateur |
| SSO d’entreprise | App → IdP → AD → politiques de mot de passe |
| OAuth tierce partie | App → API → fournisseur OAuth → utilisateur |
Si l’Identity Provider est compromis, toutes les applications qui lui font confiance le sont aussi.
Images et conteneurs
Section intitulée « Images et conteneurs »Les images de conteneurs héritent de toute leur chaîne :
FROM ubuntu:22.04 # Confiance à CanonicalRUN apt-get install nginx # Confiance aux mainteneurs des packagesCOPY app /app # Votre codeVous faites confiance à :
- Canonical (image de base)
- Les mainteneurs de chaque package APT
- Docker Hub (distribution)
- Votre registry (stockage)
Scénario 1 : La dépendance compromise
Section intitulée « Scénario 1 : La dépendance compromise »Une équipe développe une application Node.js avec 15 dépendances directes.
Chaîne de confiance réelle :
- 15 dépendances directes
- 347 dépendances transitives
- 89 mainteneurs différents
- 12 organisations distinctes
L’attaque :
- Un attaquant compromet le compte npm d’un mainteneur d’une dépendance de niveau 4 (dépendance d’une dépendance d’une dépendance)
- Il publie une version mineure avec du code malveillant
- Les mises à jour automatiques (
^1.2.0) tirent la nouvelle version - Le code malveillant s’exécute dans le CI/CD de l’équipe
- Les secrets du pipeline sont exfiltrés
Impact : L’équipe n’a jamais entendu parler de cette dépendance de niveau 4, mais elle lui faisait implicitement confiance.
Avec gestion de la confiance transitive :
- Lock files stricts (
package-lock.json) - Audit régulier des dépendances (
npm audit) - Politique de mise à jour contrôlée (pas de
^ou~) - Revue des nouvelles dépendances transitives
- Signature et vérification des packages
Scénario 2 : Le fournisseur compromis
Section intitulée « Scénario 2 : Le fournisseur compromis »Une entreprise utilise un SaaS de gestion de projet.
Chaîne de confiance :
Entreprise → SaaS → Cloud Provider → CDN → Analytics tiers → Service d'email → Outil de monitoring → Backup providerL’attaque :
- L’outil de monitoring du SaaS est compromis
- L’attaquant accède aux logs qui contiennent des données métier
- Il utilise ces données pour du phishing ciblé
- Des employés de l’entreprise cliente sont compromis
Impact : L’entreprise n’avait aucune relation avec l’outil de monitoring, mais elle lui faisait confiance via le SaaS.
Avec gestion de la confiance transitive :
- Due diligence sur les sous-traitants critiques
- Clauses contractuelles sur la chaîne de sous-traitance
- Limitation des données partagées au strict nécessaire
- Monitoring des accès aux données sensibles
- Plan de réponse incluant les incidents fournisseurs
Réduire la confiance transitive
Section intitulée « Réduire la confiance transitive »Inventorier la chaîne de confiance
Section intitulée « Inventorier la chaîne de confiance »Cartographiez toutes les entités à qui vous faites confiance, directement et indirectement :
Pour le code :
# Lister toutes les dépendances transitives (npm)npm ls --all
# Visualiser l'arbre de dépendances (Python)pipdeptree
# Analyser les dépendances (Go)go mod graphPour l’infrastructure :
- Liste des fournisseurs et sous-traitants
- Cartographie des flux de données
- Inventaire des intégrations et APIs tierces
Réduire la profondeur de la chaîne
Section intitulée « Réduire la profondeur de la chaîne »Moins de maillons = moins de risques :
| Action | Impact |
|---|---|
| Réduire le nombre de dépendances | Moins de code tiers |
| Préférer les dépendances sans sous-dépendances | Chaîne plus courte |
| Internaliser les fonctions critiques | Contrôle total |
| Consolider les fournisseurs | Moins de tiers |
Vérifier chaque maillon
Section intitulée « Vérifier chaque maillon »Ne pas faire confiance aveuglément :
- Code : audit des dépendances critiques, analyse statique
- Packages : signatures, checksums, provenance
- Fournisseurs : certifications, audits, SLAs
- Images : scan de vulnérabilités, images signées
Isoler les chaînes de confiance
Section intitulée « Isoler les chaînes de confiance »Limiter la propagation en cas de compromission :
- Segmentation réseau entre les systèmes
- Comptes de service distincts par intégration
- Données séparées par niveau de sensibilité
- Environnements isolés (dev/staging/prod)
Surveiller les changements
Section intitulée « Surveiller les changements »La confiance n’est pas statique :
- Alertes sur les nouvelles dépendances transitives
- Monitoring des changements de mainteneurs
- Veille sur les incidents des fournisseurs
- Revue régulière des chaînes de confiance
Pièges courants
Section intitulée « Pièges courants »La confiance par popularité
Section intitulée « La confiance par popularité »Un package populaire n’est pas forcément sûr. event-stream avait des millions
de téléchargements quand il a été compromis. La popularité attire aussi les
attaquants.
La confiance par certification
Section intitulée « La confiance par certification »Une certification (ISO, SOC2) couvre un périmètre défini à un instant donné. Elle ne garantit pas la sécurité des sous-traitants ni l’absence de failles.
La confiance figée
Section intitulée « La confiance figée »Faire confiance une fois et ne jamais réévaluer. Les mainteneurs changent, les entreprises sont rachetées, les contextes évoluent.
L’ignorance des transitives
Section intitulée « L’ignorance des transitives »Se concentrer uniquement sur les dépendances directes et ignorer les transitives. C’est souvent dans les profondeurs que se cachent les failles.
La confiance par défaut
Section intitulée « La confiance par défaut »Accepter les configurations par défaut qui font confiance à des sources externes (registries publics, CDN, analytics).
À retenir
Section intitulée « À retenir »-
La confiance se propage automatiquement — faire confiance à A signifie faire confiance à toute la chaîne derrière A.
-
Cartographiez vos chaînes de confiance — vous ne pouvez pas sécuriser ce que vous ne connaissez pas. Inventoriez dépendances et fournisseurs.
-
Les dépendances transitives sont le maillon faible — une application moyenne hérite de centaines de dépendances qu’elle ne connaît pas.
-
Vérifiez, ne faites pas confiance — signatures, audits, checksums. La popularité ou la certification ne suffisent pas.
-
Isolez les chaînes — si un maillon est compromis, limitez la propagation par la segmentation et la séparation des privilèges.
-
La confiance évolue — réévaluez régulièrement. Un tiers de confiance aujourd’hui peut être compromis demain.
Liens utiles
Section intitulée « Liens utiles »- Défense en profondeur — Plusieurs couches pour limiter l’impact d’une chaîne compromise
- Zero Trust — Ne jamais faire confiance par défaut, même aux entités “internes”
- Moindre privilège — Limiter les droits accordés à chaque maillon de la chaîne
- Dette de sécurité — Les dépendances obsolètes accumulent la dette transitive
- Open Source Malware — Base de données communautaire des packages malveillants (npm, PyPI, NuGet)