for noen dager siden Forskere fra Google Project Zero-teamet ga ut resultatene ved å oppsummere dataene på responstiden til produsentene før oppdagelsen av nye sårbarheter i produktene deres.
I samsvar med Googles retningslinjer, gis det 90 dager til å fjerne sårbarhetene identifisert av Google Project Zero-forskere, før de blir utgitt, og ytterligere offentliggjøring gis også. kan endres i ytterligere 14 dager med egen forespørsel.
Så i utgangspunktet, etter 104 dager, avsløres sårbarheten selv om problemet fortsatt er uopprettet.
De 2019 til 2021, prosjektet identifiserte 376 problemer, hvorav 351 (93,4 %) De ble korrigert, mens 11 (2,9 %) sårbarheter forble uopprettet og ytterligere 14 (3,7 %) problemer ble merket som unfixable (WontFix).
Gjennom årene, har det vært en nedgang i antall sårbarheter for hvilke oppdateringer som ikke passer innenfor den tildelte tiden for oppdatering: I 2021 ba 14 % om ytterligere 14 dager på å lappe, og bare én sårbarhet ble ikke rettet før avsløring.
For dette innlegget ser vi på fikse feil som ble rapportert mellom januar 2019 og desember 2021 (2019 er året vi gjorde endringer i retningslinjene for avsløring, og vi begynte også å spore mer detaljerte beregninger om våre rapporterte feil).
Dataene vi vil referere til er offentlig tilgjengelige på Project Zero Bug Tracker og ulike prosjektlagre med åpen kildekode (i tilfelle av data som brukes nedenfor for å spore tidslinjen for nettleserfeil med åpen kildekode).
|
Leverandør |
Totalt feil |
Rettet innen dag 90 |
fikset under |
Overskredet fristen & utsettelsesperiode |
Gjennomsnittlig dager å fikse |
|
eple |
84 |
73 (87%) |
7 (8%) |
4 (5%) |
69 |
|
Microsoft |
80 |
61 (76%) |
15 (19%) |
4 (5%) |
83 |
|
|
56 |
53 (95%) |
2 (4%) |
1 (2%) |
44 |
|
Linux |
25 |
24 (96%) |
0 (0%) |
1 (4%) |
25 |
|
Adobe |
19 |
15 (79%) |
4 (21%) |
0 (0%) |
65 |
|
Mozilla |
10 |
9 (90%) |
1 (10%) |
0 (0%) |
46 |
|
Samsung |
10 |
8 (80%) |
2 (20%) |
0 (0%) |
72 |
|
Oracle |
7 |
3 (43%) |
0 (0%) |
4 (57%) |
109 |
|
andre* |
55 |
48 (87%) |
3 (5%) |
4 (7%) |
44 |
|
TOTAL |
346 |
294 (84%) |
34 (10%) |
18 (5%) |
61 |
I gjennomsnitt nevnes det det tar i gjennomsnitt 52 dager å fikse en sårbarhet i 2021, 54 dager i 2020, 67 dager i 2019 og 80 dager i 2018.
På den delen av de raskeste korrigerte sårbarhetene er fremhevet til å være i Linux-kjernen og det nevnes at det er et gjennomsnitt på 15, 22 og 32 dager i 2021, 2020 og 2019.
Mens Microsoft var den tregeste til å gi ut en oppdatering, og tok i gjennomsnitt 76, 87 og 85 dager på å gjøre det (ifølge den første tabellen med total tid, var Oracle tregere til å svare: 109 dager på å gjøre det). Apple brukte i gjennomsnitt 64, 63 og 71 dager på å fikse det. For Google-produkter var gjennomsnittlig tid for å generere patcher i løpet av årene 53, 22 og 49 dager.
Det er en rekke forbehold med dataene våre, hvorav den største er at vi skal se på et lite antall prøver, så forskjeller i tall kan være statistisk signifikante eller ikke.
Videre påvirkes retningen til Project Zero-forskning nesten utelukkende av valgene til individuelle forskere, så endringer i forskningsmålene våre kan endre beregninger like mye som endringer i leverandøratferd. Så langt det er mulig er denne publikasjonen utformet for å være en objektiv presentasjon av dataene, med ytterligere subjektiv analyse inkludert på slutten.
Av nettleserprodusentene genereres rettelser raskest for Chrome, men utgivelsen etter at rettelsen dukker opp gjør Firefox raskere (i Chrome og Safari forblir den allerede løste sårbarheten i koden skjult for brukere i lang tid, som brukes av angripere).
Til slutt nevnes det at leverandørene over tid retter nesten alle feilene de mottar, og generelt gjør de det innen 90 dager pluss fristen på 14 dager når det er nødvendig.
I løpet av de siste tre årene har leverandørene for det meste fremskyndet oppdateringen deres, noe som effektivt reduserer den totale gjennomsnittlige tiden å fikse til omtrent 52 dager.
Endelig, hvis du er interessert i å vite mer om det kan du sjekke detaljene i følgende lenke.