Google verkort Project Zero’s openbaarmakingstermijn stapsgewijs naar 30 dagen

Google Project Zero zet de openbaarmakingstermijn vandaag op 90 dagen, verlaagt die op 2 februari 2027 naar 60 dagen en op 3 januari 2028 naar 30 dagen.

Een Nederlandse softwareleverancier die een melding van Project Zero krijgt, moet herstel en uitrol rond één vaste publicatiedatum plannen. De huidige termijn blijft voorlopig 90 dagen, maar de publicatiedatum volgt niet meer op een extra uitrolmaand na de patch. Dat kan bij een vroege reparatie juist meer tijd geven om de fix uit te rollen, en bij een late reparatie minder. Triage, herstel, testen en uitrol vallen zo onder één vooraf bekende openbaarmakingsdatum.

De klok loopt vanaf de melding

Full X betekent dat een leverancier vanaf de melding X dagen heeft om een patch beschikbaar te maken. Na die termijn publiceert Project Zero details, ongeacht of de fout is verholpen. Bij Full90 is dag 90 dus de vaste openbaarmakingsdatum. Dit geldt voor kwetsbaarheden die Project Zero aan een leverancier meldt, niet voor alle softwarelekken.

Sinds 2021 werkte Project Zero met een 90+30-regel. Leveranciers kregen 90 dagen om een kwetsbaarheid te verhelpen. Na een patch konden zij nog maximaal 30 dagen nemen om die bij gebruikers te krijgen. Die tweede klok kon de publicatie naar dag 120 schuiven als de patch aan het einde van de eerste periode verscheen. Tweakers beschrijft die oude route als maximaal 120 dagen tussen melding en openbaarmaking. Dat is geen termijn van 120 dagen om met repareren te beginnen: de eerste grens bleef dag 90.

De meeste uitzonderingen verdwijnen. Actief misbruik krijgt een aparte 7-dagenroute. Details die al publiek zijn, kunnen direct naar buiten; op verzoek van een leverancier kan Project Zero eerder publiceren. Het team meldt dat het in twaalf jaar vijf keer uitstel gaf om grootschalige schade te voorkomen.

De uitrol telt mee in beide richtingen

De wijziging verkort de tijd tussen patch en publicatie dus niet altijd. Verschijnt een patch op dag 47, dan zou de oude regel publicatie rond dag 77 geven. Onder Full90 wordt dat dag 90, dertien dagen later. Is de patch er pas op dag 90, dan vervalt juist de oude extra maand en verschijnen de details diezelfde dag.

Voor teams die software voor klanten onderhouden, verschuift druk naar releasebeheer. Een patch op dag 90 heeft binnen deze policy geen uitrolbuffer. Teams die alleen in vaste maandelijkse vensters publiceren, kunnen de datum missen. Vroege patches krijgen meer uitroltijd, maar openbaarmaking blijft op dag 90 staan.

Project Zero wil minder afhankelijk zijn van overleg over herstelstatus en uitstel. Het blijft fixes volgen en melden, maar die status bepaalt de publicatiedatum niet meer. De klok wordt voorspelbaarder en moet door Project Zero en leveranciers automatisch toepasbaar zijn. Leveranciers moeten triage, patchen, testen en verspreiden als één proces kunnen afhandelen.

AI zet beide kanten onder druk

Project Zero zegt dat taalmodellen aanvallers helpen kwetsbaarheden sneller te vinden en patches sneller terug te redeneren naar de fout die ze oplossen. Het team meldt dat het in bepaalde doelen van enkele vondsten per jaar naar meerdere per week ging. Project Zero stelt dat de ernst van een lek de impact meet, niet de kans dat aanvallers het ontdekken. Zo komen meer meldingen binnen terwijl technische details mogelijk sneller bruikbaar worden voor aanvallers.

In juli meldde Google dat het 1.072 lekken in twee Chrome-releases dichtte, meer dan in de 23 versies ervoor samen. In augustus vond Googles Mandiant-team ruim honderd kritieke kwetsbaarheden in gestolen software-repositories in twee dagen. Die voorbeelden laten zien hoe AI de snelheid van verdedigers kan vergroten. Project Zero wijst ook op het risico dat meerdere partijen dezelfde fout tegelijk ontdekken.

Anthropic onderzocht de andere kant van die klok. In een gecontroleerde test bouwde Mythos Preview acht exploitketens uit 21 Windows-kernelpatches. Het model werkte met oude en nieuwe programmabestanden in een afgeschermde omgeving, zonder netwerktoegang. De proef toont wat exploitontwikkeling met zulke informatie kan opleveren, niet dat aanvallers die ketens in echte systemen hebben ingezet.

De termijn is geen algemene norm

Project Zero zegt dat het leveranciers raadpleegde bij de nieuwe planning. Zij waarschuwden dat een onmiddellijke stap naar korte deadlines gebruikers met ongepatchte fouten kon blootstellen, ontwikkeltijd naar minder ernstige bugs kon trekken of sommige leveranciers kon ontmoedigen. Daarom loopt de overgang in drie stappen. Google noemt de termijnen uitdagend maar realistisch, maar publiceert geen onafhankelijke meting van het effect op gebruikers of uitroltijd.

Dit is geen wet of algemene plicht voor softwareleveranciers. De vaste klok geldt voor bevindingen die Project Zero zelf meldt; andere leveranciers volgen hun eigen afspraken. Bedrijven die software inkopen, blijven afhankelijk van de meld- en patchprocessen van hun leveranciers.

De data staan vast: Full60 begint op 2 februari 2027 en Full30 op 3 januari 2028. Voor een leverancier raakt de meldingsdatum tegelijk aan onderzoek, herstel, testen en distributie. Voor organisaties die die software gebruiken, blijft het verschil tussen een beschikbare patch en een geïnstalleerde patch bepalend. Een kortere openbaarmakingsklok verlaagt de blootstelling pas als de update de gebruikers op tijd bereikt.