8 ms·
Linux developers patch security holes faster than anyone else, says Google
- rurban 5y agoThe last time I saw such a comparison HP was in the lead with over 200 days to fix. This time Microsoft is in the lead with 90. HP doesn't seem to produce SW anymore. Or Google's project zero team doesn't care about them.
- fmajid 5y agoMicrosoft has improved dramatically compared to the days of Windows 95. Apple, on the other hand, is mired in complacency.
- mnem 5y agoDoesn't the data in that blog show Apple improving faster than MicroSoft? Going from taking longer than to fix bugs in 2019 to being faster than them now? It's pretty impressive that everyone seems to have reduced their time to fix bugs. Linux is doing an amazing job there.
- helpfulclippy 5y agoI'm always really disappointed every time I hear an account from security researchers about how difficult it is to deal with Apple. I realize that Apple cannot possibly be alone in this, but there's something especially frustrating about a company that aggressively denies choice to its users, cites security as a major benefit of that, and then ignores critical feedback about vulnerabilities.
- Mikeb85 5y agoIf you don't admit to vulnerabilities they don't exist, right?
- helpfulclippy 5y ago
- fmajid 5y agoJust one example, reneging on bug bounties is mind-blowingly stupid for a $3T company. Security researchers will sell what they find to the likes of NSO Pegasus instead of Apple. Also, the bad blood thus created makes them less likely to follow "responsible disclosure" and instead just disclose them as soon as discovered for kudos.
- mrweasel 5y agoHP spun its software out in HP Software Division and sold the whole thing to everyones favorite legacy software company: Micro Focus.
- efficax 5y agoTech companies are run by product managers these days and fixing a bug is not a product priority if the buggy software is still making money
- booleandilemma 5y agoThen let’s make it a priority. We can talk about it in the next sprint, after a story has been created and groomed. Then it’s just a matter of someone taking it off the backlog after they’ve gotten through their current workload and scheduled a meeting with product to make sure expectations are aligned.
- mkl95 5y agoThis. At most companies Agile = delivering new buggy software on top of old buggy software every few weeks.
- deleted 5y ago[deleted]
- marcosdumay 5y agoI disagree with the "these days" part. Tech companies never fixed bugs. In fact, since I can remember, they have only improved on that (but they still aren't any good).
- brightball 5y agoOne of many reasons I’m a fan of SAFe (Scaled Agile Framework). There are 2 backlogs, one run by product and one run by dev/ops/arch/sec. Over the course of a PI (about 1 quarter), capacity planning usually allocated 70/30 between the two backlogs. This allows your tech staff to prioritize things in their 30 without having to make a business case for people who don’t intimately understand why it’s important. It’s beautiful. They are called the Program and Solution backlogs. https://www.scaledagileframework.com/program-and-solution-backlogs/ https://www.scaledagileframework.com/program-and-solution-ba...
- sdoering 5y agoInteresting insight. I probably never was part of a real by the book SAFe environment then. In all SAFe projects I took part never was there a second backlog. Or if there was one (once) the reasoning was: "Let'sput everything from tech in there. We will revisit it once we have done the important/business-relevant stuff." My take away message is that no matter what, business either cares for security or it doesn't. No framework will help against the priorities of product/management if they are aligned against security.
- sitting_duck 5y agoThe *BSDs are nonexistent in the raw data [1]. Of course less code leads to less security holes. But 0/376? Or is project zero excluding BSDs entirely? [1] https://bugs.chromium.org/p/project-zero/issues/list?sort=id&colspec=ID%20Status%20Restrict%20Finder%20Reported%20Deadline%20Remaining%20CVE%20Vendor%20Product%20Summary&q=status%21%3DInvalid%20id%3E%3D1748%20id%3C%3D2248%20Deadline%3A90&can=1 https://bugs.chromium.org/p/project-zero/issues/list?sort=id...
- tomnipotent 5y agoI don't believe Chrome provides support for BSD, which explains why it's missing.
- sitting_duck 5y agoHow? I referenced the underlying data. They have Microsoft kernel bugs. Zoom bugs. Even systemd. What am I missing? I think they coincidentally happen to have their bug tracker hosted on chromium’s site.
- deleted 5y ago[deleted]
- bombcar 5y agoWhat does “Linux developers patch a security hole”? Time until the patch is merged into Linus’s tree? Or more reasonably time until a patched kernel is available in a given distro?
- stjohnswarts 5y agoYour last question is impossible to answer because distros are all so different.
- bombcar 5y agoWhich is the point - time until patched in the kernel source tree is a relatively useless metric unless it’s pretty close to when those fixes ship to Ubuntu, Debian, CentOS, Amazon Linux - whatever the majority of Linux is these days. Otherwise a fix in Linus’ tree is about as useful as a committed fix to the Windows source repository.
- opan 5y ago>Otherwise a fix in Linus’ tree is about as useful as a committed fix to the Windows source repository. I don't see why. Users can manually update their kernels in this case. I don't believe that's an option you'll get with a proprietary OS.
- bombcar 5y agoIt's a bit more useful, but the breakage has to be seriously impacting my use of the system to roll my own kernel outside of the distro's packaging (the only one I've done is manually applying a fix to a Gentoo kernel and even then I just throw the patch on after the normal stuff).
- 0xedd 5y agoEither an MR or a merge into the kernel, yes. But, regardless, the comparison omits open auditing vs a closed one. With closed systems being able to decide what to disclose and obfuscating their own system, the [power] user is less likely to have actual numbers of anything. Be it how many flaws or how many were discovered internally and placed in the backlog. Then, you throw in some PR requirements into the mix and you'll never have a clear picture of what you're using. Just a sales pitch in a different medium. This is an important dimension.
- tpmx 5y agoThe Linux kernel developers don't release security fixes directly to end users, unlike e.g. Apple and Microsoft. Perhaps the Linux numbers should also include the integration/QA lead time of the distros if it's meant to be a competition.
- jka 5y agoYou make a good point here -- the time-to-deployment is significant as well as the time-to-resolve. It's also true that once a fix is available in any Linux source tree, advanced users can begin to use it from that moment onwards. Arguably some users could develop their own workaround or solution even before one is available upstream, should they want to (because the code and tools to compile it are all available to them). (similarly it'd be valuable to analyze how long it takes for the majority of end-users to upgrade across common operating systems. something like this chart[1] of Firefox version traffic history, but for security fix rollout) [1] - https://web.archive.org/web/20201220010043/https://paulcalvano.com/assets/wp-content/uploads/2017/11/FirefoxBrowserVersionTrafficHistory_20171126.jpg https://web.archive.org/web/20201220010043/https://paulcalva...
- tpmx 5y agoSure - there is definitely a real benefit for advanced users of the Linux kernel. Epecially if your organization has someone on the Linux kernel security team, I guess.
- bombcar 5y agoThis can also be a downside where the fix reveals the vulnerability and it begins to be exploited before distros get fixes out. Iirc there recently was a big one where the fix was snuck into a large Linus patch and not revealed until all distros had a chance to release updated kernels.
- codethief 5y ago> There's a lot of FUD about how Linux is being shown recently to be less secure than proprietary systems. That's nonsense. But, now there are hard facts from Google's Project Zero, Google's security research team, showing Linux's developers do a faster job of fixing security bugs than anyone else, including Google. I don't see how the Linux developers' higher speed of fixing security bugs would in any way substantiate the author's claim that Linux is not "less secure than proprietary systems". He completely leaves aside - the number of security bugs per unit time, - the severity of the bugs in question, and - the overall system architecture and the potential impact of security bugs in general. Needless to say, this is where the situation on Linux looks pretty grim compared to current "proprietary systems" (which has nothing to do with the fact that they're proprietary).
- kodah 5y agoI don't think we'll ever get a total picture on the first two items from Windows or MacOS, so that's difficult to compare. What's the issue with Linux's architecture? Hybrid kernels aren't shown to be any more secure than a monokernel to my knowledge. There is something to be said that we don't make kernels for device drivers, which are basically their own operating systems, but that's common to all kernels.
- yjftsjthsd-h 5y agoWhat architectural/impact differences does Linux have vs others?
- codethief 5y agoSee e.g. https://madaidans-insecurities.github.io/linux.html https://madaidans-insecurities.github.io/linux.html for a detailed discussion.
- rossy 5y agoThere's some very good points in there, but (4) is unfair. It's true that there's no boundary between a sudoer and root in Linux, but there's also no boundary between an Administrator and SYSTEM in Windows. UAC, even in the "secure" AlwaysNotify mode which uses the secure desktop, has countless unpatched bypasses[1]. Also, (3) should raise some eyebrows for readers paying attention. Cool, Microsoft removed font parsing from the kernel, how wise of them. Wait a second, why was font parsing in the kernel to begin with? With win32k.sys, it shouldn't be surprising that Microsoft has to do more legwork to bring the attack surface back down to the level of other OSes. They're also exploring the use of eBPF in the Windows kernel too[2]. [1]: https://github.com/hfiref0x/UACME https://github.com/hfiref0x/UACME [2]: https://github.com/Microsoft/ebpf-for-windows https://github.com/Microsoft/ebpf-for-windows
- fastaguy88 5y agoThis is an example of why "average" is not a good statistic for long-tailed distributions. What does it mean that Apple took 69 days, or Microsoft 83? Does that mean that 90% of the bugs were fixed in 2 weeks, but 10% took months (or years)? Or were half fixed in a month, but the remainder took 3 months or more? A much more useful number would be the median. When were half the bugs fixed? And it would be nice to know about the slowest 10%.
- tedunangst 5y agoI think you want to look at cumulative time. If, hypothetically, linux fixes one bug in one day for 365 days, and windows fixes one bug in ten days one time, is linux 10x better?
- fastaguy88 5y agoThe problem with any of these measures is that we do not know how severe the bugs are. But you are certainly correct, average (or median) time does not tell us how many bugs were fixed.
- thetallstick 5y agoIt’s not in the linked article but there’s significant more information from the source: https://googleprojectzero.blogspot.com/2022/02/a-walk-through-project-zero-metrics.html?m=1 https://googleprojectzero.blogspot.com/2022/02/a-walk-throug...
- mvanbaak 5y agoLinux is just a kernel. Others provide a complete os i cluding ways to distribute security patches. Apples and oranges.