Patch the Planet: wereldwijde coördinatie van respons terwijl agenten kritieke kwetsbaarheden ontdekken

In de afgelopen twee maanden hebben we een coalitie geleid van maintainers, onderzoekers en beveiligingsproviders om kritieke kwetsbaarheden aan te pakken in PHP, een opensources programmeertaal die wordt gebruikt voor het draaien van websites en webapplicaties. Binnen ons Patch the Planet-initiatief identificeerde Calif een kritieke fout met behulp van GPT-5.6 Sol; onafhankelijk hiervan ontdekte en rapporteerde Wiz beide kwetsbaarheden. De maintainers van PHP leidden de fixes en de release, waarbij onze teams en partners zoals Wiz, Cloudflare en anderen bijdroegen met onderzoek, technische ondersteuning en coördinatie om bescherming voor te bereiden vóór de openbaarmaking.

Voor organisaties die PHP gebruiken, is de prioriteit nu het toepassen van de fixes. We delen een PHP-versiecontroleur als een Codex-skill om operators te helpen potentieel kwetsbare PHP-versies te identificeren en, samen met de richtlijnen van PHP en hun providers, te bepalen welke updates van toepassing zijn.

Gezien de ernst van deze fouten en het wijdverbreide gebruik van PHP, beschouwen we dit als een van de meest impactvolle beveiligingsproblemen in recent geheugen. Het onderstreept hoe AI beveiligingsfouten met een impact op internet-schaal kan ontdekken, maar dat dezelfde mogelijkheden aanvallers ook kunnen helpen om snel offensieve tools en exploits te ontwikkelen.

Voor zover wij weten, hebben frontier AI-modellen deze kwetsbaarheden gevonden voordat aanvallers dat deden, waardoor er een Defender’s Window ontstond voor maintainers en beveiligingsproviders om fixes en bescherming voor te bereiden vóór de openbaarmaking.

Om meer verdedigers te helpen deze mogelijkheden te benutten, hebben we 1 miljard dollar aan gesubsidieerde Daybreak-toegang toegezegd via Daybreak for Frontline Defenders, gericht op organisaties met beperkte beveiligingsmiddelen die essentiële diensten beschermen.

Hoewel deze bugs significant zijn, maken ze deel uit van verschillende belangrijke kwetsbaarheden die we al hebben gevonden en proberen op te lossen. We verwachten dat soortgelijke bevindingen in de komende maanden scherp zullen toenemen. Op basis van onze ervaringen tot nu toe delen we een voorgestelde aanpak, passend voor het AI-tijdperk, om te reageren op kritieke kwetsbaarheden in veelgebruikte software. We vragen de beveiligingsgemeenschap om te helpen dit raamwerk te verbeteren. Het brengt onze modellen, beveiligingsexpertise en maintainers samen om bevindingen om te zetten in bescherming en een respons op te bouwen die kan schalen naarmate AI-mogelijkheden vorderen.

Een wereldwijde respons coördineren

Het in gebruik nemen van een fix kan betekenen dat deze moet worden aangepast voor oudere releases, dat provider-mitigaties moeten worden voorbereid en dat systemen in veel organisaties moeten worden bijgewerkt. Een herhaalbaar proces helpt deze teams snel te handelen naarmate er meer kwetsbaarheden worden ontdekt.

Via Patch the Planet hebben we beveiligingsexpertise en modeltoegang bijgedragen om de PHP-respons te ondersteunen, en hebben we samengewerkt met maintainers en onderzoekspartners om fixes te testen en richtlijnen voor te bereiden. We hebben ook geholpen bij de coördinatie met infrastructuurproviders voor bescherming van getroffen systemen en zijn in contact getreden met overheidsinstanties voor cybersecurity om te zorgen dat de richtlijnen kritieke organisaties bereiken. Dit ondersteunde de door maintainers geleide respons en hielp andere verdedigers zich voor te bereiden.

Voor sommige bevindingen kunnen onderzoekers direct met de maintainers van de software werken om het probleem te onderzoeken en een fix te ontwikkelen. Andere vereisen een bredere respons omdat ze veel producten beïnvloeden, of omdat distributeurs en serviceproviders tijd nodig hebben (die schaars kan zijn als frontier-mogelijkheden niet veel verder zijn dan die welke breed beschikbaar zijn) om updates en bescherming voor te bereiden. In die gevallen kan het voorgestelde raamwerk maintainers helpen te identificeren wie erbij betrokken moet worden en het werk coördineren. De respons kan uit vijf fasen bestaan:

1. Valideren en herstellen van de upstream-kwetsbaarheid. De maintainer, onderzoekers en essentiële technische partners bevestigen de bevinding, beoordelen de impact en ontwikkelen en testen een fix. Dit proces omvat adversarial testing met frontier-modellen om te zoeken naar manieren om de patch te omzeilen en naar gerelateerde varianten van de kwetsbaarheid.
2. Getroffen organisaties tijd geven om actie te ondernemen. We stellen een raamwerk voor om te overwegen welke organisaties voorafgaande informatie nodig hebben om bescherming voor te bereiden, terwijl maintainers beslissen wie ze erbij betrekken. We helpen bij outreach, overeenkomsten voor informatie-uitwisseling en coördinatie tussen teams. Een distributeur kan een fix aanpassen voor een oudere release, een hostingprovider kan een mitigatie testen en een beveiligingsprovider kan detectie- of preventiemaatregelen voorbereiden, waaronder web application firewall (WAF) regels.
3. Coördineren met overheidspartners om kritieke systemen te helpen beschermen. Overheidsinstanties spelen een essentiële rol bij het coördineren van een bredere respons en het helpen van beveiligingsrichtlijnen om organisaties te bereiken die verantwoordelijk zijn voor kritieke infrastructuur en andere essentiële diensten. In het geval van PHP hebben we, in samenwerking met onze partners, contact gezocht met meerdere delen van de Amerikaanse overheid, waaronder de Super Intelligence Force van het Witte Huis, het Office of the National Cyber Director (ONCD), de Cybersecurity and Infrastructure Security Agency (CISA), en internationale partners om deze inspanning te ondersteunen.
4. Updates voorbereiden over alle getroffen producten. Zodra de fix, de richtlijnen en de plannen voor openbaarmaking stabiel zijn, kunnen maintainers extra distributeurs, hosting- en serviceproviders, responsteams en operators betrekken om updates voor te bereiden en gaten in de dekking te dichten.
5. Zodra een patch beschikbaar is, richtlijnen publiceren en implementatie ondersteunen. Publieke richtlijnen helpen mensen hun blootstelling te beoordelen, gezaghebbende updates of interim-mitigaties te vinden en te controleren of een fix is geïmplementeerd. De respons gaat door terwijl operators updates uitrollen en rapporteren waar ze hulp nodig hebben.

Het voorgestelde raamwerk houdt rekening met de beschermende rol van een organisatie, inclusief het beschermen van eigen systemen en klanten, de tijd die nodig is om te handelen en het vermogen om met gevoelige informatie om te gaan. Dezelfde criteria zouden gelden voor vergelijkbare organisaties, waarbij maintainers beslissen wie ze vóór de openbaarmaking betrekken.

Elke deelnemer ontvangt de informatie die nodig is om hun beschermende werk uit te voeren, van netwerklogs met indicatoren van compromittering tot meer gevoelige working proof-of-concept exploits. Zelfs beperkte details kunnen een kwetsbaarheid onthullen, dus we wegen het risico van het delen ervan af tegen de bescherming die het mogelijk maakt.

Teams die dit raamwerk volgen, zouden samenwerken met maintainers om verdedigers tijd te geven om zich voor te bereiden en de tijdlijn opnieuw te beoordelen als er sprake is van actieve exploitatie in het wild, een lek, een onthullende publieke patch, of een verhoogd risico voor gebruikers door vertraagde herstelwerkzaamheden.

De website van Patch the Planet brengt publieke openbaarmakingen en richtlijnen samen om operators te helpen getroffen systemen te identificeren, de juiste update te vinden en te verifiëren dat de bijgewerkte software correct draait. Voor PHP verwijst het naar de officiële patch en upgrade-instructies van de maintainers en het technische onderzoek van onze partners. De richtlijnen behandelen ook interim-mitigaties, wanneer een provider of expert moet worden ingeschakeld, en backup en recovery. Interim-beschermingen kunnen het risico verminderen, maar we zullen hun beperkingen en operationele trade-offs duidelijk maken.

Operators kunnen de richtlijnen van CISA over prioritering en herstel gebruiken om te beoordelen hoe snel ze moeten handelen op basis van blootstelling, exploitatie en potentiële impact. Dat kan betekenen: noodzakelijke patching, onmiddellijke mitigatie of een geplande update, samen met forensische triage waar gerechtvaardigd om te beoordelen of systemen al zijn gecompromitteerd. Prioriteiten moeten worden herzien naarmate omstandigheden veranderen, met een duidelijk pad naar blijvend herstel.

Maintainers de capaciteit en middelen geven om te reageren

Wereldwijde coördinatie hangt af van de mensen die de software onderhouden. Veel projecten worden beheerd door kleine teams die beveiligingsrapporten beoordelen naast routineontwikkeling. Deze teams hebben hulp nodig bij het scheiden van nieuwe problemen van duplicaten, het beoordelen van de impact en het testen van fixes over ondersteunde releases. We ondersteunen dat werk met financiering, toegang tot geavanceerde modellen en directe engineeringhulp.

Krachtige AI-mogelijkheden maken een snelle ontwikkeling door in de hele sector, en we verwachten dat AI een groeiende rol zal spelen bij het helpen van verdedigers om kwetsbaarheden te vinden, systemen te monitoren en te reageren op dreigingen. We investeren in modellen, tools en partnerschappen om verdedigers te helpen deze mogelijkheden in te zetten.

Onze investeringen omvatten abonnementen voor alle maintainers via Codex for OSS en directe sponsoring van projecten zoals de Rust Foundation voor maintainers en technisch werk. Elk project bepaalt zijn eigen prioriteiten. Herbruikbare tests en beveiligingsworkflows kunnen de inspanning verminderen die nodig is om toekomstige bevindingen af te handelen. Open-source projecten kunnen zich aanmelden bij Patch the Planet voor directe ondersteuning.

We kalibreren daarnaast extra blokkerende classifiers voor Daybreak om het potentieel voor misbruik te verminderen. Dit brengt moeilijke trade-offs met zich mee: waarborgen die bedoeld zijn om misbruik te voorkomen, kunnen ook legitiem beveiligingswerk blokkeren. Zowel brede toegang tot krachtige modellen als effectieve bescherming tegen misbruik zijn cruciaal. Ons doel is om de mogelijkheden te behouden die verdedigers nodig hebben om kwetsbaarheden te vinden en te herstellen, terwijl we schadelijk gebruik beperken. We zullen deze balans blijven verfijnen naarmate de mogelijkheden vorderen en we leren van hoe deze tools worden gebruikt.

Veiligere softwarefundamenten bouwen

Naarmate modellen krachtiger worden, strekt de mogelijkheid zich uit verder dan het vinden en herstellen van individuele kwetsbaarheden. We willen ingenieurs helpen om vanaf het begin veiligere software te bouwen. Verbeteringen aan een veelgebruikt component kunnen bugs voorkomen of hun impact beperken over veel producten en diensten.

AI kan ingenieurs helpen bestaande code te begrijpen, wijzigingen voor te bereiden en tests te ontwikkelen, terwijl maintainers en beveiligingsexperts verifiëren dat deze wijzigingen het gedrag behouden waar gebruikers op vertrouwen. We zien kansen in verschillende gebieden:

• Veilige code vanaf het begin. Coding-modellen kunnen ontwikkelaars helpen veiligere standaardinstellingen te kiezen, beveiligingsbibliotheken correct te gebruiken en risicovolle patronen te herkennen tijdens het schrijven. Het voorkomen van kwetsbaarheden tijdens de ontwikkeling betekent minder noodpatches voor maintainers en gebruikers.
• Memory-safe software. Het overzetten van kritieke componenten naar memory-safe talen kan veelvoorkomende klassen van geheugenfouten elimineren. AI kan helpen bij migraties, met tests en expert-review om gedrag en compatibiliteit te controleren.
• Formele verificatie. Mathematische bewijzen kunnen aantonen dat kritieke componenten voldoen aan gespecificeerde beveiligingseigenschappen onder gestelde aannames. Het toepassen van deze methoden op veelgebruikte componenten zou kunnen helpen om klassen van kwetsbaarheden uit te sluiten in de diensten en kritieke infrastructuur die ervan afhankelijk zijn.
• Sterkere isolatie. Systemen hebben bescherming nodig tegen kwetsbaarheden die nog niet zijn gevonden of hersteld. Software die onbetrouwbare bestanden, afbeeldingen of media verwerkt, in strikt beperkte sandboxes draaien kan de schade beperken als het gecompromitteerd raakt. AI kan ingenieurs helpen veelgebruikte sandboxing-technologieën te testen en te versterken, waardoor de bescherming over veel applicaties wordt verbeterd.

Help ons deze aanpak te verbeteren

We delen onze aanpak zodat maintainers, onderzoekers, responsteams, providers en operators kunnen helpen deze werkbaar te maken. We willen begrijpen waar het zou helpen, waar het vertraging of last zou kunnen toevoegen, en wat we over het hoofd hebben gezien. Voorbeelden uit eerdere openbaarmakingen zouden bijzonder nuttig zijn.

We zijn specifiek geïnteresseerd in:

• Openbaarmakingsvensters. Hoeveel tijd hebben maintainers, operators en verdedigers nodig om betrouwbare fixes voor te bereiden en uit te rollen? Welk bewijs zou een eerdere openbaarmaking moeten triggeren, vooral wanneer sommige gebruikers sneller beschermd kunnen worden dan anderen?
• Noodpatching. Wanneer, indien ooit, zouden overheden of andere operators een kwetsbaarheid moeten gebruiken om systemen te patchen die zij bezitten of bevoegd zijn te beheren nadat ze administratieve toegang zijn verloren? Welke waarborgen moeten gelden? We kunnen ons een eindstadium voorstellen van internet-brede, altijd-aan scanning voor bekende kwetsbaarheden, waarbij ofwel site-eigenaren worden geïnformeerd wanneer er een wordt gedetecteerd, of het systeem wordt gepatcht.
• Vroege melding. Wie heeft voorafgaande waarschuwing nodig om een nuttige beschermende actie te ondernemen, inclusief verdedigers die we zouden kunnen missen? Wanneer werken gefaseerde meldingen beter dan het tegelijkertijd informeren van een grotere groep, en hoe moeten we dekking afwegen tegen het risico op lekken?
• Secure-by-default softwarepakketten. Hoe kunnen we helpen kwetsbaarheden in downstream-pakketten te identificeren en te herstellen terwijl upstream-fixes in afwachting staan, of fixes backporten naar oudere versies die geen beveiligingsupdates meer ontvangen? Welke testen en onderhoud zouden deze pakketten betrouwbare opties maken wanneer een tijdige upgrade niet haalbaar is?

We verwelkomen ook aanbevelingen voor onafhankelijke beveiligingsexperts die de aanpak kunnen beoordelen, aannames kunnen uitdagen en gaten kunnen identificeren. Uw input zal ons helpen de respons te verfijnen en ondersteuning te prioriteren.