Mises à jour de sécurité Drupal : le manuel d’un mainteneur

Je suis des deux côtés de la sécurité Drupal : consultant qui applique des mises à jour sur des sites en production, et mainteneur de 24 projets sur drupal.org — ce qui veut dire que j’ai aussi publié des correctifs de sécurité, coordonné avec l’équipe sécurité de Drupal, et vu ce qui se passe de l’autre côté de l’embargo. Voici comment la machine fonctionne, et la routine que je voudrais voir chez chaque propriétaire de site.

Comment fonctionnent vraiment les alertes de sécurité Drupal

• Les alertes sont planifiées. Les versions de sécurité de core sortent le mercredi, annoncées à l’avance par des PSA (annonces publiques) pour les plus critiques. C’est un cadeau : vous pouvez planifier une fenêtre de maintenance avant de connaître les détails.
• Les correctifs se préparent sous embargo. Quand une vulnérabilité est signalée, les mainteneurs travaillent avec l’équipe sécurité dans une file privée. Rien n’est public avant la sortie du correctif — c’est pourquoi « le module a l’air calme » ne vous dit rien de ce qui arrive.
• La gravité est notée, pas ressentie. Chaque alerte porte un score de risque (complexité d’accès, interaction utilisateur, privilèges requis, impact sur les données). Un « Critical » exploitable sans authentification est un événement où l’on lâche tout ; un « Less critical » nécessitant un compte admin peut attendre le cycle suivant.
• Seules les versions couvertes reçoivent des alertes. Les modules sans couverture de l’équipe sécurité (versions alpha/bêta, ou projets qui n’ont pas opté pour la couverture) ne reçoivent aucune alerte — les vulnérabilités sont corrigées en silence, ou jamais. Un module contrib abandonné n’est pas « stable parce qu’il ne bouge plus » : c’est de la surface d’attaque non auditée.

La leçon d’histoire a un nom : Drupalgeddon. En 2014 (SA-CORE-2014-005) puis en 2018 (SA-CORE-2018-002), les sites non patchés après une alerte critique ont été compromis en quelques heures après la publication. Les attaquants aussi lisent les alertes — la publication est le coup de pistolet du départ.

La routine que j’applique aux sites clients

1. Connaître son mercredi. Abonnez-vous à la newsletter sécurité et aux flux RSS ; mettez les fenêtres de sortie dans le calendrier de l’équipe. Les surprises, c’est pour les amateurs.
2. Le délai de patch dépend de la gravité. Critique core/contrib exploitable à distance : le jour même, quitte à déployer un hotfix. Modérément critique : dans la semaine. Le reste : le train de maintenance mensuel.
3. Automatiser la détection ennuyeuse. composer audit en CI fait échouer le build sur les paquets vulnérables connus ; Upgrade Status et les tableaux de bord attrapent le reste. Un humain doit décider quand mettre à jour, jamais s’il faut le remarquer.
4. Mettre à jour dans le bon ordre. composer update → drush updb → drush cr → tests automatisés → déploiement par le même pipeline que n’importe quelle version. Les mises à jour de sécurité qui contournent la CI, c’est échanger une vulnérabilité contre une panne.
5. Auditer la liste des modules deux fois par an. Chaque module désinstallable, c’est de la surface d’attaque, du travail de mise à jour et du périmètre d’audit en moins. Le patch le moins cher est le module que vous ne faites plus tourner.
6. Surveiller les méta-risques. Fin de vie de PHP, thèmes non maintenus, et — le gros sujet du moment — la fin de support de Drupal 10 en décembre 2026. Faire tourner une majeure en fin de vie, c’est transformer chaque future alerte en correctif que vous ne pourrez pas appliquer.

Ce qu’être mainteneur a changé dans ma façon de voir

Publier un correctif de sécurité pour un module utilisé par des centaines de milliers de sites vous apprend deux choses. D’abord, le correctif est la partie facile — la partie difficile, c’est la discipline de compatibilité, pour que des sites en retard de quatre versions mineures puissent quand même prendre votre correctif sans projet de migration. C’est pourquoi maintenir son site à jour en routine est en soi un contrôle de sécurité : ça raccourcit le chemin d’urgence.

Ensuite, le silence n’est pas la sécurité. J’ai vu des tickets rester des semaines dans des files privées le temps qu’un correctif soit conçu. Les propriétaires de sites qui s’en sont bien sortis étaient ceux dont le pipeline de mise à jour était déjà chaud.

Envie de faire auditer votre pipeline de mise à jour — ou de remettre sous maintenance un site Drupal 7/9/10 que plus personne n’ose toucher ? C’est littéralement mon métier.