a few days ago the Researchers from the Google Project Zero team released the results by summarizing the data on the response time of the manufacturers before the discovery of new vulnerabilities in their products.
In accordance with Google policy, 90 days are given to remove the vulnerabilities identified by Google Project Zero researchers, before they are released, and further public disclosure is also granted. can be changed for another 14 days with a separate request.
So basically, after 104 days, the vulnerability is revealed even if the issue is still unpatched.
From 2019 to 2021, the project identified 376 problems, of which 351 (93,4%) They were corrected, while 11 (2,9%) vulnerabilities remained unpatched and another 14 (3,7%) issues were marked unfixable (WontFix).
Over the years, there has been a decrease in the number of vulnerabilities for which patches don't fit within the allotted time to patch: In 2021, 14% requested an additional 14 days to patch, and only one vulnerability was not patched before disclosure.
For this post, we look at fixed bugs that were reported between January 2019 and December 2021 (2019 is the year we made changes to our disclosure policies, and we also started tracking more detailed metrics about our reported bugs).
The data we will reference is publicly available on Project Zero Bug Tracker and various open source project repositories (in the case of data used below to track the timeline of open source browser bugs ).
|
Vendor |
total bugs |
Fixed by day 90 |
fixed during |
Exceeded deadline & grace period |
Avg days to fix |
|
Apple Lossless Audio CODEC (ALAC), |
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 |
|
Others* |
55 |
48 (87%) |
3 (5%) |
4 (7%) |
44 |
|
TOTAL |
346 |
294 (84%) |
34 (10%) |
18 (5%) |
61 |
On average, it is mentioned that it takes an average of 52 days to fix a vulnerability in 2021, 54 days in 2020, 67 days in 2019 and 80 days in 2018.
On the part of the fastest patched vulnerabilities are highlighted to be in the Linux kernel and it is mentioned that it is an average of 15, 22 and 32 days in 2021, 2020 and 2019.
While Microsoft was the slowest to release a patch, taking an average of 76, 87 and 85 days to do so (according to the first table with a total time, Oracle was slower to respond: 109 days to do so). Apple took an average of 64, 63 and 71 days to fix it. For Google products, the average time to generate patches over the years was 53, 22, and 49 days.
There are a number of caveats with our data, the biggest of which is that we will be looking at a small number of samples, so differences in numbers may or may not be statistically significant.
Furthermore, the direction of Project Zero research is influenced almost entirely by the choices of individual researchers, so changes in our research objectives could change metrics as much as changes in vendor behaviors. As far as possible, this publication is designed to be an objective presentation of the data, with additional subjective analysis included at the end.
Of the browser manufacturers, fixes are generated fastest for Chrome, but the release after the appearance of the fix makes Firefox faster (in Chrome and Safari, the already fixed vulnerability in the code remains hidden for users for a long time, which is used by attackers).
Finally, it is mentioned that over time, providers correct almost all the errors they receive and generally, they do so within 90 days plus the grace period of 14 days when necessary.
Over the past three years, vendors have, for the most part, sped up their patching, effectively reducing the overall average time to fix to about 52 days.
Finally, if you are interested in knowing more about it you can check the details in the following link