Malware à l'installation : ce que vérifie le pare-feu de GitHub

On imagine souvent une dépendance malveillante comme du code qui fait des dégâts quand l'application l'exécute. GitHub fait remarquer, dans son annonce du 20 octobre 2026, qu'un nombre croissant d'attaques n'attendent pas ce moment : elles agissent pendant l'installation du paquet et récupèrent les identifiants du runner de CI ou du poste du développeur, sans que votre application exécute la moindre ligne du paquet. Quand le premier test démarre, le jeton est déjà parti. La réponse de GitHub est un pare-feu de paquets, en préversion publique, et il vaut la peine de savoir ce qu'il fait comme de mesurer à quel point son périmètre reste étroit aujourd'hui.

Ce que le pare-feu inspecte

Selon la description de GitHub, le pare-feu se place entre vos points de terminaison, c'est-à-dire les runners Actions et les agents de code, et le registre amont, et il examine à la fois les requêtes de métadonnées et les téléchargements de paquets. Les politiques disponibles aujourd'hui : un délai d'attente configurable, une vérification dans la GitHub Advisory Database des alertes de malware et de vulnérabilité, et des contrôles de chaîne d'approvisionnement comme la rétrogradation d'attestation. Chaque point de terminaison doit être configuré pour passer par le pare-feu au lieu du registre, et si un paquet est bloqué à tort, vous pouvez demander une exception.

Ce qu'il ne couvre pas

Soyez précis sur le périmètre avant de construire un plan dessus. GitHub indique que la préversion s'adresse aux clients GitHub Enterprise Cloud, résidence des données comprise, et qu'elle ne prend en charge que les paquets npm pour l'instant. Sur un plan Free ou Team, vous ne l'avez donc pas, et pour un projet PHP, rien de votre installation Composer ne le traverse. Il est gratuit pendant la préversion, et GitHub annonce une facturation à l'usage plus tard, sur un modèle proche de celui d'Actions.

Côté publication, ça s'est durci le même mois

Deux changements npm du 2 octobre poussent depuis l'autre bout. npm stage publish peut maintenant créer un paquet entièrement nouveau : la première version entre dans une file d'attente, et un mainteneur doit la promouvoir avant que quiconque puisse l'installer. Et les configurations de publication de confiance non validées expirent désormais 48 heures après leur création, ce qui limite le risque de faire confiance à un nom de dépôt ou de projet qui change ensuite de propriétaire. Une configuration est validée par sa première publication réussie. npm refuse aussi les jetons de publication de confiance venant des événements de workflow issue_comment, en plus de la restriction existante sur pull_request_target ; npm conseille plutôt push, release ou workflow_dispatch.

Ce que vous pouvez faire sur n'importe quel plan

Cette partie est un conseil général, pas une affirmation sur le pare-feu. Versionnez vos lockfiles et installez à partir d'eux : npm ci côté JavaScript, composer install avec composer.lock côté PHP. Lancez une vérification des alertes en CI. --ignore-scripts saute les scripts de cycle de vie npm, mais ce n'est pas une défense complète, car les attaques à l'installation ne passent pas toutes par des scripts et certains paquets en ont réellement besoin. Un délai d'attente manuel, c'est simplement ne pas passer à une version publiée ces derniers jours, puisque la plupart des versions malveillantes sont repérées vite. Et la couche qui compte le plus : ne lancez pas d'installation sur une machine qui détient des identifiants à longue durée de vie.

npm ci
composer install --no-interaction
composer audit

Ce site tourne sous Laravel avec un peu d'outillage JavaScript, donc le pare-feu n'en couvrirait jamais que la plus petite moitié. Côté PHP, l'équivalent est simple : installer depuis le composer.lock versionné, lancer composer audit en CI, et ne laisser entrer aucune mise à jour sans que quelqu'un la lise. Si vous êtes sur Enterprise Cloud, dirigez un seul runner vers le pare-feu, observez ce qu'il bloque pendant une semaine, puis élargissez. Source : GitHub Changelog, le pare-feu de paquets en préversion publique.