Patch the Planet : réponse mondiale aux failles critiques découvertes par les agents
Ces deux derniers mois, nous avons réuni des responsables de maintenance, des chercheurs et des prestataires de sécurité pour corriger des vulnérabilités critiques dans PHP, un langage de programmation open source utilisé pour les sites et applications web. Calif a identifié une faille critique avec GPT‑5.6 Sol dans le cadre de notre initiative Patch the Planet(ouverture dans une nouvelle fenêtre). Wiz a également découvert et signalé les deux vulnérabilités de façon indépendante. Les responsables de la maintenance de PHP ont piloté les correctifs et leur publication. Nos équipes et des partenaires comme Wiz et Cloudflare ont apporté leurs recherches, leur soutien technique et leur coordination pour préparer des protections avant la divulgation.
Pour les organisations utilisant PHP, la priorité est désormais d’appliquer les correctifs. Nous publions un vérificateur de version PHP sous forme de compétence Codex(ouverture dans une nouvelle fenêtre) pour aider les exploitants à repérer les versions potentiellement vulnérables et, avec les recommandations de PHP et de leurs prestataires, à déterminer les mises à jour nécessaires.
Vu la gravité de ces failles et l’usage répandu de PHP, nous considérons qu’il s’agit d’un des problèmes de sécurité les plus lourds de conséquences de ces dernières années. Cela montre que l’IA peut révéler des failles ayant un impact à l’échelle d’Internet, mais ces mêmes capacités peuvent aussi aider les attaquants à développer rapidement des outils offensifs et des exploits.
À notre connaissance, l’IA de pointe a trouvé ces vulnérabilités avant les attaquants, ouvrant une fenêtre d’action pour les défenseurs afin que les responsables de maintenance et les prestataires de sécurité préparent correctifs et protections avant la divulgation.
Pour élargir l’accès des défenseurs à ces capacités, nous avons engagé un milliard de dollars pour subventionner l’accès à Daybreak via Daybreak pour les défenseurs en première ligne, destiné aux organisations qui protègent des services essentiels avec des moyens de sécurité limités.
Aussi graves soient-ils, ces bugs figurent parmi plusieurs vulnérabilités majeures déjà découvertes que nous travaillons à corriger. Nous prévoyons une forte hausse de ces découvertes dans les mois à venir. Forts de notre expérience, nous proposons une approche adaptée à l’ère de l’IA pour répondre aux vulnérabilités critiques des logiciels courants, et invitons la communauté de la sécurité à améliorer ce cadre. Il réunit nos modèles, notre expertise en sécurité et les responsables de maintenance pour transformer les découvertes en protections et bâtir une réponse capable de suivre les progrès de l’IA.
Déployer un correctif peut nécessiter de l’adapter à d’anciennes versions, de préparer des mesures d’atténuation chez les prestataires et de mettre à jour les systèmes de nombreuses organisations. Un processus reproductible aide ces équipes à agir vite à mesure que les découvertes de vulnérabilités se multiplient.
Avec Patch the Planet, nous avons fourni expertise en sécurité et accès aux modèles pour soutenir la réponse concernant PHP, et collaboré avec les responsables de maintenance et les partenaires de recherche pour tester les correctifs et préparer des recommandations. Nous avons aussi coordonné les protections des systèmes touchés avec les fournisseurs d’infrastructure et sollicité les agences publiques de cybersécurité pour diffuser les recommandations aux organisations critiques. Cela a soutenu la réponse pilotée par les responsables de maintenance et aidé d’autres défenseurs à se préparer.
Pour certaines découvertes, les chercheurs peuvent travailler directement avec les responsables de maintenance du logiciel pour étudier le problème et élaborer un correctif. D’autres exigent une réponse plus large, car elles touchent de nombreux produits ou parce que distributeurs et prestataires ont besoin de temps pour préparer mises à jour et protections. Ce temps peut manquer si les capacités de pointe devancent peu celles largement accessibles. Dans ces cas, le cadre proposé peut aider les responsables de maintenance à identifier les acteurs à mobiliser et à coordonner le travail. La réponse peut comporter cinq étapes :
Confirmer et corriger la vulnérabilité en amont. Le responsable de maintenance, les chercheurs et les partenaires techniques essentiels confirment la découverte, évaluent son impact, puis élaborent et testent un correctif. Ce processus inclut des tests adversariaux avec des modèles de pointe pour rechercher des moyens de contourner le correctif et des variantes de la vulnérabilité.
Laisser aux organisations touchées le temps d’agir. Nous proposons un cadre pour déterminer quelles organisations doivent être informées en avance afin de préparer des protections, les responsables de maintenance décidant qui impliquer. Nous aidons aux prises de contact, aux accords de partage d’informations et à la coordination entre équipes. Un distributeur peut adapter un correctif à une ancienne version, un hébergeur tester une mesure d’atténuation et un prestataire de sécurité préparer des mesures de détection ou de prévention, dont des règles de pare-feu applicatif web (WAF).
Se coordonner avec les partenaires publics pour protéger les systèmes critiques. Les agences publiques jouent un rôle essentiel pour coordonner une réponse élargie et transmettre les recommandations de sécurité aux organisations chargées d’infrastructures critiques et d’autres services essentiels. Pour PHP, nous avons travaillé avec nos partenaires à mobiliser plusieurs entités du gouvernement américain, dont la Super Intelligence Force de la Maison-Blanche, le Bureau du directeur national de la cybersécurité (ONCD) et l’Agence de cybersécurité et de sécurité des infrastructures (CISA), ainsi que des partenaires internationaux.
Préparer les mises à jour des produits touchés. Une fois le correctif, les recommandations et les plans de divulgation stabilisés, les responsables de maintenance peuvent mobiliser d’autres distributeurs, hébergeurs, prestataires, équipes d’intervention et exploitants pour préparer les mises à jour et combler les lacunes de couverture.
Dès qu’un correctif est disponible, publier des recommandations et soutenir son déploiement. Les recommandations publiques aident à évaluer l’exposition, à trouver des mises à jour officielles ou des mesures d’atténuation provisoires et à vérifier qu’un correctif est actif. La réponse se poursuit pendant que les exploitants déploient les mises à jour et signalent leurs besoins d’aide.
Le cadre proposé tient compte du rôle protecteur d’une organisation, notamment envers ses propres systèmes et clients, du temps nécessaire pour agir et de sa capacité à gérer des informations sensibles. Les mêmes critères s’appliqueraient aux organisations comparables, les responsables de maintenance décidant qui impliquer avant la divulgation.
Chaque participant reçoit les informations nécessaires à son travail de protection, des journaux réseau contenant des indicateurs de compromission aux preuves de concept d’exploitation fonctionnelles, plus sensibles. Même des détails limités peuvent révéler une vulnérabilité : nous mettons donc en balance le risque de leur partage et la protection qu’ils permettent.
Les équipes suivant ce cadre travailleraient avec les responsables de maintenance pour laisser aux défenseurs le temps de se préparer et revoir le calendrier en cas d’exploitation active, de fuite, de correctif public révélateur ou de risque accru pour les utilisateurs dû à une remédiation au point mort.
Le site Patch the Planet(ouverture dans une nouvelle fenêtre) rassemble les divulgations et recommandations publiques pour aider les exploitants à identifier les systèmes touchés, trouver la bonne mise à jour et vérifier le bon fonctionnement du logiciel mis à jour. Pour PHP, il renvoie au correctif officiel et aux instructions de mise à niveau des responsables de maintenance, ainsi qu’aux recherches techniques de nos partenaires. Les recommandations couvrent aussi les mesures d’atténuation provisoires, le recours à un prestataire ou à un expert, la sauvegarde et la restauration. Les protections provisoires peuvent réduire les risques, mais nous préciserons leurs limites et les compromis opérationnels associés.
Les exploitants peuvent suivre les recommandations de la CISA sur la priorisation et la remédiation(ouverture dans une nouvelle fenêtre) pour évaluer l’urgence selon l’exposition, l’exploitation et l’impact potentiel. Cela peut nécessiter un correctif d’urgence, une atténuation immédiate ou une mise à jour planifiée, avec, si nécessaire, un triage forensique pour déterminer si les systèmes sont déjà compromis. Les priorités doivent être réévaluées selon l’évolution de la situation, avec une voie claire vers une remédiation durable.
La coordination mondiale repose sur les personnes qui assurent la maintenance des logiciels. De nombreux projets sont gérés par de petites équipes qui examinent les signalements de sécurité en parallèle du développement courant. Ces équipes ont besoin d’aide pour distinguer les nouveaux problèmes des doublons, évaluer leur impact et tester les correctifs sur les versions prises en charge. Nous soutenons ce travail par des financements, l’accès à des modèles performants et une aide concrète en ingénierie.
Les capacités avancées de l’IA progressent dans tout le secteur. Nous pensons que l’IA aidera de plus en plus les défenseurs à trouver des vulnérabilités, surveiller les systèmes et répondre aux menaces. Nous investissons dans des modèles, des outils et des partenariats pour aider les défenseurs à exploiter ces capacités.
Nos investissements incluent des abonnements pour tous les responsables de maintenance via Codex pour l’open source et le parrainage direct de projets tels que la Fondation Rust(ouverture dans une nouvelle fenêtre), pour soutenir les responsables de maintenance et les travaux techniques. Chaque projet fixe ses propres priorités. Des tests et processus de sécurité réutilisables peuvent réduire l’effort nécessaire pour traiter les découvertes futures. Les projets open source peuvent candidater à Patch the Planet(ouverture dans une nouvelle fenêtre) pour bénéficier d’un soutien concret.
Nous calibrons aussi des classificateurs de blocage supplémentaires pour Daybreak afin de réduire les risques d’utilisation abusive. Cela implique des compromis difficiles : les garde-fous contre les abus peuvent aussi bloquer des travaux de sécurité légitimes. Un large accès à des modèles performants et des protections efficaces contre les abus sont tous deux essentiels. Notre objectif est de préserver les capacités dont les défenseurs ont besoin pour détecter et corriger les vulnérabilités, tout en limitant les usages nuisibles. Nous continuerons à affiner cet équilibre au fil des progrès et des enseignements tirés de l’utilisation de ces outils.
À mesure que les modèles progressent, les possibilités vont au-delà de la détection et de la correction de vulnérabilités isolées. Nous voulons aider les ingénieurs à concevoir des logiciels plus sûrs dès le départ. Améliorer un composant très utilisé peut prévenir des bugs ou limiter leur impact dans de nombreux produits et services.
L’IA peut aider les ingénieurs à comprendre le code existant, préparer des modifications et créer des tests, tandis que les responsables de maintenance et les experts en sécurité vérifient que ces changements préservent le fonctionnement dont dépendent les utilisateurs. Nous voyons des possibilités dans plusieurs domaines :
Un code sécurisé dès le départ. Les modèles de programmation peuvent aider les développeurs à choisir des paramètres par défaut plus sûrs, à bien utiliser les bibliothèques de sécurité et à repérer les schémas risqués pendant l’écriture du code. Prévenir les vulnérabilités lors du développement réduit les correctifs d’urgence pour les responsables de maintenance et les utilisateurs.
Des logiciels garantissant la sûreté mémoire. Migrer les composants critiques vers des langages garantissant la sûreté mémoire peut éliminer des catégories courantes d’erreurs de mémoire. L’IA peut faciliter les migrations, avec des tests et une revue par des experts pour vérifier le comportement et la compatibilité.
La vérification formelle. Des preuves mathématiques peuvent montrer que des composants critiques satisfont des propriétés de sécurité précises sous des hypothèses données. Appliquer ces méthodes à des composants très utilisés pourrait éliminer des catégories de vulnérabilités dans les services et infrastructures critiques qui en dépendent.
Une isolation renforcée. Les systèmes doivent être protégés contre les vulnérabilités qui n’ont pas encore été découvertes ou corrigées. Exécuter les logiciels qui traitent des fichiers, images ou médias non fiables dans des bacs à sable strictement restreints peut limiter les dégâts en cas de compromission. L’IA peut aider les ingénieurs à tester et renforcer les technologies de mise en bac à sable courantes, améliorant ainsi la protection de nombreuses applications.
Nous partageons notre approche pour que responsables de maintenance, chercheurs, équipes d’intervention, prestataires et exploitants contribuent à la rendre opérationnelle. Nous voulons comprendre où elle serait utile, où elle pourrait ajouter des délais ou des contraintes, et ce qui nous a échappé. Des exemples de divulgations passées seraient particulièrement utiles.
Nous nous intéressons notamment aux points suivants :
Les délais de divulgation. De combien de temps les responsables de maintenance, les exploitants et les défenseurs ont-ils besoin pour préparer et déployer des correctifs fiables ? Quels éléments devraient déclencher une divulgation anticipée, surtout lorsque certains utilisateurs peuvent être protégés avant les autres ?
L’application de correctifs d’urgence. Dans quels cas, s’il y en a, les gouvernements ou d’autres exploitants devraient-ils exploiter une vulnérabilité pour corriger des systèmes qu’ils possèdent ou sont autorisés à gérer, après en avoir perdu l’accès administrateur ? Quels garde-fous faudrait-il appliquer ? À terme, on peut imaginer une recherche permanente des vulnérabilités connues à l’échelle d’Internet, avec notification aux propriétaires des sites lorsqu’une faille est détectée, ou application d’un correctif au système.
L’alerte anticipée. Qui doit être averti en avance pour prendre des mesures de protection utiles, y compris parmi les défenseurs que nous risquons d’oublier ? Quand des notifications échelonnées sont-elles plus efficaces qu’une alerte simultanée à un groupe élargi, et comment mettre en balance la couverture et le risque de fuite ?
Les paquets logiciels sécurisés par défaut. Comment aider à détecter et corriger les vulnérabilités des paquets en aval en attendant les correctifs en amont, ou rétroporter des correctifs vers d’anciennes versions qui ne reçoivent plus de mises à jour de sécurité ? Quels tests et quelle maintenance en feraient des options fiables lorsqu’une mise à niveau rapide n’est pas possible ?
Nous souhaitons aussi des recommandations d’experts indépendants en sécurité capables d’examiner l’approche, de remettre en question ses hypothèses et d’en repérer les lacunes. Vos contributions nous aideront à affiner la réponse et à prioriser le soutien. Faites-nous part de vos retours ici(ouverture dans une nouvelle fenêtre).
