Support technique
Documentation
Connexion
Nous contacter
Accédez directement au résumé généré par l'IA de cet article de blog 
Principaux enseignements
- PyPI Public vérifie qui a publié un paquet, et non ce que fait ce paquet.
- SecureChain vérifie et reconstruit les paquets avant qu'ils n'arrivent dans votre environnement.
- Les artefacts reconstruits comportent de nouveaux hachages ; il faut donc régénérer les fichiers de dépendances épinglées.
- L'application des correctifs se poursuit après l'installation, sur l'ensemble de l'arborescence des dépendances.
PyPI public vérifie que les fichiers mis en ligne sont authentifiés et autorisés pour le projet, et publie un hachage pour chaque fichier mis en ligne. En revanche, il ne reconstitue pas ces fichiers pour prouver que leur contenu provient bien du dépôt source auquel ils renvoient, ni ne vérifie si le code peut être exécuté en toute sécurité. C'est cette lacune qui pousse généralement les utilisateurs à rechercher une alternative à PyPI : une solution qui évalue ce que fait un paquet plutôt que de se contenter de vérifier d'où il provient.
Cet article explique en détail où SecureChain pour Python effectue des analyses, procède à des recompilations et continue d'appliquer des correctifs après l'installation, ainsi que les limites de cette couverture.
Ce que vérifie Public PyPI, et ce qu'apporte une alternative à PyPI
Lorsque « pip » effectue une installation à partir du dépôt public PyPI, seule une courte liste de vérifications est appliquée, et aucune d'entre elles ne vérifie ce que fera le paquet une fois qu'il sera installé dans votre environnement.
La publication d'une version nécessite un compte de responsable authentifié. Chaque fichier téléchargé se voit attribuer un hachage de publication, et pip vérifie le téléchargement par rapport au hachage fourni par l'index, ce qui permet de détecter un transfert corrompu. Ce hachage accompagne toutefois le fichier depuis sa source d'origine ; il prouve donc que l'artefact est arrivé intact, mais pas que son contenu a été vérifié par quelqu'un. Mode de vérification des hachages c'est l'option la plus stricte, car avec --require-hashes Une valeur de hachage fournie par l'index ne peut pas répondre à cette exigence. L'artefact doit correspondre à une valeur de hachage que vous avez validée localement.
Les responsables de maintenance qui optent pour « Trusted Publishing » reçoivent des identifiants OIDC à durée de vie limitée au lieu d’un jeton API statique, et PyPI peut fournir des attestations numériques qui lient de manière cryptographique un artefact à son identité de publication et, grâce à la provenance SLSA, à son emplacement source. Il s’agit là de signaux de provenance utiles, mais aucun d’entre eux ne permet d’établir que l’artefact lui-même est inoffensif. Une fois qu’un identifiant de publication ou un workflow autorisé est compromis, l’authentification seule ne permet pas de savoir ce qui a été transmis par ce canal, et le processus de signalement et de mise en quarantaine de PyPI intervient généralement une fois qu’une version malveillante est déjà installable, plutôt que de filtrer les artefacts avant leur mise en ligne.
Un miroir PyPI sécurisé qui se contente de rediriger vers une autre source de téléchargement des paquets présente le même point faible. Ce problème n’est pas non plus spécifique à Python. Il s’agit d’un angle mort que de nombreux outils de chaîne d’approvisionnement ne parviennent jamais à combler: un paquet est évalué par rapport à un hachage et à un flux CVE, mais jamais par rapport à ce qu’il fait réellement lorsqu’il s’exécute.
Un dépistage avant l'accouchement, et non après
SecureChain analyse le code source d’un paquet avant même qu’il ne soit transmis à un agent de compilation ou à une machine appartenant à un développeur, signalant tout comportement suspect et bloquant tout élément qui ne passe pas l’inspection. Il s’agit d’une étape du pipeline différente de celle à laquelle interviennent la plupart des outils. Un scanner qui ne détecte une dépendance qu’après sa résolution ou son installation ne fait que signaler quelque chose qui existe déjà dans l’environnement. Effectuer un filtrage avant la transmission signifie qu’un paquet qui échoue à l’inspection n’atteint jamais l’environnement utilisateur.
Trois incidents survenus en 2026 montrent pourquoi ce timing est important. LiteLLM a diffusé un programme de vol d'identifiants en mars après qu’une version corrompue de Trivy, intégrée à son propre pipeline de CI, a divulgué le jeton PyPI du projet. En mai, tâche durable, le SDK Durable Task de Microsoft, a été compromis via un jeton d'API extrait des secrets de GitHub Actions. Et en juin, Hades est désormais disponible sur PyPI avec 37 artefacts Wheel malveillants, recensés comme 26 paquets par Orca et 19 par Socket. Ces fichiers Wheel utilisaient .pth des hooks de démarrage qui se déclenchent au lancement de l'interpréteur plutôt qu'au moment de l'importation, la même astuce qu'avait utilisée l'une des versions malveillantes de LiteLLM trois mois plus tôt.
Aucun des trois n’avait besoin d’un bug dans l’application utilisant le paquet. Chacun a suivi une voie de publication autorisée, et l’authentification permet de confirmer qu’une voie est autorisée sans pour autant garantir que l’artefact qui en provient soit inoffensif. La même lignée de campagne remonte jusqu’à la propagation de Shai-Hulud sur npm, et c’est justement là où réside tout l’intérêt. C’est ce type de schéma que les contrôles préalables à la livraison sont censés détecter, quel que soit l’écosystème dans lequel il apparaîtra ensuite.
Recompiler à partir du code source, et ce que cela permet réellement de vérifier
La plupart des modules Python s’installent à partir d’artefacts de distribution que PyPI ne recompile pas de manière indépendante pour vérifier leur conformité avec le dépôt source dont ils sont censés provenir. Un fichier « wheel » peut présenter un hachage constant, s’installer sans problème et contenir néanmoins du code que le dépôt associé n’a jamais connu, car rien dans le système de packaging n’oblige un fichier « wheel » à correspondre à sa source.
SecureChain recompile les paquets à partir d'une source vérifiée dans un environnement contrôlé, de sorte que ce qui est installé peut être retracé jusqu'à cette source, et non jusqu'à un binaire en amont opaque. Ce que cette vérification permet de garantir dépend du type de paquet.
| Type d'artefact | Contient | Fidélité de la reconstruction |
|---|---|---|
| Wheel Python pur | Fichiers source, sans compilation | Les résultats sont très proches, même si les métadonnées ZIP et les horodatages diffèrent |
| Wheel avec extensions compilées | Fichiers binaires spécifiques à une plateforme, compilés à partir de code en C, C++ ou Rust | Ce n'est pas comparable au niveau de l'octet, car un même code source peut donner lieu à des compilations différentes selon les chaînes d'outils |
| Distribution des sources | Arborescence source, ainsi que les métadonnées de packaging et de compilation | C'est ce à quoi il faut surtout se référer, même si le moteur de compilation peut exécuter du code pendant la compilation |
Un fichier « wheel » Python pur contient le code source Python et les métadonnées de packaging générées, sans binaires compilés ; par conséquent, la comparaison entre une nouvelle compilation et le fichier « wheel » publié se résume essentiellement à une comparaison au niveau des fichiers. Un wheel construit à partir d’extensions en C, C++ ou Rust est un résultat de compilation lié à une chaîne d’outils et à une plate-forme spécifiques ; sa recompilation produit un binaire différent plutôt qu’un binaire identique. Il s’agit là d’une véritable limite, qui s’applique à une part non négligeable des installations effectuées par les équipes chargées des données ou du machine learning. Les distributions de sources se situent entre les deux : bien que moins courantes au quotidien, elles exposent directement le code source et les éléments d’entrée de la compilation, ce qui offre le plus de possibilités pour une recompilation.
En réalité, le cadre de Python est donc hiérarchisé plutôt qu’uniforme. Il est solide pour le Python pur, utile d’un point de vue structurel pour les sdists, et moins fiable pour tout ce qui implique des extensions compilées. Prétendre à une reconstruction « à l’octet près » sur l’ensemble de PyPI reviendrait à surestimer ce que la reconstruction peut apporter dès lors que des sorties compilées ou dépendantes de l’environnement entrent en jeu.
Conséquences de la reconstruction sur vos hachages épinglés
Le « hash pinning » limite chaque dépendance à un ou plusieurs hachages d'artefacts explicitement approuvés.
pip-compile --generate-hashes requirements.in
pip install --require-hashes -r requirements.txtCes hachages sont associés à des fichiers spécifiques. Étant donné que SecureChain recompile les paquets à partir du code source plutôt que de redistribué l'artefact d'origine de PyPI, un paquet recompilé génère un hachage différent de celui publié par PyPI, même lorsque le code source sous-jacent correspond exactement. Le changement implique donc une véritable étape de migration, car chaque « pin » couvrant un paquet recompilé par SecureChain doit être régénéré en fonction du nouvel index.
Prévoyez cela avant le lancement d'un projet pilote, plutôt que pendant celui-ci. Commencez par régénérer les fichiers d'exigences en fonction du nouvel index dans un référentiel unique, vérifiez que l'installation s'effectue correctement et que l'application se comporte de la même manière, puis déterminez l'étendue du déploiement en fonction du nombre de référentiels et de pipelines qui utilisent actuellement des hachages verrouillés. C'est la taille de cette liste, et non le concept de verrouillage des hachages, qui détermine l'ampleur réelle de la migration.
Une seule URL d'index, pas deux
Pour configurer Pip sur SecureChain, il suffit d'effectuer un seul réglage, en utilisant le point de terminaison fourni par SecureChain pour votre compte :
pip config set global.index-url https://<your-securechain-endpoint>/simple/Utilisation index-url, et non extra-index-url. pip ne tient pas compte de l'index d'où provient un paquet. Si les deux index proposent des candidats compatibles pour le même nom de paquet, pip les évalue conjointement et peut choisir le candidat public dont la version est la plus récente, ce qui représente précisément le risque de confusion entre les dépendances --extra-index-url crée.
Vérifiez ce qui est réellement configuré sur un runner CI plutôt que de vous fier aveuglément à la documentation. PIP_INDEX_URL et PIP_EXTRA_INDEX_URL définir dans l'environnement, remplacer en silence pip.conf, et une image de base héritée d'une autre équipe est souvent le moyen par lequel l'une d'entre elles se glisse dans le projet sans que personne ne s'en aperçoive.
pip config list
pip config get global.index-urlCorrectifs appliqués après l'installation, et pas seulement vérifiés avant celle-ci
La vérification porte sur l'état d'un paquet au moment de sa livraison. La majeure partie du cycle de vie d'une dépendance se déroule après cela, et le fait de constater a posteriori qu'il y a un problème est une tâche distincte de celle consistant à disposer d'une version corrigée de celle que vous utilisez réellement.
Un seul paquet de niveau supérieur peut entraîner des dizaines de dépendances transitives via le résolveur de pip, dont la plupart n’ont été examinées directement par aucun membre de l’équipe, et dont chacune peut introduire du code exécutable et de nouvelles vulnérabilités dans l’environnement. SecureChain applique les mêmes procédures de vérification, de filtrage et d’application de correctifs à l’ensemble du graphe de dépendances, et pas seulement à ce qui apparaît dans requirements.txt.
De nouvelles vulnérabilités CVE sont divulguées concernant des paquets déjà présents dans un environnement de production, selon un calendrier que personne ne contrôle. De nombreux outils vous en informent. SecureChain surveille ces divulgations et fournit des correctifs adaptés aux versions déjà fixées, ce que la sortie de `pip-audit` et l'examen manuel des avis de sécurité ne prennent pas en charge.
À un moment donné, un responsable de maintenance cesse de publier de nouvelles versions. Le référentiel public PyPI continue d’héberger les versions existantes, mais aucune nouvelle correction n’est appliquée à partir de ce moment-là, quelles que soient les failles découvertes par la suite. Le service « Endless Lifecycle Support » de TuxCare vient ici en renfort à SecureChain en rétroportant les correctifs pour les paquets déjà présents dans le catalogue, ce qui évite à une équipe d’avoir à choisir entre une dépendance non corrigée et une réécriture que personne n’avait prévue.
Comparaison de SecureChain avec votre propre pile Python
Générez votre propre arborescence de dépendances, déterminez la part de Python « pur » par rapport à celle des extensions compilées, et vérifiez combien de dépôts fonctionnent déjà en mode de vérification des hachages. C'est là que réside la véritable portée du passage à SecureChain pour Python pour votre pile technologique, et non une estimation générique.
Pour évaluer SecureChain en tant qu’outil de sécurité des paquets Python, il s’agit avant tout de comparer ces caractéristiques à votre propre pipeline plutôt qu’à une simple fiche technique. Si les lacunes évoquées ici correspondent à ce que votre dernière analyse d’incident a mis en évidence, demandez un devis pour SecureChain pour Python et obtenez une réponse claire sur la couverture du catalogue pour votre arborescence de dépendances.
FAQ
Qu'est-ce qu'une alternative à PyPI ?
Un index qui met les paquets Python à la disposition des développeurs et des systèmes de compilation, sans passer directement par le PyPI public. Certaines options se contentent de reproduire ou de mettre en cache les paquets en amont, tandis que d'autres ajoutent des contrôles tels que la vérification et la recompilation, ce qui comble les lacunes laissées par la simple mise en miroir.
La commande « pip install » peut-elle exécuter du code malveillant ?
Oui. L'installation d'une distribution source permet d'exécuter du code de fond de compilation géré par les paquets pendant la compilation de ceux-ci, et un paquet installé peut exécuter du code ultérieurement, au moment de son importation ou via des mécanismes de démarrage tels qu'un exécutable. .pth fichier, c'est précisément ce qu'exploitaient les roues d'Hadès. SecureChain analyse le code source d'un paquet avant sa livraison, signale les comportements suspects et bloque les paquets malveillants avant qu'ils n'atteignent un environnement.
Un paquet recompilé correspond-il toujours à sa source en amont ?
Cela dépend du type de paquet. Les « wheels » Python purs ne contiennent aucun binaire compilé ; ainsi, une nouvelle compilation peut être comparée assez directement au « wheel » publié, au niveau des fichiers. Les « wheels » comportant des extensions compilées en C, C++ ou Rust constituent des résultats de compilation spécifiques à la plateforme, et leur recompilation produit un binaire différent plutôt qu’un binaire identique, même lorsque le code source est identique.
Le passage à SecureChain va-t-il compromettre mes hachages épinglés ?
Oui, pour tout paquet, il procède à une nouvelle compilation. SecureChain met à disposition les paquets recompilés plutôt que de redistribué l'artefact d'origine de PyPI ; par conséquent, les hachages diffèrent de ceux publiés par PyPI, même lorsque le code source est identique. La régénération des fichiers de dépendances épinglées constitue une étape réelle de la migration, et non un cas marginal.
SecureChain prend-il en charge les dépendances transitives, et pas seulement celles qui figurent dans le fichier requirements.txt ?
Oui. Une seule dépendance directe peut entraîner l'installation de dizaines de paquets que personne n'a examinés directement, et ces paquets peuvent introduire du code exécutable et des vulnérabilités dans l'environnement. SecureChain applique des processus de vérification, de filtrage et d'application de correctifs à l'ensemble du graphe de dépendances, et non pas uniquement aux paquets de niveau supérieur répertoriés par une équipe.
Que se passe-t-il lorsqu'un module Python arrive en fin de vie ?
Rien, et c’est là le problème. Le PyPI public ne supprime pas le paquet ni ne le signale comme n’étant plus pris en charge, et les anciennes versions restent généralement téléchargeables, à moins qu’elles ne soient retirées ou mises en quarantaine pour une autre raison. Ce qui s’arrête, c’est l’activité en amont : les responsables cessent de produire des correctifs de sécurité pour le paquet dès qu’ils se désengagent. SecureChain continue quant à lui à corriger les paquets répertoriés au-delà de ce stade ; ainsi, lorsqu’un paquet arrive en fin de vie, cela ne signifie pas automatiquement qu’il reste vulnérable ou qu’il faille se démener pour le remplacer.
