Mis à jour le 46 min de lecture

Sécurité des applications web : se protéger des failles

Sébastien Nobour

Fondateur de DEVEDANOS

Pratiques

PHP est un langage de programmation. Selon W3Techs, un service qui mesure les technologies utilisées par les sites web, il est utilisé, en octobre 2026, par 69,3 % des sites web dont on connaît le langage côté serveur. Le 21 octobre 2026, l’équipe de PHP a publié en urgence de nouvelles versions du langage. Elles corrigent deux failles critiques, que leurs découvreurs ont baptisées PHP2Shell. Avec quelques requêtes, sans compte ni mot de passe, un attaquant peut faire exécuter son propre code par le serveur qui héberge un site.

Si votre site ou votre application repose sur PHP, la question à poser à votre hébergeur ou à votre prestataire est simple : quelle version de PHP utilisons-nous, et quand passe-t-elle à une version corrigée ? Notre article sur la faille PHP d’octobre 2026 explique qui est concerné et ce qu’il faut faire, dans l’ordre.

Le même jour, GitLab et Node.js ont eux aussi publié des correctifs de failles graves. GitLab, une plateforme qui héberge le code des logiciels et automatise leurs tests et leur déploiement, a corrigé une faille (CVE-2026-110264) notée 10 sur 10, qui permettait, sans compte et dans certaines conditions, d’exécuter du code sur les installations que les entreprises hébergent elles-mêmes. Elle touchait toutes les versions depuis la 7.0. GitLab.com, la version hébergée par GitLab, était déjà corrigée.

Node.js, le logiciel qui exécute du JavaScript sur les serveurs, a publié des versions qui comblent quatre failles de gravité élevée, dont une, dans le décodage des données compressées au format Brotli, permet d’exécuter du code à distance. Ces versions mettent aussi à jour la liste des certificats de confiance, après la compromission d’une autorité de certification intermédiaire d’eMudhra.

Si votre entreprise héberge elle-même GitLab, ou si ses applications utilisent Node.js, la même question vaut pour ces logiciels : quelle version utilisons-nous, et quand passe-t-elle à une version corrigée ?

Des médias ont regroupé ces correctifs et d’autres incidents de la semaine sous le nom « Black October », apparu dans la nuit du 21 au 22 octobre. SecurityToday, un site d’actualité allemand sur la sécurité informatique, y voit surtout un pic de publications : beaucoup des attaques révélées ces jours-là avaient commencé des semaines ou des mois plus tôt.

La suite vaut pour toute application, quel qu’en soit le langage. Ces failles ne sont pas les premières de cette ampleur, et rien n’indique qu’elles seront les dernières. Face à une faille, trois choses se préparent à l’avance : ce qu’elle permet d’atteindre, le temps qu’il faut pour s’en apercevoir, et le temps qu’il faut pour la corriger.

Les détails techniques sont regroupés dans les passages intitulés « Pour votre équipe technique ».

Les attaques commencent de plus en plus tôt, parfois avant que la faille soit rendue publique

Mandiant, l’équipe d’analyse des menaces de Google Cloud, mesure chaque année le délai entre la publication d’une faille et sa première exploitation observée. En moyenne, ce délai était de 63 jours en 2018 et 2019, de 44 jours entre 2020 et le début de 2021, de 32 jours en 2021 et 2022, puis de 5 jours seulement en 2023 (Mandiant). Dans son rapport M-Trends 2026, Mandiant estime qu’en moyenne, la première exploitation précède de sept jours la publication de la faille. L’exploitation a couramment lieu « avant même la publication d’un correctif » (M-Trends 2026).

VulnCheck, une société de veille sur les failles, a regardé seulement les failles dont l’exploitation est avérée. Au premier semestre 2026, 23,43 % d’entre elles ont été exploitées le jour même de leur publication, ou avant. Les logiciels de gestion de contenu, comme WordPress et ses plugins (c’est ainsi que l’on appelle les extensions sur WordPress), sont la catégorie la plus visée : un tiers de ces failles (VulnCheck). Et selon le rapport annuel de Verizon sur les violations de données, dans son édition 2026, 31 % des violations commencent par une faille logicielle, devant les mots de passe volés (Verizon DBIR 2026).

Face à l’IA : appliquer les correctifs dès leur publication, et relire le code qu’elle écrit

Les autorités de sécurité s’accordent sur un point : l’IA raccourcit le temps dont disposent ceux qui appliquent les correctifs. En février 2026, le CERT-FR, le centre de réponse aux incidents de l’ANSSI, l’agence nationale de la sécurité des systèmes d’information, écrivait, dans sa synthèse de la menace liée à l’IA générative, que celle-ci « permet aux acteurs malveillants d’agir plus rapidement et donc à plus grande échelle ». En mai, le NCSC, le centre national de cybersécurité du Royaume-Uni, annonçait une vague de mises à jour, pour des failles de toutes gravités, parce que l’IA, entre des mains compétentes, permet d’exploiter les faiblesses accumulées dans les logiciels « à grande échelle et à un rythme soutenu ». En juin, la CISA, l’agence américaine de cybersécurité, a changé les délais qu’elle impose aux administrations fédérales américaines pour appliquer les correctifs : ils dépendent désormais du risque (exposition à Internet, exploitation avérée, impact). Le délai le plus court est de trois jours. Elle justifie ce changement par l’usage de l’IA par les attaquants, qui « pourrait réduire encore » le temps dont disposent les défenseurs. Nous en tirons une règle : un correctif critique s’applique le jour même de sa publication, ce que permet une approche de livraison où chaque modification passe déjà par le pipeline.

L’IA sert aussi à écrire du code, et plusieurs de ces autorités recommandent de le contrôler. En mars 2026, le directeur général du NCSC a prévenu que des logiciels peu sûrs, produits « sans relecture humaine », pourraient propager des failles. L’ANSSI et le BSI, son homologue allemand, relèvent dans leur rapport sur les assistants de programmation un risque de dépendance excessive à ces outils et d’acceptation sans examen du code qu’ils génèrent, en particulier chez les développeurs débutants. Ils recommandent que le code généré soit en règle générale vérifié par les développeurs, avec une relecture critique des erreurs de l’outil et des risques de sécurité. Le CERT-FR signale un autre piège : un assistant d’IA peut inventer le nom d’un composant qui n’existe pas, et des attaquants enregistrent ces noms pour y publier des versions malveillantes. Pour les agents d’IA, le principe du minimum de droits s’applique comme pour le processus PHP (détail plus bas).

Concrètement, nous conseillons à une équipe qui développe avec l’IA de relire chaque ligne que l’outil écrit et de la faire passer par les tests du pipeline, comme le reste du code ; de vérifier qu’un composant proposé par l’IA existe, et qui le publie, avant de l’ajouter ; et de ne donner à un agent que les droits dont sa tâche a besoin. Pour une application créée avec l’IA, notre article « Peut-on créer une application avec l’IA ? » détaille ce que l’outil fait seul.

Partir du principe qu’une faille existe déjà

Une PME ou une start-up n’a pas besoin de chercheurs en sécurité dans ses équipes. Trouver une faille comme PHP2Shell demande des spécialistes, et leur recherche s’est déroulée avant la publication : de huit à dix semaines séparent le premier signalement du correctif, selon les calendriers de Wiz, une société de sécurité du cloud, et de Calif, la société de recherche en sécurité dont les chercheurs ont signalé les premières failles à l’équipe de PHP (Wiz, Calif). Pour le reste, le guide d’hygiène informatique de l’ANSSI rassemble, dans son édition de 2017, 42 mesures. L’agence y écrit que la majeure partie des attaques pour lesquelles elle est intervenue auraient pu être évitées si ces mesures avaient été appliquées. Pour ceux qui manquent de connaissances, elle conseille de solliciter un spécialiste pour un diagnostic, et de désigner dans l’entreprise un référent en sécurité.

Dave Farley est l’inventeur du pipeline de déploiement, qu’on appelle souvent pipeline CI/CD. La livraison continue consiste à garder le logiciel prêt à être mis en production à tout moment, par petites modifications vérifiées automatiquement. Le pipeline de déploiement est la chaîne automatique qui prend chaque modification du code, la teste, l’enregistre et la rend prête à partir en production. Dave Farley est coauteur, avec Jez Humble, du livre « Continuous Delivery » (Livraison continue), et auteur de « Modern Software Engineering » (Ingénierie logicielle moderne). Dans « Continuous Delivery Pipelines » (Pipelines de livraison continue), il écrit que la sécurité peut demander l’avis de spécialistes, mais qu’elle est « la responsabilité de chacun dans l’équipe ». Les spécialistes conseillent ; ils ne doivent pas servir de « gardiens » qui valident chaque mise en production.

Ce que l’équipe qui développe et maintient l’application peut faire se résume à quatre objectifs, et aucun ne demande de chercher des failles :

  1. Limiter ce qu’une faille permet d’atteindre, pour qu’un attaquant qui entre par PHP ne trouve pas toutes les portes ouvertes derrière.
  2. Être alerté immédiatement quand quelque chose ne va pas, pour couper l’accès et trouver d’où vient l’attaque.
  3. Appliquer le correctif le jour même de sa publication, sans rien casser. Tant qu’aucun correctif n’existe, appliquer les mesures de protection que recommandent l’éditeur et les autorités, comme l’ont fait l’équipe de PHP et le CERT-FR pour PHP2Shell (The PHP Group, CERT-FR).
  4. Savoir quoi faire le jour où cela arrive, avec un plan écrit à l’avance.

Les sections « Limiter ce qu’une faille permet d’atteindre » et « Être alerté immédiatement » traitent les deux premiers objectifs. Les sections sur les dépendances, sur les mises à jour et sur l’approche de livraison traitent le troisième, et la section « Site piraté ou faille découverte » le quatrième. Le pipeline de déploiement vérifie aussi chaque modification du code, pour repérer les failles qu’elle introduirait (tests de sécurité dans le pipeline).

Selon M-Trends 2026, le délai médian entre l’entrée d’un attaquant dans un système et sa découverte est de 14 jours (M-Trends 2026). Pendant ce délai, l’attaquant agit : les deux premiers objectifs réduisent ce qu’il peut atteindre et le temps qu’il reste inaperçu.

Limiter ce qu’une faille permet d’atteindre

Un service numérique ne se résume pas à un site. Une application web typique comprend plusieurs éléments : un point d’entrée qui reçoit les requêtes venues d’Internet et les transmet, le serveur qui exécute le code, une base de données, des sauvegardes, et les comptes des personnes qui administrent le tout. Chacun de ces éléments peut être réglé pour qu’une faille dans l’un ne donne pas accès à tous les autres. C’est ce qu’on appelle la défense en profondeur.

Donner à chaque programme le minimum de droits. Le processus PHP n’a besoin ni d’être administrateur de la machine, ni de pouvoir modifier le code du site. Le compte qu’il utilise pour se connecter à la base de données n’a besoin, selon le guide de sécurisation de WordPress, que de lire et d’écrire des données ; les droits de supprimer, de modifier la structure ou d’accorder des droits peuvent lui être retirés, en sachant que certaines mises à jour de WordPress ont besoin de modifier cette structure. Jez Humble et Dave Farley le disent dans « Continuous Delivery » : les réglages par défaut des systèmes d’exploitation et des bases de données ne conviennent pas à une application en production ; il faut des pare-feu, des services inutiles désactivés, et des utilisateurs de base de données aux droits ajustés.

Rendre le code impossible à modifier depuis le site. Si le processus PHP ne peut pas écrire dans les dossiers du code, un attaquant qui en prend le contrôle ne peut pas y déposer aussi facilement un web shell, un petit fichier qui lui permet de revenir commander le serveur depuis son navigateur. Pour un site WordPress, seul le dossier des contenus envoyés doit rester modifiable, et l’éditeur de code de l’administration peut être désactivé.

Cloisonner. La base de données n’a aucune raison d’être joignable depuis Internet : seul le serveur d’application doit pouvoir s’y connecter. L’ANSSI demande de segmenter le réseau, de cloisonner les services visibles depuis Internet du reste du système, et d’administrer les serveurs depuis un réseau dédié (mesures 19, 23 et 28 de son guide).

Filtrer en amont, en connaissant les limites du filtre. Un pare-feu applicatif, ou WAF, examine les requêtes avant qu’elles n’atteignent le serveur et bloque celles qui ressemblent à une attaque connue. Le guide de sécurisation de WordPress recommande d’en installer un. Il a ses limites : Cloudflare demande lui-même d’appliquer le correctif malgré ses règles contre PHP2Shell, et le CERT-FR précise que le blocage qu’il propose n’est pas qualifié par ses soins. Un pare-feu applicatif fait gagner du temps ; il ne remplace pas le correctif.

Envoyer les en-têtes de sécurité, et les vérifier sur le site en ligne. Avec chaque page, le serveur peut indiquer au navigateur ce qu’il a le droit d’en faire : n’utiliser que des connexions chiffrées, refuser qu’un autre site affiche la page dans un cadre, ne charger des scripts que depuis les adresses prévues. L’OWASP, la fondation de référence sur la sécurité des applications web, recommande ces en-têtes, et cite Mozilla Observatory pour les vérifier sur le site en production. Le plus exigeant, la politique de sécurité du contenu (CSP), limite les scripts qu’une page peut exécuter : un code glissé dans une page de paiement pour copier les numéros de carte a alors plus de mal à s’exécuter. L’OWASP la présente comme « une deuxième ligne de protection efficace », sur laquelle il ne faut pas compter seule. Sur un site existant, elle se met en place par étapes, d’abord en mode d’observation, où le navigateur signale ce qu’elle bloquerait sans rien bloquer.

Sortir les secrets du code. Les mots de passe et les clés d’accès à d’autres services (paiement, envoi d’e-mails, stockage) ne devraient pas être écrits dans les fichiers du code. MITRE ATT&CK recommande une règle qui interdit de stocker des mots de passe dans des fichiers. Placés dans les variables d’environnement du serveur ou dans un coffre-fort de secrets, ils restent lisibles par PHP pendant qu’il s’exécute : cela ne les protège pas d’une prise de contrôle du processus PHP. Ce que l’on y gagne, à notre avis, c’est qu’ils ne se trouvent plus dans l’historique du code ni dans ses sauvegardes, et qu’on peut les changer sans toucher au code. Cela compte le jour où il faut tous les remplacer.

Choisir où vivent les secrets. Ceux du pipeline et de la production se gardent dans les variables protégées de la plateforme d’intégration continue, ou dans un coffre-fort de secrets : GitLab demande d’enregistrer les jetons et les mots de passe dans les réglages du projet, jamais dans le fichier qui décrit le pipeline. Sur le poste d’un développeur, nous conseillons de ne garder aucun secret en clair dans un fichier : le gestionnaire de mots de passe ou de secrets le fournit au programme au moment où celui-ci s’exécute ; à défaut de gestionnaire, Jez Humble et Dave Farley conseillent de le conserver chiffré. L’OWASP recommande de séparer les secrets de production de ceux de développement, et de n’accorder à chacun que le minimum de droits : un développeur travaille avec des identifiants de développement, qui n’ouvrent pas la production. Un jeton qui ne sert plus se révoque chez le service qui l’a émis, plutôt que de rester valable dans un fichier oublié.

Protéger les comptes des personnes. Un attaquant n’a pas toujours besoin d’une faille : un mot de passe réutilisé lui suffit. L’ANSSI demande de protéger les mots de passe, de changer ceux fournis par défaut, et de privilégier une authentification forte (mesures 11 à 13). Concrètement, nous conseillons un gestionnaire de mots de passe, pour que chacun ait un mot de passe différent par service, et une double authentification sur les comptes qui donnent accès à la production, à l’hébergement et au code.

Interdire les modifications à la main en production. Dans « Continuous Delivery Pipelines », Dave Farley fixe un objectif : « supprimer tout accès humain en écriture aux systèmes de production ». Chaque changement passe par le pipeline de déploiement. Dans « Continuous Delivery », les deux auteurs ajoutent que la production doit être fermée aux personnes extérieures comme aux personnes de l’entreprise, équipes d’exploitation comprises. Sans cela, quand quelque chose tourne mal, plus personne ne sait qui a fait quoi, ni quand.

Garder des sauvegardes hors ligne, et les tester. Une sauvegarde accessible depuis le serveur compromis peut être chiffrée ou effacée avec le reste. L’ANSSI demande une politique de sauvegarde qui prévoie des copies hors ligne et des tests de restauration, avec au moins un exercice de restauration par an (mesure 37). Une sauvegarde qui n’a jamais été restaurée n’a pas fait la preuve qu’elle fonctionne.

Pour votre équipe technique : la défense en profondeur

  • Point d’entrée : un serveur mandataire (reverse proxy), souvent associé à un répartiteur de charge qui distribue les requêtes entre plusieurs serveurs, reçoit les requêtes d’Internet et les transmet au serveur d’application. C’est aussi là qu’un blocage peut se faire avant PHP.
  • Utilisateur du processus PHP : avec PHP-FPM, chaque groupe de processus s’exécute sous l’utilisateur défini par la directive user, obligatoire (php.net). Les réglages posés par php_admin_value et php_admin_flag ne peuvent pas être modifiés par ini_set(). Ne pas exposer PHP-FPM sur une adresse joignable de l’extérieur.
  • Durcissement de PHP, et ses limites : la fiche OWASP sur la configuration de PHP recommande notamment expose_php = Off, display_errors = Off, allow_url_fopen = Off, allow_url_include = Off, open_basedir, disable_functions (system, exec, shell_exec, passthru, proc_open…), des cookies de session secure, httponly et use_strict_mode. Mais la documentation de PHP prévient elle-même que disable_functions « peut être contourné » et que open_basedir n’est qu’« un filet de sécurité supplémentaire, loin d’être complet », qui ne restreint pas l’accès aux sockets Unix. Ces réglages compliquent la suite d’une attaque ; ils ne l’empêchent pas, et PHP2Shell se déclenche avant que l’application ne s’exécute.
  • Production verrouillée : toute modification de l’infrastructure, d’une règle de pare-feu à une nouvelle version, passe par le même processus, testée sur un environnement semblable à la production, enregistrée et vérifiée (« Continuous Delivery »). Avec une infrastructure immuable, « toute modification manuelle sera écrasée au prochain déploiement » (« Continuous Delivery Pipelines »).
  • Sauvegardes : tester la sauvegarde, la restauration et l’archivage des données dans le cadre des tests de continuité (« Continuous Delivery ») ; copies hors ligne et exercice annuel de restauration (ANSSI, mesure 37).
  • En-têtes de sécurité (OWASP) : Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options: nosniff, frame-ancestors dans la CSP (ou X-Frame-Options), Referrer-Policy, Permissions-Policy. La CSP commence en Content-Security-Policy-Report-Only, le temps de recenser les scripts légitimes.

Être alerté immédiatement quand quelque chose ne va pas

Une fois la défense en place, il reste à être prévenu quand elle est franchie. L’objectif est triple : savoir qu’il se passe quelque chose d’anormal, couper l’accès, puis trouver d’où vient l’attaque. Dans « Continuous Delivery », Jez Humble et Dave Farley demandent que les équipes d’exploitation soient « informées immédiatement » d’un incident, et qu’elles disposent des outils pour en trouver la cause. Ils relèvent aussi une erreur fréquente : ignorer les erreurs au lieu de les enregistrer, ce qui empêche de les détecter.

Une solution de supervision surveille des signaux précis, et ses journaux sont conservés ailleurs que sur le serveur surveillé. Les équipes d’exploitation suivent l’état des serveurs en permanence sur des tableaux de bord, comme Grafana ou Kibana, qui rassemblent les mesures et les journaux et déclenchent une alerte quand un seuil est franchi. Voici les signaux que ces alertes doivent surveiller.

Le serveur web lance un programme. Un serveur web sert des pages ; il n’a aucune raison de lancer un interpréteur de commandes ou un outil de téléchargement. Quand il le fait, c’est souvent qu’un web shell est utilisé (MITRE ATT&CK).

Le serveur se connecte à des adresses inconnues. Un logiciel qui mine de la cryptomonnaie, un outil de prise de contrôle à distance ou une fuite de données ont tous besoin de connexions sortantes. Nous conseillons de bloquer par défaut les connexions sortantes du serveur, sauf vers les services dont l’application a besoin : cela limite aussi l’usage de ces outils.

Un fichier de code change. En production, le code ne change que lors d’un déploiement. Un nouveau fichier .php dans les dossiers du site, hors déploiement, est un signal d’intrusion. WordPress recommande de surveiller l’intégrité des fichiers, et rappelle qu’une attaque « laisse toujours des traces, dans les journaux ou dans les fichiers ».

Un nouveau compte administrateur apparaît. L’ANSSI demande de tenir à jour l’inventaire des comptes à privilèges (mesure 5). Un compte administrateur créé hors de toute procédure est un signal à traiter.

Les erreurs se multiplient. L’ANSSI demande d’enregistrer les erreurs des services web, en citant les erreurs 403, 404 et 500, ainsi que les arrêts inopinés (mesure 36).

Garder les journaux hors du serveur. Un attaquant qui contrôle le serveur peut effacer ses traces dans les journaux qui s’y trouvent. L’ANSSI recommande donc de centraliser les journaux sur un autre système, et de conserver les événements de sécurité au moins un an.

Pour votre équipe technique : la supervision

  • Signaux propres à PHP2Shell : selon Patchstack, qui suit les failles de l’écosystème WordPress, et Wiz, des requêtes d’envoi de fichiers suivies d’erreurs de mémoire ou d’erreurs 500 répétées, des cookies de session anormalement longs ou malformés, et des redémarrages inexpliqués des processus PHP.

Quelques outils libres, donnés en exemple :

  • Wazuh : son module de surveillance de l’intégrité des fichiers alerte quand un utilisateur ou un processus crée, modifie ou supprime un fichier surveillé (documentation Wazuh). OSSEC est l’outil cité par le guide de sécurisation de WordPress pour le même usage.
  • Falco : outil de sécurité à l’exécution, projet diplômé de la Cloud Native Computing Foundation ; ses règles par défaut couvrent le lancement d’un interpréteur de commandes, les connexions réseau inattendues et les modifications sous /etc (documentation Falco).
  • CrowdSec : détection et blocage d’intrusions, libre et participatif, qui partage entre ses utilisateurs les adresses malveillantes repérées.
  • ModSecurity : pare-feu applicatif libre.
  • Signaux de production à suivre en continu : mémoire, disque, processeur, journaux d’erreurs (« Continuous Delivery Pipelines »).

Les dépendances : choisir ses versions, vérifier chaque jour

Une application n’est pas écrite entièrement par ceux qui la développent. Elle s’appuie sur des composants publiés par d’autres, les dépendances, que des outils installent et mettent à jour : Composer pour PHP, npm ou pnpm pour JavaScript. Et elle s’exécute sur un environnement, PHP lui-même, fourni par le système du serveur, par l’hébergeur ou par l’image qui sert à la déployer.

Dans « Continuous Delivery », Jez Humble et Dave Farley sont catégoriques : un projet doit toujours indiquer « la version exacte des bibliothèques externes » qu’il utilise. Sans cela, écrivent-ils, on ne peut pas reconstruire à l’identique ce qui est en production. À notre avis, on ne sait pas non plus si l’on est exposé à une faille.

Moins de composants installés, c’est moins de failles possibles : l’OWASP demande de retirer les dépendances inutiles, et l’ANSSI de limiter les dépendances entre logiciels (« adhérences logicielles », dans son guide). Et un composant abandonné par son auteur ne recevra plus de correctif : il se remplace.

Inscrire la version exacte, et la verrouiller

Quand un projet accepte « toute version à partir de celle-ci », une version nouvellement publiée entre dans l’application à la prochaine mise à jour, sans que personne ne l’ait choisie. C’est, à ce jour, le réglage par défaut de npm (npm), et Composer le recommande pour les bibliothèques destinées à être réutilisées par d’autres projets (Composer). Le détail de la notation figure dans l’encadré « Pour votre équipe technique : les dépendances » plus bas.

Toutes les nouvelles versions ne se traitent pas de la même façon. Le correctif d’une faille grave s’installe dès sa publication : attendre, c’est laisser la porte ouverte. Les autres nouvelles versions peuvent attendre quelques jours, parce que c’est dans une version tout juste publiée que se glisse le code malveillant. En 2018, un attaquant a pris la maintenance du paquet event-stream et y a ajouté du code qui visait les portefeuilles de bitcoins de l’application Copay (npm). En septembre 2025, le compte du mainteneur de chalk, de debug et d’une vingtaine d’autres paquets JavaScript a été piraté au moyen d’un faux e-mail de réinitialisation ; selon StepSecurity, une société de sécurité informatique, ces paquets étaient alors téléchargés des milliards de fois par semaine (StepSecurity). Quelques jours plus tard, le ver Shai-Hulud, qui se propageait seul d’un paquet à l’autre, en avait compromis plus de 500 ; la CISA a alors recommandé de fixer les dépendances sur des versions sûres, publiées avant le 16 septembre 2025 (CISA).

D’où six pratiques.

Inscrire la version exacte dans le fichier qui déclare les dépendances. L’application reçoit alors une nouvelle version quand quelqu’un le décide, pas quand elle est publiée. Avec un fichier de verrouillage enregistré avec le code (pratique suivante), une plage de versions ne joue qu’au moment d’une mise à jour. Elle n’est donc pas une faille en soi : la version exacte est une règle d’équipe, qui rend chaque mise à jour délibérée. Pour une application PHP, composer.lock suffit à reconstruire à l’identique ce qui est en production ; la version exacte dans composer.json reste facultative. À ce jour, le pipeline de notre site refuse toute dépendance déclarée sans sa version exacte.

Conserver le fichier de verrouillage avec le code. Ce fichier enregistre la version exacte de chaque composant installé, y compris les composants dont dépendent vos composants, et la documentation de Composer demande de l’enregistrer avec le code du projet (Composer).

Installer depuis ce fichier, et ne mettre à jour que sur décision. Le pipeline installe exactement les versions du fichier de verrouillage. Une mise à jour se décide composant par composant, et se teste.

Attendre avant d’adopter une version tout juste publiée. Le gestionnaire pnpm propose ce délai, fixé par défaut, à ce jour, à un jour depuis sa version 11, « pour réduire le risque d’installer des paquets compromis ou défectueux ». Sa documentation indique que les versions malveillantes sont en général découvertes et retirées en moins d’une heure (pnpm). Le correctif d’une faille grave ne suit pas ce délai : il s’installe dès sa publication, une fois vérifié qu’il est bien annoncé par l’éditeur ou par le CERT-FR.

Bloquer les scripts d’installation, sauf ceux que l’on a autorisés. Un paquet JavaScript peut lancer n’importe quelle commande au moment où il s’installe, et l’OWASP conseille de désactiver ces scripts. À ce jour, pnpm les bloque par défaut, sauf pour les paquets que l’équipe a autorisés un par un (pnpm). Composer, pour PHP, n’exécute que les scripts du projet lui-même, et ne charge aucun plugin que sa liste allow-plugins ne nomme pas (Composer) : il suffit de ne pas assouplir ce réglage.

Fixer aussi la version du langage, et vérifier que chaque environnement l’utilise. L’environnement d’exécution, PHP ou Node.js, se traite comme une dépendance. Jez Humble et Dave Farley demandent de tester sur des environnements aussi proches que possible de la production, avec les mêmes logiciels installés. Nous conseillons donc que le projet déclare la version du langage qu’utilise la production, et que le pipeline échoue si un environnement en utilise une autre. Cette version se met à jour à son tour : le NIST, l’institut américain des normes et de la technologie, demande dans son cadre de développement de logiciels sécurisés (SSDF) d’utiliser des versions à jour des compilateurs, des interpréteurs et des outils de construction.

Le risque inverse existe aussi : fixer ses versions et ne plus jamais les mettre à jour. D’après nos calculs sur les chiffres de W3Techs, près de la moitié des sites PHP utilisaient, en octobre 2026, une version que l’équipe de PHP ne corrige plus. Une version exacte ne protège que si les mises à jour suivent, souvent, une à une, et vérifiées. Jez Humble et Dave Farley en font un principe général : « si c’est douloureux, faites-le plus souvent, et attaquez la difficulté plus tôt ». Une mise à jour faite chaque semaine change peu de choses à la fois ; une mise à jour repoussée pendant deux ans devient un chantier.

Vérifier chaque jour, pas seulement quand le code change

De nouvelles failles sont publiées chaque jour sur du code qui, lui, n’a pas changé. Une vérification lancée seulement au moment d’une modification laisse passer les failles publiées entre-temps. Composer, l’outil qui gère les composants d’une application PHP, sait comparer les composants installés aux avis de sécurité publiés sur Packagist, le dépôt principal des composants PHP, et signale aussi les composants abandonnés (Composer). Lancée chaque jour par une tâche planifiée du pipeline, cette vérification signale une faille dès que son avis de sécurité est publié. Dans « Continuous Delivery Pipelines », Dave Farley demande que la sécurité soit testée dans le pipeline, dès la première étape, et non traitée comme un contrôle à part.

Une fois par semaine, une autre vérification liste les composants pour lesquels une nouvelle version existe. Ce rappel évite l’écart de deux ans.

Une vérification planifiée peut aussi cesser de s’exécuter sans que personne le remarque, et son silence ressemble alors à une bonne nouvelle. Nous conseillons donc d’ajouter à chaque vérification planifiée un signal de vie : une alerte part quand la vérification attendue n’a pas eu lieu. Aucune référence de la sécurité ne le prescrit ; il s’appuie sur l’alerte que Jez Humble et Dave Farley demandent de prévoir dans « Continuous Delivery », celle qui signale qu’« un événement requis ne s’est pas produit ».

Trier les alertes : gravité et exploitation

Une alerte ne demande pas toujours la même réponse. Deux informations décident de l’urgence. L’exploitation d’abord : une faille déjà exploitée passe avant une faille plus grave qui ne l’est pas encore. La CISA tient la liste des failles exploitées : elle impose aux administrations fédérales américaines des délais pour les corriger, et recommande à toute organisation de les traiter « immédiatement ». Le FIRST, l’organisation internationale qui publie l’échelle de gravité CVSS, diffuse aussi chaque jour l’EPSS, une estimation de la probabilité qu’une faille soit exploitée dans les trente jours. En France, le CERT-FR distingue ses alertes, « destinées à prévenir d’un danger immédiat », de ses avis, qui font état de failles et des moyens de s’en prémunir. PHP2Shell a fait l’objet d’une alerte.

La gravité ensuite : la plupart des avis de sécurité donnent une note CVSS, de 0 à 10, que le FIRST range en cinq niveaux : aucune (0), faible (0,1 à 3,9), moyenne (4 à 6,9), élevée (7 à 8,9) et critique (9 à 10) (CVSS 4.0). Les failles de PHP2Shell sont notées 9,2 : critiques. Cette note compare la gravité d’une faille à celle des autres ; elle ne mesure pas le risque pour votre entreprise.

En pratique, nous conseillons de corriger le jour même de sa publication toute faille déjà exploitée, visée par une alerte du CERT-FR, ou critique : nous étendons ainsi la recommandation de la CISA, qui vise les failles exploitées. Les autres suivent le rythme normal des mises à jour, une à la fois.

Certaines alertes ne se traitent pas tout de suite : la partie du composant concernée n’est jamais appelée par l’application, ou aucun correctif n’existe encore. Le NIST demande d’enregistrer la raison de chaque exception de ce type, et de réexaminer régulièrement toutes les exceptions accordées. Nous y ajoutons une date d’expiration, à laquelle le pipeline échoue et l’exception se décide à nouveau : aucune référence ne la prescrit, c’est notre façon d’imposer le réexamen que demande le NIST.

Ces outils ont une limite, et PHP2Shell la montre. Ils examinent les bibliothèques déclarées par l’application, pas le langage qui l’exécute. Une vérification des composants sans alerte ne dit rien de PHP2Shell. La version de PHP se surveille à part : l’équipe de PHP publie la liste des versions prises en charge et un fil d’actualité de ses versions ; le CERT-FR publie ses alertes, et l’ANSSI demande de s’informer de l’apparition de nouvelles failles par ce canal (mesure 34). L’ANSSI demande aussi d’anticiper la fin de maintenance des logiciels (mesure 35) : PHP 8.2 n’en reçoit plus après le 31 décembre 2026.

Pour votre équipe technique : les dépendances

Un composer.json avec des versions exactes (noms de composants donnés pour l’exemple) :

{
  "require": {
    "vendor/component-a": "2.3.1",
    "vendor/component-b": "5.0.4"
  }
}

À la place de "^2.3.1", qui accepterait toute version de 2.3.1 à 3.0.0 exclue (Composer). À ce jour, npm inscrit ^ par défaut : ^1.2.3 accepte toute version à partir de 1.2.3 et avant 2.0.0 (node-semver). Pour npm, save-exact=true dans .npmrc fait inscrire la version exacte par défaut (npm).

Un exemple de pipeline GitLab, donné pour illustration et à adapter : une vérification à chaque envoi de code, une tâche quotidienne et une tâche hebdomadaire, chacune déclenchée par sa propre planification GitLab (planifications, règles).

# Exemple d'illustration, à adapter à votre projet
stages: [commit, audit]

.php:
  # Image de votre projet avec PHP et Composer, épinglée par son empreinte
  image: registry.example/php-composer@sha256:<digest>

commit:
  extends: .php
  stage: commit
  script:
    # Vérifie que composer.json et composer.lock sont cohérents
    - composer validate --strict
    # Échoue si un composant, de production ou de développement, a un avis de sécurité
    - composer audit --locked
    # Installe exactement les versions du fichier de verrouillage
    - composer install --no-interaction --prefer-dist
  rules:
    - if: $CI_PIPELINE_SOURCE == "push"

daily-audit:
  extends: .php
  stage: audit
  script:
    # Même vérification chaque jour, sans changement de code ; échoue aussi si un composant est abandonné
    - composer audit --locked --abandoned=fail
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule" && $SCHEDULE_KIND == "daily"

weekly-reminder:
  extends: .php
  stage: audit
  script:
    # Liste les nouvelles versions disponibles, sans faire échouer le pipeline : c'est le rappel
    - composer outdated --direct
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule" && $SCHEDULE_KIND == "weekly"
  • Le fichier de verrouillage (composer.lock, ou package-lock.json pour npm) est enregistré avec le code. Le pipeline lance composer install, qui installe exactement les versions de ce fichier ; composer update recalcule les versions et réécrit le fichier : il ne sert qu’à une mise à jour décidée, par exemple composer update vendor/component-a (Composer).
  • Délai avant adoption : minimumReleaseAge pour pnpm, min-release-age pour npm (noms des réglages en octobre 2026). Pour Composer, nous conseillons de tenir ce délai par une règle d’équipe, ou par l’outil qui propose les mises à jour.
  • composer audit renvoie un code de sortie non nul quand un composant est concerné par un avis : la tâche passe au rouge, et c’est l’alerte. --locked lit le fichier de verrouillage, même sans dossier vendor (Composer) : l’exemple lance donc la vérification avant composer install, et la tâche s’arrête avant d’installer un composant concerné par un avis. L’exemple vérifie aussi les composants de développement : ils s’exécutent dans le pipeline, qui a accès au code et aux secrets de déploiement.
  • À ce jour, Composer n’est pas inclus dans l’image officielle php de Docker, d’où l’image de projet dans l’exemple.
  • Images Docker épinglées par empreinte (@sha256:…) : la documentation de Docker indique que l’on obtient alors toujours la même image, et prévient que l’image ne reçoit plus les mises à jour, « qui peuvent inclure des correctifs de sécurité » (Docker). L’épinglage n’a donc de sens qu’avec une mise à jour régulière de l’empreinte, testée par le pipeline.
  • Des empreintes partout où elles existent, pas seulement pour les images Docker. Les fichiers de verrouillage de npm et de pnpm enregistrent l’empreinte de chaque paquet (champ integrity), et l’installation échoue si le paquet téléchargé ne correspond pas. Pour un script ou une feuille de style chargés depuis un autre domaine, l’attribut integrity (Subresource Integrity) fait refuser au navigateur un fichier modifié (MDN) ; l’ANSSI recommande ce contrôle pour les ressources JavaScript et CSS, internes comme tierces, en particulier celles d’un CDN (recommandations R11 et R12). L’OWASP demande d’activer la vérification des empreintes et des signatures des paquets téléchargés. Renovate ou Dependabot peuvent proposer ces mises à jour sous forme de demandes de fusion ; ils ne déploient rien eux-mêmes (Renovate, Dependabot).
  • Surveiller PHP lui-même : le fil Atom de php.net (https://www.php.net/feed.atom) et les alertes du CERT-FR. OSV-Scanner, de Google, lit à ce jour composer.lock et, dans une image de conteneur, les paquets Alpine et Debian ou Ubuntu : il peut repérer un PHP installé par le système de l’image.
  • Scripts d’installation : pour pnpm, allowBuilds liste les paquets autorisés à exécuter un script à l’installation (pnpm) ; pour npm, ignore-scripts=true dans .npmrc (OWASP). Pour Composer, allow-plugins ne nomme que les plugins nécessaires, jamais true pour tous (Composer).
  • Version du langage : pour PHP, require.php dans composer.json, et composer check-platform-reqs, qui échoue quand la version de PHP ou une extension de l’environnement ne correspond pas ; config.platform fait choisir les dépendances pour la version de PHP de la production (Composer). Pour Node.js, le champ engines de package.json, avec engine-strict=true, fait échouer l’installation sur une autre version.
  • Exceptions : audit.ignore, dans composer.json, associe à chaque avis ignoré sa raison (Composer).

Mises à jour : automatiques, ou sur décision

Pour un logiciel que l’on installe et que l’on utilise tel quel (Windows, macOS, un téléphone, un navigateur, un logiciel de bureautique), nous conseillons d’activer les mises à jour automatiques, comme le demande le NCSC. Sur un site WordPress, nous déconseillons les mises à jour automatiques que WordPress applique seul.

Une application que l’on développe, ou que l’on assemble à partir de composants, se met à jour sur décision. Le référentiel Cyber Essentials du NCSC exclut de son périmètre les composants développés sur mesure des applications web, et recommande pour eux « un développement et des tests rigoureux ». L’OWASP, dans son classement 2025 des risques les plus critiques pour les applications web, demande de « choisir délibérément la version de chaque dépendance, et de ne mettre à jour qu’en cas de besoin », et d’« éviter de déployer les mises à jour sur tous les systèmes à la fois ». Son classement des risques propres aux pipelines CI/CD demande de ne pas configurer les outils pour qu’ils prennent toujours la dernière version d’un paquet. Nous conseillons que chaque mise à jour, du langage comme d’un composant, passe par le pipeline de déploiement et ses tests automatisés.

Cette approche suppose quelqu’un pour assurer la maintenance. Ce qui s’automatise, ce sont les alertes : une alerte quand une faille touche les versions en place, une alerte quand quelque chose d’anormal se passe sur le serveur, qui prévient à l’instant même où cela se produit. C’est à une personne de décider quand mettre à jour, et d’appliquer sans attendre le correctif d’une faille critique ou déjà exploitée.

Pour un site WordPress ou une application PHP, selon l’hébergement, c’est l’hébergeur ou vous qui mettez PHP à jour. Sur WordPress, les plugins et les thèmes se mettent à jour un à la fois.

Tester la sécurité dans le pipeline de déploiement

Chaque modification du code peut aussi introduire une faille : le pipeline contrôle donc le code que l’équipe écrit, comme il contrôle les dépendances. Dave Farley, cité plus haut, demande aussi d’automatiser les tests d’intrusion courants. Le NIST recommande une analyse statique qui vérifie automatiquement le code, et des tests dynamiques de failles intégrés aux tests automatisés.

L’analyse statique lit le code sans l’exécuter, et y repère les motifs de code connus pour causer des failles. Semgrep, un outil libre parmi d’autres, propose des règles pour PHP comme pour JavaScript. Ces outils signalent aussi des cas qui n’en sont pas : quelqu’un doit examiner chaque alerte, et le NIST demande d’enregistrer et de trier les problèmes trouvés.

Les tests dynamiques interrogent l’application en fonctionnement, comme le ferait un visiteur. Le scan de base de ZAP, un outil libre de test de sécurité des applications web, n’effectue aucune véritable attaque : il observe les réponses du site, et signale par exemple un en-tête de sécurité manquant. Sa documentation le dit adapté à un pipeline, et même à un site en production. Un scan actif, qui envoie de vraies attaques, se lance uniquement sur un environnement de test, jamais sur la production.

Le fuzzing envoie au programme des données inattendues ou aléatoires, pour voir s’il les traite mal. Le NIST le cite parmi ses exemples. À notre avis, il ne s’impose pas pour une application web courante ; il se justifie pour le code qui lit et interprète des données reçues de l’extérieur, comme un format de fichier.

Vérifier qu’aucun secret n’entre dans le code. Nous conseillons un outil de détection des secrets, comme gitleaks, qui examine chaque modification avant qu’elle soit enregistrée et envoyée ; le pipeline reprend ensuite tout l’historique du code, au cas où cette première vérification aurait été contournée. L’OWASP recommande de détecter les secrets avant même l’enregistrement d’une modification, et d’utiliser plus d’un outil pour cela. Un secret enregistré par erreur se révoque et se remplace : l’OWASP demande qu’une clé exposée soit révoquée immédiatement.

Pourquoi l’approche de livraison décide du délai d’application d’un correctif

Tout ce qui précède repose sur une même capacité : mettre un correctif en production le jour même, sans rien casser. Cette capacité ne s’improvise pas le jour de l’alerte. Elle dépend de la façon dont le logiciel est livré au quotidien.

D’expérience, dans une organisation où chaque mise en production est une opération rare (un soir par trimestre, des tests faits à la main, plusieurs personnes mobilisées), une faille critique arrive comme un imprévu. Il faut monter une correction d’urgence en dehors du calendrier, réunir les personnes qui savent déployer, refaire les tests à la main, réserver une fenêtre d’intervention, parfois obtenir l’accord d’un comité. Le correctif devient un projet, et pendant ce temps, l’application reste exposée. Ce rythme de livraison pousse à corriger directement sur le serveur, à la main. Dans « Continuous Delivery », Jez Humble et Dave Farley refusent ce raccourci sans détour : face à un défaut critique, « ne contournez sous aucun prétexte votre processus ». Ils rappellent aussi qu’il vaut parfois mieux revenir à la version précédente que de déployer une correction. Une correction faite à la main en production n’est pas testée, peut aggraver le problème, et n’est souvent enregistrée nulle part.

Le problème dépasse un cadre particulier. Il touche toutes les approches prédictives, le cycle en V comme les cadres présentés comme agiles, dès qu’une fonctionnalité est engagée avec un périmètre, un budget et un délai fixés à la fois, puis inscrite dans un planning bâti sur des estimations. SAFe (Scaled Agile Framework), par exemple, planifie le travail par intervalles de huit à douze semaines, avec des objectifs et des dates de livraison pour chacun. Ces organisations prévoient des corrections d’urgence, qui passent avant le reste. Chacune reste pourtant une exception au planning : elle emprunte un chemin moins rodé que celui des livraisons prévues, et décale ce qui était engagé. Dans « Accelerate », Nicole Forsgren, Jez Humble et Gene Kim rappellent que des délais courts comptent aussi « lorsqu’un défaut ou une panne survient et qu’il faut livrer un correctif rapidement, en toute confiance ».

Or le travail qui n’était pas planifié prend de plus en plus de place : davantage de failles publiées, donc davantage de correctifs qui ne peuvent pas attendre. L’IA ne crée pas les faiblesses de ces organisations : elle les exploite plus vite. Pour Amazon, « un délai de 7 ou 30 jours suppose un répit qui n’existe plus », et le NCSC demande aux organisations de s’assurer que leurs « processus et leur appétence au risque permettent des mises à jour fréquentes et à grande échelle ».

À notre avis, ce fonctionnement prédictif expose d’abord les organisations qui y restent : chaque correctif urgent bouscule un planning qui ne lui avait pas fait de place, et pendant ce temps, le système reste exposé. Dans une approche adaptative, le périmètre évolue selon les priorités, et avec la livraison continue, le correctif passe devant le reste et suit le chemin de toutes les autres modifications, le jour même. Dans leur enquête, les auteurs d’« Accelerate » constatent que les organisations les plus performantes en livraison ont deux fois plus de chances que les autres de déclarer avoir dépassé leurs objectifs de rentabilité et de parts de marché.

Appliquer un correctif ne demande pas pour autant de confier le système à des experts en cybersécurité. C’est le travail quotidien de l’équipe qui développe l’application : elle met à jour le composant concerné, le pipeline de déploiement vérifie la modification par les tests automatisés, puis la met en production. DORA demande d’intégrer la sécurité « au travail quotidien » de toute la chaîne de livraison, parce que « la sécurité est la responsabilité de tous ».

Avec la livraison continue logicielle, pratiquée dans le cadre d’une approche adaptative, c’est-à-dire en ajustant le logiciel en continu à partir de son usage, le même correctif est une modification comme une autre. Jez Humble définit la livraison continue comme « la capacité de mettre en production, ou entre les mains des utilisateurs, des modifications de tous types, y compris de nouvelles fonctionnalités, des changements de configuration, des corrections de bugs et des expériences, de manière sûre, rapide et durable » (continuousdelivery.com). Dave Farley précise que le pipeline de déploiement est « la SEULE route vers la production » : chaque modification y passe, la mise à jour de PHP comme la nouvelle fonctionnalité. Elle subit les mêmes tests automatisés, puis part en production. Comme chaque modification suit ce chemin, la procédure est déjà rodée le jour où un correctif arrive.

Cette discipline change aussi la façon de gérer le projet. Une faille critique ne se planifie pas pour la fin de la semaine : elle passe devant le reste, le jour même. Une équipe qui respecte la discipline de la livraison continue peut changer ses priorités dans la journée, en fonction de ce qui arrive, parce que rien de ce qui est en cours ne bloque la mise en production du correctif.

Pour que rien de ce qui est en cours ne retienne le correctif, Jez Humble et Dave Farley recommandent que chacun enregistre ses modifications sur la branche principale, et que l’on « cache une nouvelle fonctionnalité tant qu’elle n’est pas terminée » : c’est le trunk-based development, où tout le monde intègre son travail sur une seule branche, plusieurs fois par jour. Un correctif urgent suit alors le même chemin que le reste, sans attendre la fin d’une fonctionnalité. Pour cacher une fonctionnalité inachevée, un réglage de configuration suffit ; les mêmes auteurs demandent de retirer ces réglages dès qu’ils ont servi. C’est une pratique de la livraison continue, dont les référentiels de sécurité ne traitent pas.

Nous conseillons que le pipeline construise l’application une seule fois, puis déploie la même archive sur chaque environnement. « Chaque fois que l’on compile le code, on court le risque d’introduire une différence », écrivent Jez Humble et Dave Farley. La règle vaut aussi pour PHP, qui ne se compile pas. L’archive contient le code, les composants installés par Composer et les fichiers statiques ; c’est elle qui part en production, et rien ne s’installe directement sur le serveur. Après chaque déploiement, un smoke test, un test rapide, vérifie que l’application répond. Revenir en arrière consiste alors à redéployer l’archive précédente, ce que les mêmes auteurs décrivent comme souvent la façon la plus simple. Les données limitent ce retour : une base de données modifiée par la nouvelle version ne revient pas d’elle-même à son état précédent.

DORA (DevOps Research and Assessment), le programme de recherche de Google Cloud sur le développement et la mise en production des logiciels, mesure ce que cette pratique change. DORA ne mesure pas directement le délai d’application d’un correctif. L’indicateur le plus proche est le délai de mise en production d’une modification, du moment où elle est enregistrée dans le code à celui où elle est en production. Dans « Modern Software Engineering », Dave Farley pose une question voisine : combien de temps faut-il pour qu’une modification d’une seule ligne passe de l’idée au logiciel qui fonctionne ? À notre avis, ce délai est aussi celui qu’il faudra pour appliquer le prochain correctif de sécurité. Les recherches de DORA montrent régulièrement que « la vitesse et la stabilité ne sont pas des compromis » (DORA). Selon un résumé du rapport 2024 publié par Octopus Deploy, un éditeur d’outils de déploiement, les équipes les plus performantes mettent une modification en production en moins d’un jour, et se remettent d’une mise en production ratée en moins d’une heure (Octopus Deploy, rapport 2024 de DORA).

Les comités d’approbation des changements ne compensent pas une livraison lente. Dans « Modern Software Engineering », Dave Farley cite les travaux de recherche publiés dans le livre Accelerate : « l’approbation par un organe externe, comme un responsable ou un comité d’approbation des changements, ne permet tout simplement pas d’augmenter la stabilité des systèmes en production […] C’est même pire que de n’avoir aucun processus d’approbation des changements ».

Les références de la sécurité ne fixent pas le même délai. L’ANSSI, dans son guide de 2017, demande d’appliquer les correctifs de sécurité « dans le mois qui suit leur publication par l’éditeur », et prévoit une éventuelle qualification des correctifs et un déploiement progressif (mesure 34). L’OWASP, dans son classement 2025 des dix risques les plus critiques pour les applications web, met en garde contre cette cadence : l’exposition « arrive souvent dans les environnements où l’application des correctifs est une tâche mensuelle ou trimestrielle soumise à un contrôle des changements, ce qui laisse les organisations exposées pendant des jours ou des mois à des failles déjà corrigées ». Le délai d’un mois date de 2017, avant que le délai d’exploitation ne tombe à quelques jours, et se présente comme un maximum. Avec des attaques qui commencent parfois avant que le correctif soit publié, il ne suffit plus comme objectif. La vérification des correctifs que demande l’ANSSI n’impose pas d’attendre un mois : des tests automatisés dans le pipeline la réalisent à chaque modification.

Agents d’IA : ce que la livraison continue couvre, et ce qui relève des droits d’accès

Jamie Dimon, président-directeur général de JPMorgan Chase, a pointé en octobre 2026 deux risques : des agents d’IA qui agissent sur les comptes bancaires de leurs utilisateurs, et des outils d’IA qui mettent au jour des centaines de failles graves dans du code libre, ce qui laisse des industries « complètement sans protection ». À ce jour, sa banque ne laisse aux agents d’IA externes qu’un accès en lecture seule aux comptes de ses clients particuliers.

Pour les failles que l’IA met au jour plus tôt, la livraison continue répond au délai d’application du correctif. Dès 2010, dans « Continuous Delivery », Jez Humble et Dave Farley demandaient de pouvoir publier rapidement une nouvelle version « au cas où l’on découvrirait des défauts critiques ou des failles de sécurité ». Ils demandaient aussi que la production soit « entièrement verrouillée », pour que seul le pipeline de déploiement puisse y apporter des changements. Avec ces pratiques et celles décrites dans la section sur l’approche de livraison, le correctif d’une faille trouvée par une IA part en production comme toute autre modification. À notre avis, la livraison continue raccourcit le temps pendant lequel une faille dont le correctif existe reste exploitable chez vous ; trouver les failles et arrêter les attaques relève des autres pratiques décrites dans cet article.

L’autre risque que décrit Jamie Dimon relève des droits d’accès : savoir si un agent agit bien pour la personne qui l’a autorisé, pour une banque comme pour toute application. L’OWASP range l’« autonomie excessive » parmi les risques des applications d’IA, et le NCSC demande d’appliquer aux agents le principe du minimum de droits. Si votre application laisse des agents d’IA agir pour vos utilisateurs, nous conseillons, comme l’OWASP, de ne leur donner que le minimum de droits, de les faire agir dans le contexte de l’utilisateur concerné, et de faire approuver par une personne les actions à fort impact.

Site piraté ou faille découverte : que faire, dans l’ordre

Le jour où une faille touche votre logiciel, la marche à suivre tient en huit étapes. Elle s’appuie sur quatre documents publics : le guide « Que faire en cas de cyberattaque ? » de cybermalveillance.gouv.fr, le service public d’assistance aux victimes d’attaques informatiques, écrit pour les dirigeants ; sa fiche sur la défiguration de site ; le guide d’hygiène de l’ANSSI ; la fiche réflexe du CERT-FR, vers laquelle renvoie son alerte sur PHP. Mieux vaut avoir lu ces étapes avant ce jour-là, et savoir qui fait quoi.

Les trois premières étapes dépendent de la faille. Pour PHP2Shell, il s’agit de savoir si vous êtes exposé, de mettre à jour ou d’isoler, puis de chercher des traces d’intrusion. Les cinq suivantes valent pour toute faille.

4. Préserver les preuves avant de nettoyer. Cybermalveillance.gouv.fr demande de récupérer les journaux du pare-feu, du serveur mandataire et des serveurs touchés, et de réaliser une copie complète de la machine attaquée et de sa mémoire. Le guide pour les dirigeants demande de déposer plainte « avant toute action de remédiation ». Redéployer une version propre avant cette copie efface justement ce qui permettrait de comprendre ce qui s’est passé.

5. Changer tous les secrets que le serveur détenait. Nous conseillons de changer les mots de passe de la base de données, les clés de l’application (clés et sels de WordPress, APP_KEY de Laravel, clé de chiffrement de Magento), les clés d’accès aux services tiers (paiement, envoi d’e-mails, stockage), les comptes d’envoi de messages, les jetons de déploiement présents sur le serveur, les clés privées des certificats et les comptes administrateurs, et de fermer les sessions ouvertes. Les nouveaux secrets se génèrent depuis un environnement sain et ne se déploient que sur le serveur reconstruit à l’étape suivante, jamais sur le serveur encore compromis. Le CERT-FR demande de « changer les secrets potentiellement compromis », cybermalveillance.gouv.fr de changer tous les mots de passe avant toute remise en ligne. CosmicSting l’a montré : une clé volée avant le correctif reste valable après, et Sansec recommande de remplacer la clé de chiffrement et d’invalider l’ancienne. Changer la clé de l’application déconnecte tous les utilisateurs ; c’est attendu. Attention, en revanche, aux données chiffrées avec l’ancienne clé : elles deviennent illisibles, sauf si l’ancienne clé reste disponible pour les déchiffrer ou si elles sont rechiffrées avec la nouvelle. Laravel permet de garder les anciennes clés pour le déchiffrement (APP_PREVIOUS_KEYS), et Adobe fournit pour Magento une procédure de changement de clé et une commande qui rechiffre les données.

6. Si le serveur a été compromis, reconstruire à partir d’une source saine. Nous conseillons de ne pas restaurer l’ancienne image du serveur ni l’ancien code, qui peuvent contenir le web shell. Avec un pipeline, on reconstruit le serveur et l’application depuis le dépôt de code, à une version saine, avec le correctif. Les données, elles, se restaurent à notre avis depuis une sauvegarde antérieure à la première date d’intrusion possible. C’est là que les sauvegardes hors ligne et testées font la différence. Cybermalveillance.gouv.fr demande ensuite une remise en service progressive, après s’être assuré que la faille est corrigée.

7. Déclarer. Si des données personnelles ont pu être consultées, modifiées ou détruites, il faut notifier l’incident à la CNIL dans les 72 heures, rappelle cybermalveillance.gouv.fr. Déclarer aussi le sinistre à votre assureur. Pour être accompagné, l’ANSSI conseille de faire appel à un prestataire qualifié de réponse aux incidents de sécurité (mesure 40 de son guide). En cas d’urgence, la police et la gendarmerie répondent au 17.

8. Tirer les leçons. Poser la question que cybermalveillance.gouv.fr place à la dernière étape de son guide : qu’a-t-on appris ? Combien de temps a-t-il fallu pour appliquer le correctif, et pourquoi ? C’est le délai dont DORA mesure l’indicateur le plus proche, présenté plus haut : plus il est court au quotidien, plus le prochain correctif sera appliqué tôt après sa publication. Qu’est-ce qui a permis, ou aurait permis, de s’apercevoir de l’attaque ?

Comment nous travaillons

Un correctif de sécurité est une modification comme les autres : il passe par le même pipeline que le reste. Nous ne cherchons pas les failles ; cette recherche revient aux chercheurs. Notre rôle est de limiter ce que la prochaine faille permettra d’atteindre, d’être alerté dès qu’elle est exploitée, et d’appliquer son correctif dès qu’il est publié.

La même équipe développe, teste, déploie et maintient votre logiciel en continu, dans le même pipeline. Chaque déploiement en production transite par un pipeline de déploiement : la sécurité et l’accessibilité sont vérifiées automatiquement avant d’atteindre la production, et la performance est surveillée en production. Nous mettons en production une modification à la fois, après vérification par le pipeline. En cas d’incident, nous revenons à la version précédente.

Pour les applications que nous développons, voici ce que nous mettons en place grâce à un pipeline de déploiement. Chaque dépendance est inscrite à sa version exacte. Une version tout juste publiée n’est adoptée qu’au bout de trois jours, sauf le correctif d’une faille grave : nous levons alors ce délai, au cas par cas, pour l’installer dès sa publication. Chaque matin, une tâche planifiée vérifie si une faille connue touche les composants en place. Nous mettons aussi en place la supervision des serveurs, avec des alertes sur les signaux décrits plus haut. Une mise à jour de PHP ou d’un composant passe par le même pipeline que le reste.

Les correctifs de sécurité et les mises à jour de dépendances font partie de la maintenance incluse dans notre offre : un logiciel sur mesure à budget mensuel fixe, avec une garantie zéro régression.

Nous offrons également l’audit de chaîne de production logicielle et la formation d’équipes techniques. L’audit vérifie si une faille découverte dans votre logiciel peut être corrigée et livrée à vos clients le jour même, et ce qu’il reste à mettre en place.

Pour aller plus loin

Une mise à jour de sécurité atteint la production le jour même de sa publication quand chaque modification y arrive déjà par petits changements. Notre article sur la livraison continue et le déploiement continu explique comment cela fonctionne, et notre article sur l’approche prédictive ou adaptative pourquoi cette façon de livrer relève d’une approche adaptative.

Pour reprendre une application dont le langage ou les composants ne sont plus maintenus, notre page reprise et refonte d’application explique comment nous procédons.

Vous avez une application à faire développer, ou à reprendre en main ? On en parle ?

Sources

À lire aussi

Shadow IT : définition, exemples et risques

Shadow IT, c'est quoi ? La définition du centre britannique de cybersécurité, des exemples (Excel, outils d'IA), les risques pour l'entreprise, et pourquoi la réponse est un outil adapté au travail.

Mise à jour automatique de WordPress : faut-il l'activer ou la désactiver ?

Faut-il activer ou désactiver la mise à jour automatique de WordPress ? Nous déconseillons celle que WordPress applique seul aux plugins et aux thèmes, sans aucun test. Un hébergeur qui teste chaque mise à jour avant de l'appliquer peut s'en charger ; sans lui, mettez à jour un plugin à la fois, puis vérifiez le site.