GitHub et PyPI ajoutent des défenses par délai temporel contre les attaques sur la chaîne d'approvisionnement

GitHub et le Python Package Index (PyPI) ont chacun introduit cette semaine des défenses basées sur le temps, destinées à ralentir les attaques sur la chaîne d’approvisionnement qui exploitent la rapidité des mises à jour automatiques de dépendances. Le Dependabot de GitHub retarde désormais l’adoption de nouvelles versions de packages de 72 heures par défaut, tandis que PyPI a commencé à refuser les téléversements de fichiers pour les releases vieilles de plus de 14 jours.

Ces deux changements ciblent la même faiblesse sous-jacente : les outils de sécurité peuvent signaler un package malveillant en quelques minutes après sa publication, mais la détection seule ne supprime pas la menace. Les mainteneurs doivent encore agir sur l’alerte, et entre-temps, des outils automatisés comme Dependabot peuvent intégrer le package compromis en production avant que quiconque ne s’en aperçoive.

Pourquoi maintenant

Ces mesures font suite à une série d’incidents très médiatisés sur les deux écosystèmes l’année dernière, notamment les détournements des packages npm « chalk » et « debug » — qui ont ensemble affecté des packages cumulant 2 milliards de téléchargements hebdomadaires —, la campagne de malware s1ngularity pilotée par IA qui a touché 2 180 comptes GitHub, l’attaque Shai-Hulud qui a expédié des packages signés malveillants déguisés en bibliothèques TanStack et Mistral, et la campagne GhostAction qui a forcé PyPI à invalider des tokens de publication volés. GitHub avait déjà annoncé le mois dernier un ensemble plus large de changements de sécurité pour npm ; le délai de refroidissement de Dependabot étend cet effort de durcissement.

Comment fonctionnent les défenses

Le nouveau délai de refroidissement de 72 heures de Dependabot retarde les Pull Requests qu’il ouvre pour les nouvelles versions de dépendances, laissant à la communauté de sécurité le temps de détecter et de signaler les versions malveillantes avant que les outils automatisés ne les adoptent. GitHub a déclaré que trois jours ont été choisis comme équilibre entre sécurité et maintien à jour avec les mises à jour légitimes, et ce délai est configurable — les mainteneurs peuvent le raccourcir ou le rallonger. GitHub a également recommandé d’associer ce délai de refroidissement avec des lockfiles pour le verrouillage des dépendances, des tokens de publication à portée restreinte, et la désactivation des scripts d’installation inutiles dans les pipelines CI/CD, car le délai seul ne protège pas contre une compromission de compte à long terme.

Le changement de PyPI cible un schéma d’attaque différent : un attaquant qui compromet le token de publication ou le workflow CI/CD d’un mainteneur longtemps après qu’une version de package a été expédiée et a gagné la confiance des développeurs. En bloquant les téléversements de fichiers pour toute release vieille de plus de 14 jours, PyPI ferme la fenêtre pour ce type d’« empoisonnement de release », où une version déjà adoptée et de confiance est modifiée silencieusement après coup. PyPI a noté qu’aucune attaque passée confirmée n’a utilisé cette technique spécifique — la plateforme agit de manière préventive, ayant constaté que seule une petite fraction des projets téléversent légitimement des fichiers plus de deux semaines après une release.

Ce que cela signifie pour les développeurs

Pour la plupart des projets, l’effet pratique est un court délai avant que les PR de dépendances automatisées n’apparaissent, et l’impossibilité de corriger d’anciennes releases de packages après deux semaines. Aucun des deux changements ne nécessite d’action de la part du développeur pour en bénéficier — les deux sont activés par défaut au niveau de la plateforme —, bien que les mainteneurs ayant des workflows de release inhabituels puissent avoir besoin d’ajuster le paramètre de délai de refroidissement de Dependabot si la valeur par défaut de 72 heures entre en conflit avec leur cadence de mise à jour, comme l’a rapporté en premier BleepingComputer.