Attaque supply chain sur un logiciel de paie : se protéger

Pourquoi un logiciel de paie est une cible de choix

Une seule base de paie suffit pour de l’usurpation d’identité à grande échelle ou des fraudes au virement. Mais une application bien protégée résiste aux attaques directes. Une dépendance, elle, s’exécute à l’intérieur, sans authentification, avec accès à tout ce que le processus voit : variables d’environnement, fichiers de configuration, réseau interne.

Une application Node, PHP ou Python moderne embarque des centaines de dépendances transitives. Vous n’en avez choisi qu’une petite partie.

Les quatre vecteurs à connaître

1. Le package légitime compromis

L’attaquant prend le contrôle du compte d’un mainteneur (phishing, mot de passe réutilisé, jeton de publication volé) ou se fait confier la maintenance d’un projet abandonné, puis publie une version piégée. Le cas d’école est event-stream en 2018 : un nouveau mainteneur a ajouté une dépendance, flatmap-stream, qui visait les portefeuilles d’une application bitcoin précise. La porte dérobée d’xz-utils en 2024 a montré la même logique sur plusieurs années, au niveau du système.

2. Le typosquatting

Un package au nom presque identique à une dépendance populaire (une lettre inversée, un tiret en plus, un préfixe crédible) attend une faute de frappe dans un npm install ou un pip install. Le script d’installation s’exécute immédiatement.

3. La dependency confusion

Vos packages internes portent des noms qui fuient (fichiers lock publiés, messages d’erreur, offres d’emploi). Un attaquant publie un package du même nom sur le registre public avec un numéro de version plus élevé. Un gestionnaire mal configuré préfère la version publique. La technique a été démontrée publiquement en 2021 contre de nombreuses grandes entreprises.

4. La chaîne de build

Une GitHub Action tierce référencée par une étiquette mobile (@v3) peut être modifiée après coup. Si votre workflow lui donne accès aux secrets de déploiement, elle les lit. Même risque avec une image Docker de base non épinglée.

Pour un panorama par écosystème, voir notre article sur les attaques npm, Composer et pip.

Ce que l’attaquant récupère concrètement

Le code piégé s’exécute rarement « en production » au sens où vous l’imaginez. Il s’exécute :

• à l’installation (postinstall npm, setup.py), donc sur les postes des développeurs et dans la CI ;
• au build, là où se trouvent les secrets de déploiement ;
• au runtime, avec l’accès à DATABASE_URL, aux clés du prestataire de paiement, au service de stockage des bulletins.

Une clé de base de données ou un compte de service cloud suffit ensuite pour lire toute la base, sans plus jamais passer par l’application.

Comment le tester

1. Inventaire : générez la liste complète des dépendances, transitives comprises (npm ls --all, composer show -t, pip freeze ou un SBOM CycloneDX). Comptez-les.
2. Lock files : vérifiez que chaque dépôt a un fichier lock versionné et que la CI installe en mode strict (npm ci, composer install sans update, pip install --require-hashes).
3. Scripts d’installation : listez les packages qui déclarent des scripts preinstall ou postinstall. Chacun mérite une justification.
4. Noms internes : pour chaque package privé, cherchez s’il existe un package du même nom sur le registre public. Vérifiez que votre configuration force le registre privé pour votre scope.
5. CI/CD : relisez vos workflows. Toute action tierce doit être épinglée par hash de commit. Vérifiez quels secrets chaque job reçoit réellement.
6. Secrets accessibles : depuis un conteneur de production, listez les variables d’environnement. Tout secret présent est lisible par n’importe quelle dépendance. Vérifiez aussi l’historique Git.
7. Sortie réseau : vérifiez si vos serveurs peuvent joindre n’importe quelle adresse Internet. Une exfiltration a besoin d’une sortie.

Comment corriger

• Verrouiller : fichiers lock, installation stricte, mises à jour revues en pull request (Dependabot ou Renovate, jamais en automatique sur la branche principale).
• Réduire : supprimer les dépendances inutiles. Chacune est du code tiers exécuté avec vos droits.
• Désactiver les scripts d’installation par défaut (npm config set ignore-scripts true) et les autoriser au cas par cas.
• Cloisonner les secrets : la CI de test n’a pas besoin des clés de production. En production, préférez des identités de charge de travail à courte durée aux clés statiques.
• Filtrer la sortie réseau des serveurs applicatifs vers une liste d’hôtes autorisés.
• Séparer le site vitrine et l’application : un plugin WordPress compromis ne doit donner aucun chemin vers la base de paie.
• Préparer la réponse : savoir en quelques heures quelles versions ont tourné où, et quels secrets étaient exposés, pour les révoquer et délimiter la notification à la CNIL.

Ce que ça change quand un agent IA entre dans la chaîne

Les agents IA ajoutent une nouvelle catégorie de dépendances : les serveurs MCP, les plugins et les outils qu’ils chargent. Un serveur MCP installé depuis npm s’exécute avec les droits de l’agent et voit ce qu’il voit. L’épisode du ver npm et du faux serveur postmark-mcp a montré qu’un outil d’apparence anodine pouvait copier en silence les e-mails envoyés par l’agent.

Les mêmes règles s’appliquent : épingler les versions des serveurs MCP, lire leur code avant installation, ne leur donner que les secrets nécessaires, et surveiller ce qu’ils envoient vers l’extérieur. Si un agent de votre produit manipule des données de paie avec des outils tiers, le Red Team Agent Express vérifie en cinq jours ce qu’un outil piégé ou une injection pourrait lui faire exfiltrer.