La confiance implicite
Ce que la pipeline accorde sans qu'on le lui demande.
Imaginez donner les clés de votre maison à un inconnu simplement parce qu'il porte un uniforme de livreur. Absurde ? C'est pourtant ce que font la plupart des pipelines : elles exécutent du code externe sans vérifier qui l'a écrit ni ce qu'il fait vraiment.
Trois incidents, un même mécanisme
XZ Utils (février 2024) : un attaquant a passé deux ans à gagner la confiance d'un mainteneur épuisé avant d'injecter une porte dérobée dans une bibliothèque présente sur presque toutes les distributions Linux. Polyfill.io (juin 2024) : un service de diffusion utilisé par plus de cent mille sites a été racheté, puis modifié pour injecter des redirections malveillantes. tj-actions/changed-files (mars 2025) : une action de forge employée par plus de 23 000 projets a été compromise les secrets de milliers de pipelines ont été exfiltrés en quelques heures.
En bref
Chaque élément d'une pipeline représente une décision de confiance. Rendre ces décisions explicites et vérifiables est le premier pas vers une chaîne d'approvisionnement sécurisée.
Ce qu'est la confiance implicite
C'est accorder une autorisation sans l'avoir consciemment décidée : laisser la porte ouverte parce que « le quartier est sûr », jusqu'au jour où quelqu'un entre. Dans une pipeline, elle se manifeste de multiples façons — utiliser une action tierce sans en lire le code, télécharger des dépendances sans vérifier leur intégrité, exécuter des scripts récupérés sur Internet, donner accès aux secrets à toutes les étapes.
Ce qui la rend dangereuse, c'est son invisibilité. Personne n'a pris la décision consciente de faire confiance à ce composant : il est simplement là, hérité d'un tutoriel, copié d'un autre projet, ajouté parce que « ça marchait ».
| Confiance implicite | Confiance explicite |
|---|---|
| « on a toujours utilisé cette action » | « on a audité cette action et accepté ses risques » |
| « ça vient d'un mainteneur connu » | « on vérifie la signature de chaque publication » |
| « c'est populaire, donc c'est sûr » | « on épingle la version et on surveille les changements » |
| « le script est sur notre dépôt interne » | « le script est signé et sa provenance est vérifiable » |
La question à poser pour chaque composant : qui a décidé de lui faire confiance, et sur quels critères ?
Les sept zones de confiance
Pensez à votre pipeline comme à un restaurant : vous faites confiance au chef — votre code — mais aussi aux fournisseurs, au livreur, au moyen de paiement, aux assiettes, aux recettes et au réfrigérateur. Un seul maillon compromis, et tout le repas l'est.
Sept surfaces distinctes : chacune est une décision de confiance, prise ou subie.
| Zone | Ce qui s'y joue |
|---|---|
| Dépendances | chaque installation télécharge du code qui s'exécute chez vous que se passe-t-il si le mainteneur perd son compte ? |
| Actions et greffons | ils s'exécutent avec les permissions de la pipeline : une action compromise lit tous les secrets |
| Identités et jetons | un secret volé donne accès à tout ce qu'il permet permissions larges, attaquant large |
| Artefacts produits | si la pipeline est compromise, les artefacts le sont aussi — sans signature, impossible de les distinguer |
| Scripts et configurations | moins revus que le code applicatif, ils peuvent désactiver des contrôles ou créer des accès persistants |
| Cache | un cache compromis réinjecte du code malveillant à chaque construction, même après correction de la source |
| Services externes | charger des ressources depuis un service tiers, c'est dépendre de sa sécurité |
Une action compromise peut lire les secrets, modifier le code, publier des artefacts malveillants et exfiltrer des données.
Pourquoi la confiance aveugle persiste
Malgré les incidents répétés, la confiance implicite reste la norme. Plusieurs biais cognitifs l'expliquent.
| Biais | Ce qu'on se dit | La réalité |
|---|---|---|
| Automatisation | « c'est automatisé, donc fiable » | l'automatisation exécute aveuglément, y compris du code malveillant |
| Familiarité | « on a toujours fait comme ça » | l'absence d'incident passé ne garantit rien |
| Illusion de contrôle | « le code est ouvert » | qui lit vraiment chaque dépendance ? |
| Popularité | « des millions l'utilisent » | plus c'est populaire, plus l'impact est massif |
| Pression du temps | « on vérifiera plus tard » | « plus tard » devient « jamais » |
Cinq raisonnements confortables — et cinq façons de ne pas décider.
L'anatomie d'une attaque
L'affaire XZ Utils est un cas d'école. Une attaque de chaîne d'approvisionnement se déroule en cinq phases, et sa caractéristique première est la patience.
| Phase | Ce que fait l'attaquant |
|---|---|
| 1. Identification | repérer un composant largement utilisé mais peu surveillé : mainteneur seul, projet utilitaire, peu de revue |
| 2. Infiltration | gagner la confiance pendant des mois par des contributions utiles, ou compromettre un compte existant |
| 3. Injection | injecter le code malveillant, noyé dans un gros commit, obfusqué, ou conditionnel — actif seulement en intégration ou en production |
| 4. Propagation | le composant est téléchargé automatiquement par tous les projets dépendants les pipelines accélèrent la diffusion |
| 5. Exploitation | exfiltration de secrets, portes dérobées dans les artefacts, déplacement latéral, persistance |
La cible idéale : un mainteneur unique ou épuisé, un projet utilitaire, des permissions élevées, peu de revue.
Les principes de la confiance explicite
Vérifier plutôt que supposer
Trois questions pour chaque composant externe : est-il signé par son auteur légitime ? Peut-on tracer sa provenance jusqu'au code source ? Son intégrité est-elle garantie depuis sa création ? Le chapitre donne les outils correspondants.
Minimiser les permissions
Chaque étape ne devrait avoir accès qu'à ce dont elle a strictement besoin. Un job de test n'a pas besoin des secrets de production une action de formatage n'a pas besoin d'écrire sur le dépôt.
Épingler les versions
Utiliser latest ou un tag majeur, c'est accepter à l'avance tout
changement futur.
{Le tag exprime une intention l'empreinte désigne un contenu.}
# À ÉVITER : confiance implicite
uses: actions/checkout@v4
# CORRECT : confiance explicite
uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1Surveiller et documenter
Un audit initial ne suffit pas : les dépendances évoluent. Il faut être alerté des nouvelles versions, revoir les changements avant mise à jour, et détecter les comportements anormaux. Enfin, quand l'équipe décide de faire confiance à un composant, cette décision se documente : pourquoi celui-ci ? quelles alternatives ont été considérées ? quels risques ont été acceptés ? qui en assure la surveillance ?
À retenir de cette séance
La confiance implicite est invisible : personne n'a consciemment décidé de l'accorder. Sept zones de confiance existent dans une pipeline — dépendances, actions, identités, artefacts, scripts, cache, services externes. Les biais cognitifs nous piègent : automatisation, familiarité, popularité, pression du temps. Les attaques de chaîne d'approvisionnement sont patientes. Et la confiance explicite repose sur cinq gestes : vérification, permissions minimales, épinglage, surveillance, documentation.
Réponse unique
Qu'est-ce qui rend la confiance implicite si difficile à traiter ?
Indice · Peut-on réexaminer une décision qui n'a jamais été prise ?
[ METTRE EN PRATIQUE ]
Énumérer ses zones de confiance
3 étapes · 30 min · 120 XP
[ CETTE LEÇON DANS LES PARCOURS ]
- Cybersécuritéétape 11 / 13suivant — Bloquer n'est pas sécuriser →