Linux Developers Patch Bugs Faster Than Microsoft, Apple, and Google, Study Show...
source link: https://linux.slashdot.org/story/22/02/20/1915222/linux-developers-patch-bugs-faster-than-microsoft-apple-and-google-study-shows
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Linux programmers fixed bugs faster than anyone — in an average of just 25 days (improving from 32 days in 2019 to just 15 in 2021). That's the conclusion of Google's "Project Zero" security research team, which studied the speed of bug-fixing from January 2019 to December 2021.
ZDNet reports that Linux's competition "didn't do nearly as well."
For instance, Apple, 69 days; Google, 44 days; and Mozilla, 46 days. Coming in at the bottom was Microsoft, 83 days, and Oracle, albeit with only a handful of security problems, with 109 days. By Project Zero's count, others, which included primarily open-source organizations and companies such as Apache, Canonical, Github, and Kubernetes, came in with a respectable 44 days. Generally, everyone's getting faster at fixing security bugs. In 2021, vendors took an average of 52 days to fix reported security vulnerabilities. Only three years ago the average was 80 days. In particular, the Project Zero crew noted that Microsoft, Apple, and Linux all significantly reduced their time to fix over the last two years. As for mobile operating systems, Apple iOS with an average of 70 days is a nose better than Android with its 72 days. On the other hand, iOS had far more bugs, 72, than Android with its 10 problems. Browsers problems are also being fixed at a faster pace. Chrome fixed its 40 problems with an average of just under 30 days. Mozilla Firefox, with a mere 8 security holes, patched them in an average of 37.8 days. Webkit, Apple's web browser engine, which is primarily used by Safari, has a much poorer track record. Webkit's programmers take an average of over 72 days to fix bugs.
›
It doesn't seem to do much for the number of current bugs being exploited.
Apparently everyone's getting faster at making new ones, too.
-
It doesn't seem to do much for the number of current bugs being exploited.
Apparently everyone's getting faster at making new ones, too.
The challenge is that fixing one bug can result in another, especially if there is pressure to release it fast, while not having a suitable testing or QA setup.
-
Every month I do two in-person presentations and a YouTube video covering the new vulnerabilities and patches for the month. Then I answer questions about them. I've been tracking vulnerabilities as part of my job for several years now and I've noticed some patterns.
A pattern with Microsoft is that each series of related vulnerabilities lasts 3-9 months. For example right now we're hopefully finishing up the print spooler vulnerabilities - that started seven months ago. Each month we have new patches to try to get the print spooler fixed. Overlapping with that was the Exchange issues. Every month Microsoft's QFE team tries again to fix the vulnerabilities with Exchange. That's to be expected because often they are only seeing the current attack, the current symptom. They don't always have a deep understanding of the underlying cause of the problem.
My experience with shellshock was very different, and typical of important Linux vulnerabilities.
With shellshock, just on one mailing list alone there were just over 100 of us looking at the codes looking at the issue, and trying to find the best fix over the next couple of days. Within just a few hours, Florian Weimer of Red Hat posted a fix, and said that was pretty much the only way to fix it. It was a broad fix, pretty much getting rid of the little-used feature that had the vulnerability. Others tried to come up with a smaller, more specific fix.
About half a dozen more tailored fixes were proposed and each time someone else pointed out how attackers would get around it. Florian said that no "fix" to the feature could ever work - that little-used feature HAD to be removed. All the ways people were trying to stop the exploits were essentially trying to allow an untrusted user to run code, without allowing them to run code, Florian said.
Over the next 48 hours or so, as narrow fixes were proposed and shot down, we all started to see what Florian had seen immediately. We started to understand the deeper issue. What has been immediately obvious to Florian became clear to everyone else over the period of two days or so. Florian's fix was then deployed, and it held. It was right fix.
That's the phenomenon ESR was talking about when he wrote:
--
Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.Or, less formally, "Given enough eyeballs, all bugs are shallow." I dub this: "Linusâ(TM)s Law"....
My original formulation was that every problem "will be transparent to somebody". Linus demurred that the person who understands and fixes the problem is not necessarily or even usually the person who first characterizes it. "Somebody finds the problem," he says, "and somebody else understands it.
--Notice he didn'r say "all bugs are not exist".
Anybody who thinks ESR (or anyone) ever claimed "all bugs are not exist" simply doesn't understand the point being made, and certainly hasn't read the paper.He said that almost all will be *shallow* to someone - that someone will intuitively understand the true nature of the problem, and the fix will be obvious to someone. You can get to the right fix a lot quicker when you show the problem to enough people so someone clearly sees the right fix, right away. Like Florian did with shellshock.
That's been my experience. With 100 people looking at the problem in the code, you get the right solution much faster than with just one or two people.
-
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK