לפני כמה ימים ה חוקרים מצוות Google Project Zero פרסמו את התוצאות על ידי סיכום הנתונים על זמן התגובה של היצרנים לפני הגילוי של נקודות תורפה חדשות במוצרים שלהם.
בהתאם למדיניות גוגל, ניתנים 90 יום להסרת נקודות התורפה זוהו על ידי חוקרי Google Project Zero, לפני שהם פורסמו, וניתנת גם חשיפה פומבית נוספת. ניתן לשנות ל-14 ימים נוספים בבקשה נפרדת.
אז בעצם, לאחר 104 ימים, הפגיעות מתגלה גם אם הבעיה עדיין לא תוקנה.
בין 2019 ל -2021, הפרויקט זיהה 376 בעיות, מתוכם 351 (93,4%) הם תוקנו, בעוד ש-11 (2,9%) פגיעויות נותרו ללא תיקון ועוד 14 (3,7%) בעיות סומנו כבלתי ניתנות לתיקון (WontFix).
לאורך השנים, חלה ירידה במספר הפגיעות עבורם תיקונים אינם מתאימים בזמן שהוקצב לתיקון: בשנת 2021, 14% ביקשו 14 ימים נוספים לתיקון, ורק פגיעות אחת לא תוקנה לפני החשיפה.
עבור פוסט זה, אנו מסתכלים על באגים שתוקנו שדווחו בין ינואר 2019 לדצמבר 2021 (2019 היא השנה בה ביצענו שינויים במדיניות החשיפה שלנו, והתחלנו גם לעקוב אחר מדדים מפורטים יותר לגבי הבאגים המדווחים שלנו).
הנתונים שאליהם נפנה זמינים לציבור ב-Project Zero Bug Tracker ובמאגרי פרויקטים שונים בקוד פתוח (במקרה של נתונים המשמשים להלן כדי לעקוב אחר ציר הזמן של באגים בדפדפן בקוד פתוח).
מוכר |
סך הכל באגים |
תוקן עד יום 90 |
קבוע במהלך |
חריגה מהדדליין & תקופת חסד |
ימים ממוצעים לתיקון |
תפוח עץ |
84 |
73 (% 87) |
7 (% 8) |
4 (% 5) |
69 |
מיקרוסופט |
80 |
61 (% 76) |
15 (% 19) |
4 (% 5) |
83 |
|
56 |
53 (% 95) |
2 (% 4) |
1 (% 2) |
44 |
לינוקס |
25 |
24 (% 96) |
0 (% 0) |
1 (% 4) |
25 |
Adobe |
19 |
15 (% 79) |
4 (% 21) |
0 (% 0) |
65 |
מוזילה |
10 |
9 (% 90) |
1 (% 10) |
0 (% 0) |
46 |
סמסונג |
10 |
8 (% 80) |
2 (% 20) |
0 (% 0) |
72 |
אורקל |
7 |
3 (% 43) |
0 (% 0) |
4 (% 57) |
109 |
אחרים* |
55 |
48 (% 87) |
3 (% 5) |
4 (% 7) |
44 |
סך הכל |
346 |
294 (% 84) |
34 (% 10) |
18 (% 5) |
61 |
בממוצע, מוזכר כך לוקח בממוצע 52 ימים לתקן פגיעות ב-2021, 54 ימים ב-2020, 67 ימים ב-2019 ו-80 ימים ב-2018.
בקטע ש הפגיעויות המתוקנות המהירות ביותר מסומנות בליבת לינוקס וצוין כי מדובר בממוצע של 15, 22 ו-32 ימים ב-2021, 2020 ו-2019.
בעוד מיקרוסופט הייתה האיטית ביותר לשחרר תיקון, לקח בממוצע 76, 87 ו-85 ימים לעשות זאת (לפי הטבלה הראשונה עם זמן כולל, אורקל הייתה איטית יותר להגיב: 109 ימים לעשות זאת). לאפל נדרשו בממוצע 64, 63 ו-71 ימים כדי לתקן את זה. עבור מוצרי Google, הזמן הממוצע ליצירת תיקונים לאורך השנים היה 53, 22 ו-49 ימים.
ישנן מספר אזהרות עם הנתונים שלנו, הגדול שבהם הוא שאנו נסתכל על מספר קטן של דגימות, כך שההבדלים במספרים עשויים להיות מובהקים סטטיסטית או לא.
יתר על כן, הכיוון של מחקר Project Zero מושפע כמעט לחלוטין מבחירותיהם של חוקרים בודדים, כך ששינויים ביעדי המחקר שלנו עשויים לשנות מדדים באותה מידה כמו שינויים בהתנהגויות של ספקים. עד כמה שניתן, פרסום זה נועד להוות הצגה אובייקטיבית של הנתונים, עם ניתוח סובייקטיבי נוסף בסופו.
מבין יצרני הדפדפנים, התיקונים נוצרים הכי מהר עבור Chrome, אך השחרור לאחר הופעת התיקון הופכת את Firefox למהיר יותר (ב-Chrome ו-Safari, הפגיעות שכבר תוקנה בקוד נשארת מוסתרת עבור המשתמשים במשך זמן רב, המשמשת תוקפים).
לבסוף, מוזכר כי לאורך זמן, הספקים מתקנים כמעט את כל השגיאות שהם מקבלים ובדרך כלל, הם עושים זאת תוך 90 יום בתוספת תקופת החסד של 14 יום בעת הצורך.
במהלך שלוש השנים האחרונות, הספקים, לרוב, האיצו את התיקון שלהם, ובכך הפחיתו את הזמן הממוצע הכולל לתיקון לכ-52 ימים.
לבסוף, אם אתה מעוניין לדעת יותר על כך אתה יכול לבדוק את הפרטים ב הקישור הבא.