Dus Google wil nog steeds bepalen hoe snel iets gepatched is? Even afgezien van het feit, dat melden aan de maker essentieel is, is het ook belangrijk om naar andere dingen te kijken. Bij een aangevallen zero-day is het snel melden goed en moet er bij voorkeur een voorstel voor mitigatie zijn. Bij een niet aangevallen probleem, lijkt het me zinnig om op aanvallen te monitoren en anders in goed overleg met de maker te publiceren. Afhankelijk van de plek waar het lek zit, kan fixen binnen een krap tijdsbestek tot andere problemen leiden. Programmeurs zijn mensen kunnen fouten maken, zeker onder tijdsdruk. Dus als een maker van software besluit om eerst een patch uit te brengen, die het exploiteren van het lek bemoeilijkt en pas later de definitieve patch, zou Google moeten wachten tot dat laatste is gebeurd, ongeacht of dit binnen 10 dagen is of binnen 120 dagen.

Hoop dat ze ook uitzonderingen kunnen maken op deze regel.

Ter illustratie, een bug in SMB2 kan dan wel gepatched zijn, maar een wereldwijde uitrol van de updates is wel erg moeilijk om dit binnen de gestelde termijn ook nog te doen.

Google is wat clemente naar Microsoft geworden, ondanks dat die zo traag patcht. Het belang zou ik niet weten want Google doet niks met Microsoft software. Je zou zeggen waar maken ze zich druk om.

Het is van de zotte dat ze niet secure coden daar. Het lijkt wel of er een stel beginners zitten. En als je kijkt in welke versies de exact zelfde fouten zitten is dat reused code.
ja, dan heb je wel even nodig om de fout te verhelpen.
Het is een schandalig bedrijf als je kijkt naar het aantal cvss3>9 van de afgelopen tijd.

Waarom zo laat?,het komt toch juist ten goede als kwetsbaarheden gelijk worden gemeld?. Dan kan er tot er een patch is toch meteen aan een workout worden gewerkt?. Op deze manier kan je een hoop ellende voor zijn.

90 dagen is zowat 3 maanden. Als een softwaremaker in die tijd niet in staat is om een lek te dichten dan is er iets goed mis met die softwaremaker.

Ooit was het gangbaar om te doen wat jij voorstelt: een lek melden bij de maker en het pas openbaar maken nadat het gedicht was. Het bleek dat meerdere softwarebedrijven, waaronder heel grote, er bij die benadering domweg geen prioriteit aan gaven om lekken te dichten en dat die er wel heel lang in konden blijven zitten. Dat is problematisch omdat als iemand die het lek netjes meldt het weet te vinden je er niet vanuit kan gaan dat niemand die het lek zou misbruiken het weet te vinden.

Daarom nam een aantal mensen een andere houding aan: meteen het lek openbaren, zodat softwaremakers wel gedwongen waren er de hoogst mogelijke prioriteit aan te geven. De redenatie was dat het bestaan van het lek op zich de software onveilig maakte, een ander kan het immers ook vinden, en dat dit de snelste weg naar veiligheid was.

Maar natuurlijk is dat wat te kort door de bocht, een lek dat open en bloot op straat ligt heeft een aanzienlijk grotere kans misbruikt te worden dan een lek dat niet algemeen bekend is. Sofwarebedrijven kwamen daarom als compromis met het idee van "responsible disclosure": meld het, houdt het nog een zekere periode onder de pet, maar niet onbeperkt, zodat er wél een deadline is die druk op de ketel zet om het op te lossen, maar niet meteen alle misbruiksluizen open gezet worden door directe publicatie.

Als je de deadline weer loslaat dan kan je erop wachten dat er bedrijven zijn die als ze de druk niet meer voelen om de lekken die gemeld worden te dichten het laten versloffen, en als dat gebeurt kan je erop wachten dat een deel van de mensen die lekken vinden ze weer meteen openbaar gaan maken.

Dat 90 dagen best lang is wordt duidelijk als je het vergelijkt met hoe het Linux kernel team met security bugs omgaat: men wil ze zo snel mogelijk in de openbaarheid hebben, en houdt een termijn aan van onmiddelijk tot enkele weken na de melding, maar liever dagen dan weken, met een dag of 7 als typische termijn. Als die dat kunnen, waarom zou het een ander 13 keer zoveel tijd moeten kosten? Dan lijkt men er nog steeds geen hoge prioriteit aan te geven. Google faciliteert die lage prioriteit wel met 90 dagen.

https://www.kernel.org/doc/html/v4.15/admin-guide/security-bugs.html

Ordianire machtstrijd. Google doet niets met de problemen en kwetsbaarheden rond Android Chrome die ze zelf hebben.

https://www.security.nl/posting/696617#posting697326 #nofurthercomment