GitHub et PyPI : 3 jours pour stopper les paquets malveillants

Imaginez que votre équipe de développement installe un outil courant pour accélérer un projet. Sans le savoir, elle vient d'introduire un logiciel espion dans votre système d'information. Ce scénario, appelé supply chain attack, est l'une des menaces qui progressent le plus vite contre les PME. Bonne nouvelle : GitHub et PyPI, deux des plateformes les plus utilisées pour partager du code, viennent d'annoncer un mécanisme simple mais efficace pour le contrer. Un délai obligatoire de 72 heures avant qu'un nouveau paquet logiciel soit accessible au public. Voici pourquoi c'est important pour vous, et ce que vous devez demander à vos développeurs dès cette semaine.

C'est quoi un « paquet empoisonné » et pourquoi votre PME est concernée

Quand vos développeurs construisent une application ou un site web, ils n'écrivent pas tout le code eux-mêmes. Ils s'appuient sur des briques logicielles toutes faites, appelées paquets ou dépendances, téléchargées depuis des plateformes comme GitHub, PyPI (pour le langage Python) ou npm. C'est une pratique normale qui fait gagner un temps précieux. Le problème : des cybercriminels publient des paquets qui imitent des outils légitimes, avec un nom quasi identique ou en prenant le contrôle d'un compte de développeur connu. Une fois installé, ce paquet npm malveillant ou Python peut voler des mots de passe, chiffrer vos données pour demander une rançon, ou ouvrir une porte dérobée dans votre réseau. Ces attaques de type supply chain attack PME sont particulièrement redoutables car elles passent sous les radars des antivirus classiques : le logiciel malveillant entre déguisé en outil de travail ordinaire. Et contrairement aux grandes entreprises, les PME disposent rarement d'une équipe dédiée pour surveiller chaque dépendance installée.

Le délai de 72 heures : une barrière simple qui change tout

Le principe annoncé par GitHub et PyPI est volontairement sobre : avant qu'un paquet nouvellement publié soit disponible pour tout le monde, une fenêtre de 72 heures s'écoule obligatoirement. Durant ce délai, des systèmes automatisés analysent le code à la recherche de comportements suspects, et la communauté peut signaler d'éventuelles anomalies. Concrètement, cela crée un filet de sécurité là où il n'en existait pas. Jusqu'ici, un paquet malveillant pouvait être téléchargé des milliers de fois en quelques heures, avant même qu'un humain ait eu le temps de réagir. Les attaques les plus dévastatrices de ces dernières années, comme celle contre SolarWinds ou l'incident XZ Utils en 2024, ont justement exploité cette vitesse de propagation. Ce délai ne résout pas tout, mais il réduit drastiquement la fenêtre d'opportunité pour les attaquants. Pour votre PME, cela signifie que vos développeurs ont moins de chances de tomber sur un paquet piégé dans les premières heures suivant sa mise en ligne, période la plus dangereuse.

Dependabot et les outils existants : ils sont inutiles sans une bonne hygiène

GitHub propose depuis quelques années un outil gratuit appelé Dependabot sécurité. Son rôle : surveiller automatiquement les dépendances de vos projets et vous alerter dès qu'une vulnérabilité connue est détectée dans un paquet que vous utilisez. C'est un excellent point de départ, mais il ne sert à rien s'il est ignoré ou mal configuré. Beaucoup de PME ont Dependabot activé sur leurs dépôts GitHub sans que personne ne lise les alertes. Les notifications s'accumulent, les mises à jour sont repoussées, et une faille découverte il y a six mois reste ouverte. Le nouveau délai de 72 heures vient compléter Dependabot, pas le remplacer. Ensemble, ils forment une première ligne de défense accessible même sans expert en sécurité à temps plein. Mais cette défense ne tient que si quelqu'un dans votre équipe a la responsabilité explicite de vérifier ces alertes régulièrement, au minimum une fois par semaine.

Ce que vous pouvez faire dès maintenant

1. Demandez à vos développeurs si Dependabot est activé sur tous vos projets GitHub. Si ce n'est pas le cas, c'est une action de 5 minutes qui peut vous éviter une catastrophe.

2. Désignez un responsable des alertes de sécurité. Quelqu'un doit avoir pour mission de consulter et traiter les notifications Dependabot chaque semaine. Sans nom et sans date, cela ne se fait jamais.

3. Exigez un inventaire des dépendances critiques. Demandez à votre équipe de lister les 10 paquets les plus utilisés dans vos projets principaux. Savoir ce qui tourne dans votre SI est la base de tout.

4. Instaurez une règle simple : aucun paquet publié depuis moins de 72 heures ne doit être intégré en production sans validation explicite. Cette règle s'aligne avec le nouveau mécanisme de GitHub et PyPI, et coûte zéro euro à mettre en place.

5. Sensibilisez vos développeurs aux supply chain attacks PME lors de votre prochaine réunion d'équipe. Montrez-leur cet article. Une attaque réussie via un paquet npm malveillant peut paralyser votre activité pendant plusieurs jours. Quinze minutes de sensibilisation peuvent suffire à changer les réflexes.