Patch the Planet: gecoördineerde wereldwijde respons op kritieke kwetsbaarheden die agents ontdekken

De afgelopen twee maanden leidden we een coalitie van softwarebeheerders, onderzoekers en beveiligingsbedrijven om kritieke kwetsbaarheden in PHP aan te pakken, een opensourceprogrammeertaal voor websites en webapplicaties. Calif ontdekte met GPT‑5.6 Sol een kritiek beveiligingslek binnen ons initiatief Patch the Planet⁠(opent in een nieuw venster). Ook Wiz ontdekte en meldde beide kwetsbaarheden, onafhankelijk van Calif. De PHP-beheerders leidden de ontwikkeling en uitrol van de oplossingen. Onze teams en partners zoals Wiz en Cloudflare droegen bij met onderzoek, technische ondersteuning en coördinatie om vóór de openbaarmaking beschermingsmaatregelen voor te bereiden.

Voor organisaties die PHP gebruiken, heeft het toepassen van de oplossingen nu prioriteit. We delen een PHP-versiecontrole als Codex-skill⁠(opent in een nieuw venster) waarmee systeembeheerders mogelijk kwetsbare PHP-versies kunnen herkennen en, met de richtlijnen van PHP en hun leveranciers, kunnen bepalen welke updates nodig zijn.

Gezien de ernst van deze lekken en het wijdverbreide gebruik van PHP beschouwen we dit als een van de ingrijpendste beveiligingsproblemen van de afgelopen jaren. Dit laat zien hoe AI beveiligingslekken kan blootleggen met gevolgen voor het hele internet. Maar dezelfde mogelijkheden kunnen aanvallers ook helpen snel aanvalstools en exploits te ontwikkelen.

Voor zover wij weten, vond grensverleggende AI deze kwetsbaarheden eerder dan aanvallers. Dat gaf beheerders en beveiligingsbedrijven een voorsprong voor verdedigers om vóór de openbaarmaking oplossingen en beschermingsmaatregelen voor te bereiden.

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

Hoe ernstig ook, deze fouten zijn slechts enkele van de aanzienlijke kwetsbaarheden die we al hebben gevonden en proberen te verhelpen. We verwachten de komende maanden een sterke toename van soortgelijke vondsten. Op basis van onze ervaringen tot nu toe stellen we een aanpak voor die past bij het AI-tijdperk, om te reageren op kritieke kwetsbaarheden in veelgebruikte software. We vragen de beveiligingsgemeenschap dit kader te helpen verbeteren. Deze aanpak brengt onze modellen, beveiligingsexpertise en softwarebeheerders samen om bevindingen om te zetten in bescherming en een respons te ontwikkelen die kan meegroeien met de mogelijkheden van AI.

Een oplossing in gebruik nemen kan betekenen dat deze wordt aangepast voor oudere versies, dat leveranciers risicobeperkende maatregelen voorbereiden en dat systemen bij veel organisaties worden bijgewerkt. Een herhaalbaar proces helpt die teams snel te handelen naarmate er meer kwetsbaarheden worden ontdekt.

Via Patch the Planet boden we beveiligingsexpertise en toegang tot modellen ter ondersteuning van de PHP-respons. Met beheerders en onderzoekspartners testten we oplossingen en stelden we richtlijnen op. Ook hielpen we beschermingsmaatregelen voor getroffen systemen af te stemmen met infrastructuurleveranciers en schakelden we overheidsinstanties voor cyberveiligheid in om richtlijnen bij cruciale organisaties te krijgen. Dit ondersteunde de respons onder leiding van de beheerders en hielp andere verdedigers zich voor te bereiden.

Bij sommige bevindingen kunnen onderzoekers rechtstreeks met de softwarebeheerders samenwerken om het probleem te onderzoeken en een oplossing te ontwikkelen. Andere vereisen een bredere respons, omdat ze veel producten treffen of omdat distributeurs en dienstverleners tijd nodig hebben om updates en beschermingsmaatregelen voor te bereiden. Die tijd kan schaars zijn als grensverleggende mogelijkheden niet ver voorlopen op wat breed beschikbaar is. In die gevallen kan het voorgestelde kader beheerders helpen bepalen wie betrokken moet worden en het werk coördineren. De respons kan uit vijf fasen bestaan:

• De kwetsbaarheid in de bronsoftware bevestigen en verhelpen. De beheerder, onderzoekers en essentiële technische partners bevestigen de bevinding, beoordelen de impact en ontwikkelen en testen een oplossing. Daarbij testen ze met grensverleggende modellen vanuit het perspectief van een aanvaller, op zoek naar manieren om de patch te omzeilen en naar verwante varianten van de kwetsbaarheid.

• Getroffen organisaties tijd geven om te handelen. We stellen een kader voor om af te wegen welke organisaties vooraf informatie nodig hebben om beschermingsmaatregelen voor te bereiden. De beheerders beslissen wie ze erbij betrekken. We helpen bij het leggen van contacten, afspraken over informatiedeling en de coördinatie tussen teams. Een distributeur kan een oplossing aanpassen voor een oudere versie, een hostingprovider kan een risicobeperkende maatregel testen en een beveiligingsbedrijf kan detectie- of preventiemaatregelen voorbereiden, waaronder regels voor een webapplicatiefirewall (WAF).

• Afstemmen met overheidspartners om kritieke systemen te helpen beschermen. Overheidsinstanties spelen een essentiële rol bij het coördineren van een bredere respons en het verspreiden van beveiligingsrichtlijnen onder organisaties die verantwoordelijk zijn voor kritieke infrastructuur en andere essentiële diensten. Voor PHP hebben we samen met onze partners contact gezocht met verschillende onderdelen van de Amerikaanse overheid, waaronder de Super Intelligence Force van het Witte Huis, het Office of the National Cyber Director (ONCD) en de Cybersecurity and Infrastructure Security Agency (CISA), en met internationale partners om deze inspanning te ondersteunen.

• Updates voorbereiden voor getroffen producten. Zodra de oplossing, richtlijnen en plannen voor openbaarmaking vaste vorm krijgen, kunnen beheerders meer distributeurs, hosting- en dienstverleners, responsteams en systeembeheerders betrekken om updates voor te bereiden en hiaten in de bescherming aan te pakken.

• Zodra een patch beschikbaar is, richtlijnen publiceren en de uitrol ondersteunen. Openbare richtlijnen helpen mensen hun blootstelling te beoordelen, officiële updates of tijdelijke maatregelen te vinden en te controleren of een oplossing actief is. De respons gaat door terwijl systeembeheerders updates uitrollen en melden waar ze hulp nodig hebben.

Het voorgestelde kader houdt rekening met de beschermende rol van een organisatie, waaronder de bescherming van eigen systemen en klanten, de tijd die nodig is om te handelen en het vermogen om met gevoelige informatie om te gaan. Voor vergelijkbare organisaties zouden dezelfde criteria gelden. De beheerders bepalen wie ze vóór de openbaarmaking betrekken.

Elke deelnemer ontvangt de informatie die nodig is voor diens beschermende werk, van netwerklogs met aanwijzingen voor een inbraak tot gevoeligere, werkende proof-of-concept-exploits. Zelfs beperkte details kunnen een kwetsbaarheid onthullen. Daarom wegen we het risico van informatiedeling af tegen de bescherming die deze mogelijk maakt.

Teams die dit kader volgen, zouden met beheerders samenwerken om verdedigers voorbereidingstijd te geven. Ze zouden de planning herzien bij actief misbruik in de praktijk, een lek, een openbare patch die de kwetsbaarheid onthult of een verhoogd risico voor gebruikers doordat herstel uitblijft.

De website van Patch the Planet⁠(opent in een nieuw venster) bundelt openbaar gemaakte kwetsbaarheden en richtlijnen. Zo kunnen systeembeheerders getroffen systemen herkennen, de juiste update vinden en controleren of de bijgewerkte software goed werkt. Voor PHP verwijst de website naar de officiële patch- en upgrade-instructies van de beheerders en het technische onderzoek van onze partners. De richtlijnen behandelen ook tijdelijke maatregelen, wanneer een leverancier of expert nodig is, en back-ups en herstel. Tijdelijke beschermingsmaatregelen kunnen het risico verkleinen, maar we zullen de beperkingen en de afwegingen voor de bedrijfsvoering duidelijk benoemen.

Systeembeheerders kunnen CISA's richtlijnen voor prioritering en herstel⁠(opent in een nieuw venster) gebruiken om op basis van blootstelling, misbruik en mogelijke impact te beoordelen hoe snel ze moeten handelen. Dat kan betekenen: een spoedpatch, directe risicobeperkende maatregelen of een geplande update, zo nodig met forensische triage om vast te stellen of systemen al zijn gecompromitteerd. Bij veranderende omstandigheden moeten de prioriteiten opnieuw worden beoordeeld, met een duidelijk traject naar duurzaam herstel.

Wereldwijde coördinatie staat of valt met de mensen die de software onderhouden. Veel projecten worden beheerd door kleine teams die beveiligingsmeldingen beoordelen naast hun reguliere ontwikkelwerk. Die teams hebben hulp nodig om nieuwe problemen van dubbele meldingen te onderscheiden, de impact te beoordelen en oplossingen voor alle ondersteunde versies te testen. We ondersteunen dat werk met financiering, toegang tot krachtige modellen en praktische technische hulp.

In de hele sector nemen de mogelijkheden van krachtige AI toe. We verwachten dat AI een steeds grotere rol gaat spelen bij het helpen van verdedigers om kwetsbaarheden te vinden, systemen te bewaken en op dreigingen te reageren. We investeren in modellen, tools en samenwerkingen om verdedigers deze mogelijkheden te helpen benutten.

Onze investeringen omvatten abonnementen voor alle beheerders via Codex for OSS en directe sponsoring van projecten zoals de Rust Foundation⁠(opent in een nieuw venster) voor beheerders 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. Opensourceprojecten kunnen zich aanmelden bij Patch the Planet⁠(opent in een nieuw venster) voor praktische ondersteuning.

Ook stemmen we aanvullende blokkeringsclassificatoren voor Daybreak af om de kans op misbruik te helpen verkleinen. Daarbij zijn lastige afwegingen nodig: waarborgen tegen misbruik kunnen ook legitiem beveiligingswerk blokkeren. Zowel brede toegang tot krachtige modellen als effectieve bescherming tegen misbruik is essentieel. We willen de mogelijkheden behouden die verdedigers nodig hebben om kwetsbaarheden te vinden en te verhelpen, en tegelijk schadelijk gebruik beperken. We blijven die balans verfijnen naarmate de mogelijkheden toenemen en we leren van het gebruik van deze tools.

Naarmate modellen krachtiger worden, reiken de kansen verder dan het vinden en verhelpen van afzonderlijke kwetsbaarheden. We willen ontwikkelaars helpen om software vanaf het begin veiliger te bouwen. Verbeteringen aan een veelgebruikte component kunnen fouten voorkomen of de impact ervan beperken in tal van producten en diensten.

AI kan ontwikkelaars helpen bestaande code te begrijpen, wijzigingen voor te bereiden en tests te ontwikkelen. Beheerders en beveiligingsexperts controleren daarbij of de werking waarop gebruikers vertrouwen behouden blijft. We zien kansen op verschillende gebieden:

• Veilige code vanaf het begin. Programmeermodellen kunnen ontwikkelaars helpen veiligere standaardinstellingen te kiezen, beveiligingsbibliotheken correct te gebruiken en riskante patronen tijdens het programmeren op te sporen. Kwetsbaarheden voorkomen tijdens de ontwikkeling betekent minder spoedoplossingen voor beheerders en gebruikers.

• Geheugenveilige software. Kritieke componenten overzetten naar geheugenveilige talen kan veelvoorkomende categorieën geheugenfouten uitsluiten. AI kan helpen bij migraties, waarbij tests en beoordelingen door experts de werking en compatibiliteit controleren.

• Formele verificatie. Wiskundige bewijzen kunnen aantonen dat kritieke componenten onder vastgelegde aannames aan gespecificeerde beveiligingseigenschappen voldoen. Door deze methoden toe te passen op veelgebruikte componenten kunnen we mogelijk hele categorieën kwetsbaarheden uitsluiten in de diensten en kritieke infrastructuur die ervan afhankelijk zijn.

• Sterkere isolatie. Systemen hebben bescherming nodig tegen kwetsbaarheden die nog niet zijn gevonden of verholpen. Software die niet-vertrouwde bestanden, afbeeldingen of media verwerkt, kan in strikt afgeschermde sandboxes draaien. Dat kan de schade beperken als de software wordt gecompromitteerd. AI kan ontwikkelaars helpen veelgebruikte sandboxtechnologieën te testen en te versterken, en zo de bescherming in tal van applicaties verbeteren.

We delen onze aanpak zodat softwarebeheerders, onderzoekers, responsteams, leveranciers en systeembeheerders deze kunnen helpen werkbaar te maken. We willen begrijpen waar de aanpak zou helpen, waar deze vertraging of extra belasting kan opleveren en wat we over het hoofd hebben gezien. Voorbeelden van eerdere openbaarmakingen zouden bijzonder nuttig zijn.

We zijn vooral geïnteresseerd in:

• Termijnen voor openbaarmaking. Hoeveel tijd hebben softwarebeheerders, systeembeheerders en verdedigers nodig om betrouwbare oplossingen voor te bereiden en uit te rollen? Welke aanwijzingen moeten aanleiding geven tot eerdere openbaarmaking, vooral wanneer sommige gebruikers eerder beschermd kunnen worden dan andere?

• Spoedpatches. Wanneer zouden overheden of andere systeembeheerders, als dat überhaupt wenselijk is, een kwetsbaarheid mogen benutten om systemen te patchen die ze bezitten of bevoegd zijn te beheren, nadat ze de beheerderstoegang zijn kwijtgeraakt? Welke waarborgen moeten daarvoor gelden? We kunnen ons een toekomst voorstellen waarin het hele internet continu wordt gescand op bekende kwetsbaarheden. Bij detectie krijgt de website-eigenaar een melding of wordt het systeem gepatcht.

• Vroegtijdige kennisgeving. Wie moet vooraf gewaarschuwd worden om zinvolle beschermingsmaatregelen te kunnen nemen, inclusief verdedigers die we mogelijk over het hoofd zien? Wanneer werken gefaseerde meldingen beter dan het tegelijk informeren van een bredere groep, en hoe moeten we het bereik afwegen tegen het risico op lekken?

• Standaard veilige softwarepakketten. Hoe kunnen we kwetsbaarheden helpen opsporen en verhelpen in afgeleide pakketten zolang oplossingen in de bronsoftware nog ontbreken? Of oplossingen overzetten naar oudere versies die geen beveiligingsupdates meer krijgen? Welke tests en welk onderhoud zouden deze pakketten tot betrouwbare opties maken wanneer een tijdige upgrade niet haalbaar is?

Ook horen we graag welke onafhankelijke beveiligingsexperts de aanpak kunnen beoordelen, de aannames kritisch kunnen toetsen en hiaten kunnen opsporen. Jullie inbreng helpt ons de respons te verfijnen en prioriteiten te stellen voor de ondersteuning. Deel hier je feedback⁠(opent in een nieuw venster).