GitHub prend des mesures pour éviter que les pires cyberattaques de ces dernières années ne se répètent
Trois jours d'attente chez GitHub, deux semaines de verrou chez PyPI : les plateformes qui distribuent le code du monde entier découvrent les vertus de la lenteur. La quarantaine ne soigne pas tout, mais elle évite bien des contagions.
Trois jours d'attente chez GitHub, deux semaines de verrou chez PyPI : les plateformes qui distribuent le code du monde entier découvrent les vertus de la lenteur. La quarantaine ne soigne pas tout, mais elle évite bien des contagions.
Huit ans d'attaques contre les dépôts de code ont fini par imposer une évidence : la vitesse d'adoption des mises à jour est devenue une surface d'attaque à part entière. GitHub et PyPI viennent d'en tirer la même conclusion, chacun à sa manière. Le premier a justifié cette semaine, dans un billet publié sur son blog, le délai de trois jours désormais appliqué par défaut à son service Dependabot ; le second a annoncé refuser tout ajout de fichier à une version publiée depuis plus de deux semaines.
Trois jours chez GitHub, quatorze chez PyPI
Dependabot, pour resituer, est ce service qui surveille les dépendances d'un projet et propose automatiquement les montées de version. Depuis le 14 juillet, il attend trois jours après la parution d'une nouvelle version avant d'ouvrir sa proposition, un réglage devenu la norme après un an d'existence en option. La nuance qui compte : ce délai ne concerne que les mises à jour de version. Les correctifs de sécurité, eux, continuent de passer immédiatement, personne n'attendra donc trois jours pour colmater une faille documentée. Le curseur reste par ailleurs ajustable projet par projet, dans un sens comme dans l'autre.
PyPI, le grand dépôt des paquets Python, choisit une serrure plutôt qu'un sas. Passé quatorze jours, plus aucun fichier ne peut rejoindre une version déjà publiée. La cible : l'empoisonnement de versions anciennes et réputées sûres par un attaquant qui aurait volé un jeton de publication ou compromis une chaîne de livraison. La plateforme reconnaît d'ailleurs qu'aucune attaque connue n'a encore emprunté cette voie précise (fermer la porte avant qu'on ne la pousse, voilà qui change des habitudes du secteur) et précise qu'une part infime de projets ajoute légitimement des fichiers au-delà de deux semaines.
18 paquets malveillants par jour, l'échelle qui a tranché
Le raisonnement de GitHub s'appuie sur une revue de 21 incidents survenus entre 2018 et 2026, avec un constat récurrent. Les versions piégées d'axios, de Solana web3.js, d'ua-parser-js ou du kit de connexion Ledger ont toutes été retirées en quelques heures. Un délai de trois jours aurait donc filtré l'essentiel de ces publications éphémères avant qu'elles n'atteignent le moindre projet. S'ajoute l'argument du volume : la base d'avis de sécurité de GitHub a recensé plus de 6 500 paquets npm malveillants sur l'année close en mai, contre environ 6 200 un an plus tôt. Dix-huit signalements par jour, en moyenne.
Le principe rappelle la quarantaine des ports d'autrefois : on laisse le navire au mouillage quelques jours, le temps que la fièvre se déclare (les Vénitiens comptaient quarante jours, les développeurs se contenteront de trois). GitHub liste lui-même les limites de son sas : il ne peut rien contre une porte dérobée dormante, un mainteneur qui sabote son propre paquet ou une chaîne de compilation compromise. Le code de certains de ces scénarios circulait d'ailleurs en libre accès. D'où ses recommandations complémentaires, fichiers de verrouillage et jetons à portée restreinte en tête, pendant que les faux dépôts piégés continuent de proliférer. Le mouvement dépasse d'ailleurs ces deux acteurs : npm a verrouillé ses scripts d'installation en juin, après pnpm, et la latence volontaire s'installe partout comme réglage de sécurité.