NCSC : préparez-vous à la patch wave dopée par l'IA

Ce qui s'est passé

Le 1er mai 2026, le National Cyber Security Centre britannique a publié sur son blog officiel un billet intitulé Preparing for a vulnerability patch wave, signé par son CTO Ollie Whitehouse. Le texte, repris par The Register, The Record et Industrial Cyber dans les heures qui ont suivi, dresse un constat brutal : la rapidité avec laquelle les modèles d'intelligence artificielle découvrent désormais des vulnérabilités dans le code existant va provoquer une avalanche de divulgations sans précédent. L'agence parle explicitement d'un changement de régime, comparable à celui qu'avait imposé l'arrivée des fuzzers automatiques dans les années 2010, mais à une échelle décuplée.

Le NCSC s'appuie sur plusieurs signaux convergents. D'abord, l'expérience Project Glasswing menée par Anthropic avec son modèle Claude Mythos Preview, qui a identifié des milliers de vulnérabilités zero-day dans les principaux systèmes d'exploitation et navigateurs en quelques semaines. Ensuite, la divulgation simultanée de CVE-2026-31431 alias Copy Fail dans le noyau Linux, une régression vieille de huit ans qu'un audit IA-piloté aurait pu lever bien plus tôt. Enfin, les retours opérationnels du CERT-EU et du CERT-FR qui constatent une accélération mesurable du rythme de publication d'advisories sur les composants open source critiques.

La cible principale du billet, ce sont les RSSI et les directions techniques. Le NCSC insiste sur la notion de technical debt — dette technique — accumulée par toutes les organisations qui ont privilégié la livraison de fonctionnalités sur la résilience du code. Cette dette, jusqu'ici invisible faute de moyens d'audit massifs, devient soudain exploitable. L'agence cite explicitement les composants embarqués, les firmwares industriels, les bibliothèques tierces utilisées par les frameworks web et les SDK mobiles : autant de zones où le code legacy a été déployé puis oublié.

Le diagnostic se double de recommandations opérationnelles très concrètes. Le NCSC demande aux organisations de cartographier en priorité leur attack surface internet-facing — passerelles VPN, portails SSO, API exposées, fronts de SaaS — puis de remonter vers le cloud et l'on-premises. Sur chaque actif, les équipes doivent activer les hot-patches automatiques quand ils existent, accepter par défaut les mises à jour des dispositifs embarqués et appliquer la méthodologie SSVC (Stakeholder Specific Vulnerability Categorisation) du SEI/CERT pour prioriser les patches selon l'exploitabilité réelle plutôt que le seul score CVSS.

Le billet aborde aussi un sujet sensible : la capacité des équipes ops à absorber le rythme. Beaucoup d'organisations fonctionnent avec un cycle de patching mensuel ou trimestriel, calé sur le Patch Tuesday Microsoft. Le NCSC prévient que cette cadence sera intenable : la fréquence des advisories critiques pourrait passer de quelques unités par mois à plusieurs dizaines par semaine sur certains périmètres. L'agence appelle à industrialiser les pipelines de tests de régression, à raccourcir les fenêtres de validation et à investir dans l'automatisation de bout en bout, du SBOM à la mise en production.

Côté contexte, le NCSC rappelle que le Royaume-Uni vit déjà sous tension. Selon le rapport annuel 2025 de l'agence, plusieurs incidents nationalement significatifs sont enregistrés chaque semaine, dont une majorité attribuée à des États hostiles. La patch wave annoncée s'inscrit dans ce paysage : un attaquant étatique disposant de ses propres modèles capable de fouiller le code public dispose d'une fenêtre d'opportunité courte mais massive entre la divulgation publique d'une faille et son patching effectif. Cette fenêtre, le NCSC veut la fermer.

Plusieurs autres agences se sont positionnées dans le sillage. La CISA américaine et l'ASD ACSC australienne ont publié le même 1er mai un guide commun intitulé Careful Adoption of Agentic Artificial Intelligence Services, qui aborde le pendant offensif : comment déployer des agents IA en interne sans amplifier soi-même la surface d'attaque. L'ANSSI, dans une communication informelle relayée par LeMagIT, a indiqué qu'elle préparait un guide équivalent en français pour les opérateurs d'importance vitale soumis à NIS2.

Sur le terrain, les éditeurs commencent à réagir. GitHub a annoncé une accélération du déploiement de son Dependabot enrichi par IA, capable de générer automatiquement des pull requests de remédiation. Snyk et Mend prévoient des mises à jour majeures de leurs scanners pour intégrer les CVE issues d'audits IA. Du côté des équipes blue team, le NCSC recommande de renforcer la collecte de logs eBPF et auditd, ainsi que la corrélation avec les flux de threat intelligence, pour détecter toute exploitation in-the-wild d'une vulnérabilité qui n'aurait pas encore été patchée.

Pourquoi c'est important

L'avertissement du NCSC ne décrit pas une menace future : il acte un basculement déjà engagé. Le coût marginal d'un audit de code par un modèle IA frontier est passé en deux ans de plusieurs milliers d'euros par projet à quelques dizaines, parfois quelques unités. Cette baisse touche autant les défenseurs que les attaquants. Les groupes ransomware comme LockBit ou Akira, déjà dotés de capacités industrielles, n'ont besoin que d'un accès API à un modèle puissant pour scanner les binaires de leurs cibles à la recherche de zero-days exploitables. Le déséquilibre temporaire en faveur des défenseurs — qui voient les vulnérabilités avant les attaquants — pourrait s'inverser dès qu'une fuite ou un poisonning de poids ouverts fournira un Mythos clandestin aux acteurs hostiles.

Pour les organisations soumises à NIS2 et DORA, l'enjeu est immédiat. Les deux textes imposent une gestion de la vulnérabilité documentée, avec une remédiation dans des délais raisonnables et proportionnés au risque. La notion de raisonnable va se durcir : si une faille critique reste non patchée plusieurs semaines après la disponibilité du correctif, et qu'un incident exploite cette faille, la défense de bonne foi sera plus difficile à plaider devant l'ANSSI ou l'ACPR. La patch wave réclame donc une révision des SLA internes et des contrats de tierce maintenance.

Sur le plan budgétaire, l'effet est double. À court terme, les équipes opérations doivent absorber un volume accru de patches sans dégrader la disponibilité des services en production. Les sociétés ayant investi dans la blue team automation — Ansible, Salt, Puppet, plateformes de patch management — récolteront les fruits de leur effort. Les autres devront recruter ou externaliser dans un marché tendu. À moyen terme, le coût de la non-conformité monte mécaniquement avec le rythme des divulgations : une organisation qui ne patche pas en quatorze jours s'expose à un risque réel d'amende et d'incident.

Au-delà de la mécanique compliance, la patch wave souligne une vérité dérangeante pour les éditeurs : leur rythme historique de release et de support n'est plus aligné avec celui de la découverte. Les LTS de cinq ou sept ans, héritage d'une époque où le code mûrissait lentement, vont se retrouver pris en tenaille entre la fréquence des CVE et l'incapacité des clients à upgrader rapidement. Le débat sur la responsabilité juridique des éditeurs vis-à-vis du code legacy non maintenu, déjà ouvert par la directive Cyber Resilience Act au niveau européen, va prendre une dimension nouvelle.

Ce qu'il faut retenir

• Cartographier la surface internet-exposée et y appliquer en priorité les patches IA-générés. Le NCSC recommande la méthode SSVC pour prioriser au-delà du seul CVSS.
• Industrialiser le patching : hot-patches automatiques, update-by-default sur l'embarqué, pipelines de tests automatisés. Les cycles trimestriels deviennent intenables.
• Aligner les SLA contractuels et les obligations NIS2/DORA sur la nouvelle cadence : un délai de remédiation raisonnable se mesure désormais en jours, plus en mois.