Paquets PyPI malveillants : sécuriser la supply chain

Un paquet Python peut exécuter du code pendant l’installation, le build, l’import ou l’usage normal. L’écosystème devient donc une cible de supply chain. Les paquets PyPI malveillants volent des secrets, altèrent les builds, posent des backdoors et contactent l’infrastructure adverse sous l’apparence d’une dépendance.

La défense n’est pas de bannir l’open source, mais de contrôler la résolution, vérifier la publication, réduire les privilèges et relier nom du paquet et comportement runtime.

Vecteurs d’attaque courants

• Typosquatting : nom proche d’une dépendance populaire.
• Dependency confusion : un package public supplante un nom interne.
• Compromission mainteneur : un vrai projet publie une version hostile.
• Transfert malveillant : droits de publication cédés à l’attaquant.
• Exécution à l’installation : hooks lisant des secrets.
• Imitation : métadonnées et README copiés.

La popularité ne prouve pas la sécurité et la nouveauté ne prouve pas la malveillance. Il faut croiser provenance et comportement.

Sécuriser la sélection

Utilisez un index ou proxy approuvé, réservez les noms internes et empêchez la résolution publique involontaire. Commitez les lockfiles des applications et vérifiez les hashes lorsque l’outil le permet. Revoyez toute dépendance directe et changement transitif inattendu.

Conservez :

• nom et version exacts ;
• index source et hash ;
• mainteneur et historique ;
• backend de build et hooks ;
• évolution du graphe ;
• vulnérabilités et signalements.

Le guide Python Packaging recommande Trusted Publishing sur les CI/CD compatibles afin de réduire les jetons persistants.

Détecter un comportement d’installation suspect

L’installation ne doit pas disposer de credentials de production. Exécutez-la dans un environnement isolé, éphémère et à sortie réseau limitée. Alertez sur :

• lecture de secrets cloud, package, SSH ou CI ;
• sous-processus depuis un hook de build ;
• connexion à un domaine récent ou mal réputé ;
• téléchargement d’une seconde charge ;
• persistance ou écriture hors du workspace ;
• obfuscation sans lien avec la finalité.

Vérifiez les artefacts par réputation de hash, les destinations par réputation de domaine et les grands ensembles via recherche en masse.

Sécuriser la publication

Imposez une MFA résistante au phishing, des rôles minimaux et des credentials courts. Protégez le workflow de release comme un système de production. Épinglez les actions tierces, revoyez les changements et séparez build et approbation.

Trusted Publishing réduit le risque du jeton long, mais ne garantit ni le code ni l’intégrité du build. Ajoutez attestations et processus contrôlé.

Réponse à incident

Après confirmation :

1. stoppez builds et déploiements ;
2. préservez wheel, source distribution, lockfiles et logs ;
3. identifiez versions et environnements touchés ;
4. collectez processus, fichiers et réseau ;
5. faites tourner les secrets accessibles ;
6. reconstruisez depuis un ensemble sain ;
7. signalez le projet et les IOC.

Recherchez aussi sur les postes développeurs : leurs installs de test accèdent parfois à plus de secrets que la production.

Éviter la sur-réaction

Ne déclarez pas un package malveillant parce qu’il est nouveau, peu documenté ou compilé. Ce sont des facteurs de revue. Distinguez vulnérable, abandonné, suspect et confirmé pour répondre proportionnellement.

Métriques

Suivez packages non approuvés, délai de revue, builds à egress libre, dépendances sans hash, couverture Trusted Publishing, détections avant release et secrets exposés.

Conclusion

La sécurité PyPI repose sur provenance, installation contrôlée et preuves runtime. Adaptez les leçons des paquets npm malveillants au modèle Python. Le nom ouvre l’enquête ; hashes, comportement et infrastructure la concluent.