L'Ecosystem Security Team de la PHP Foundation a publié le 19 août 2026 un guide pratique de Sebastian Bergmann qui accompagne les mainteneurs de projets PHP tout au long du cycle de vie d'un rapport de vulnérabilité. Le guide compte dix sections et une antisèche tenant sur un écran ; on saute directement à l'étape en cours.

Le principe central est la divulgation coordonnée : les détails restent privés jusqu'à l'existence d'un correctif. Pas d'issue publique, pas de pull request publique, pas de message de commit du type "fix SQL injection in login handler" et pas de correctif poussé sur une branche publique. Un tel commit constitue déjà la divulgation. En parallèle, il faut accuser réception du rapport en quelques jours, même en une phrase, car le silence transforme les rapporteurs bienveillants en rapporteurs frustrés qui finissent par publier seuls. Un rapport est une affirmation, pas un verdict : le mainteneur décide de la validité, du périmètre et du calendrier. "Works as designed" est une réponse légitime si le rapport présuppose des capacités que le modèle de sécurité documenté considère comme fiables.

Une section entière existe à cause du pire scénario possible : ne jamais exécuter une preuve de concept sur sa propre machine. Celle-ci contient les clés SSH et GPG, les accès Packagist et GitHub et le gestionnaire de mots de passe ; un PoC malveillant en fait une attaque de la chaîne d'approvisionnement contre tous ceux qui installent le paquet. La hiérarchie de l'isolation : un sandbox microVM comme Docker Sandboxes (sbx), avec son propre noyau et un réseau bloqué par défaut ; un conteneur, sachant que sous Linux les conteneurs partagent le noyau hôte tandis que Docker Desktop sous macOS et Windows se situe déjà derrière une frontière de VM ; une VM durcie avec snapshot et sans dossiers partagés ; ou une VM jetable dans le cloud. Les fichiers d'entrée piégés comme les archives .phar ou les payloads sérialisés sont du code et relèvent des mêmes règles.

Le correctif se prépare dans le fork privé temporaire des GitHub Security Advisories, le test de régression d'abord, les messages de commit neutres. Pièges : la CI ne tourne pas dans les forks privés, le fork ne survit pas à l'advisory, et un patch silencieux sans advisory laisse composer audit et Dependabot aveugles. Le guide recommande aussi de traquer les bogues frères de la même classe avant publication, car une advisory braque les projecteurs sur cette classe de faiblesse, et de décider si les anciennes branches maintenues nécessitent des backports.

Pour les paquets Composer, trois champs de l'advisory déterminent si l'outillage fonctionne : l'écosystème doit être Composer, le nom du paquet doit être exactement le nom Packagist au format vendor/package, et les plages de versions affectées doivent être des contraintes Composer précises. C'est devenu plus important depuis que Composer 2.9 retire activement les versions couvertes par une advisory du pool de candidats du résolveur ; Composer 2.10 a généralisé ce mécanisme en un cadre de politique de dépendances unifié qui bloque aussi les paquets signalés comme malwares, y compris lors d'un composer install. Des plages trop larges causent des dégâts réels : pour une advisory PHPUnit en avril 2026, GitHub a réécrit les versions affectées précises 12.5.21 et 13.1.5 en plages larges, rendant du jour au lendemain toutes les anciennes versions de PHPUnit non installables, y compris PHPUnit 11 qui n'était pas affecté. La correction passe au plus vite par une pull request vers FriendsOfPHP/security-advisories, dont les données priment chez Packagist, plus une PR vers la GitHub Advisory Database.

Le jour de la publication suit un ordre fixe : fusionner le correctif, tagger et publier la release, vérifier qu'elle apparaît sur Packagist, publier l'advisory, envoyer la pull request FriendsOfPHP, puis annoncer. L'étape FriendsOfPHP ne doit pas être sautée : Composer ne lit pas les advisorys au niveau des dépôts, et la revue de GitHub vers l'Advisory Database accuse des jours voire des semaines de retard. Pour les projets hébergés hors de GitHub, c'est la seule porte d'entrée vers l'outillage. L'écart entre release et advisory doit se compter en minutes ou en heures, pas en jours. Si des détails fuient prématurément, l'embargo est de fait terminé et on publie ce que l'on a.

Concernant les CVE : GitHub est une CNA et un identifiant CVE peut être demandé depuis l'advisory, mais les demandes prennent actuellement des semaines. Ce qui protège réellement les utilisateurs, c'est la GHSA, car c'est sur elle que Composer, composer audit et Dependabot agissent. Il ne faut donc jamais retarder une release en attendant une CVE. Créditer le rapporteur dans l'advisory ne coûte rien et constitue une grande part de ce qui rend le signalement responsable attractif.

Les dernières sections traitent de la posture à long terme : activer GitHub Private Vulnerability Reporting et ajouter un SECURITY.md ; imposer un 2FA robuste sur GitHub, Packagist et la messagerie, Packagist devant afficher publiquement le statut MFA des mainteneurs ; ne jamais re-tagger une version publiée, ce que Packagist rejette désormais pour les versions stables ; supprimer les branches et workflows obsolètes pour réduire le risque de Poisoned Pipeline Execution ; et durcir les workflows GitHub Actions, ceux de PHPUnit étant passés de 52 constats à zéro après correction de l'injection de template, de la persistance des identifiants, des actions non épinglées, des permissions trop larges et des actions tierces superflues, avec zizmor recommandé comme vérification automatisée.

Les mainteneurs bloqués peuvent contacter l'Ecosystem Security Team à volker@thephp.foundation ou sur le canal #ecosystem-security du Discord phpc. L'équipe aide au triage, à la reproduction en environnement isolé, à la notation de sévérité et à la divulgation coordonnée, et affirme ne vouloir en aucun cas se placer entre un rapport et son correctif.