Confiance transitive : la propagation silencieuse des risques

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

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

Erreur fréquente

Penser que la confiance est binaire (oui/non) plutôt que contextuelle. Faire confiance à une entité pour une tâche précise ne signifie pas lui faire confiance pour tout.

Le mécanisme de la confiance transitive

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ème

Chaque flèche représente une relation de confiance. Chaque maillon peut être compromis.

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

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

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

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 physique

Une 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

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

Les images de conteneurs héritent de toute leur chaîne :

FROM ubuntu:22.04           # Confiance à Canonical
RUN apt-get install nginx   # Confiance aux mainteneurs des packages
COPY app /app               # Votre code

Vous 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

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 :

1. 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)
2. Il publie une version mineure avec du code malveillant
3. Les mises à jour automatiques (^1.2.0) tirent la nouvelle version
4. Le code malveillant s’exécute dans le CI/CD de l’équipe
5. 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

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 provider

L’attaque :

1. L’outil de monitoring du SaaS est compromis
2. L’attaquant accède aux logs qui contiennent des données métier
3. Il utilise ces données pour du phishing ciblé
4. 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

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 graph

Pour 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

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

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

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

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

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

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

Faire confiance une fois et ne jamais réévaluer. Les mainteneurs changent, les entreprises sont rachetées, les contextes évoluent.

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

Accepter les configurations par défaut qui font confiance à des sources externes (registries publics, CDN, analytics).

À retenir

1. La confiance se propage automatiquement — faire confiance à A signifie faire confiance à toute la chaîne derrière A.

2. Cartographiez vos chaînes de confiance — vous ne pouvez pas sécuriser ce que vous ne connaissez pas. Inventoriez dépendances et fournisseurs.

3. Les dépendances transitives sont le maillon faible — une application moyenne hérite de centaines de dépendances qu’elle ne connaît pas.

4. Vérifiez, ne faites pas confiance — signatures, audits, checksums. La popularité ou la certification ne suffisent pas.

5. Isolez les chaînes — si un maillon est compromis, limitez la propagation par la segmentation et la séparation des privilèges.

6. La confiance évolue — réévaluez régulièrement. Un tiers de confiance aujourd’hui peut être compromis demain.

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)