Linux developers patch security holes faster than anyone else, says Google
zdnet.com
zdnet.com
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).
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.
Any of these are wrong.
Propriety systems are closed and obfuscate their flaws.
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 [2]: https://github.com/Microsoft/ebpf-for-windows
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%.
https://googleprojectzero.blogspot.com/2022/02/a-walk-throug...
But you are certainly correct, average (or median) time does not tell us how many bugs were fixed.
Perhaps the Linux numbers should also include the integration/QA lead time of the distros if it's meant to be a competition.
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://paulcalva...
Epecially if your organization has someone on the Linux kernel security team, I guess.
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.
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-ba...
https://www.scaledagileframework.com/
It has a section "agile release train" which is a literal train! Everybody loves trains. It also has an icon with the text "Built-in quality", so you can sleep soundly knowing that you will not have quality issues anymore.
/s of course, but that image is really something. It's so vague it can be anything you want it to; a middle managers' dream.
Whenever I teach a class or tell people about SAFe I always let them know 2 things:
1. All of the principles are sound and amounts to a smooth combination of best practices working together. Many companies are doing a lot of what’s involved because of that.
2. There are a lot of buzzwords. You can just assume you’re putting “lean-agile” in front of anything like they do with “quantum” in movies. It’s exhausting if you don’t let yourself chuckle. Because of it, reading the documentation can be confusing if you haven’t taken a class.
" The more alignment you have, the more autonomy you can grant. The one enables the other.
© Scaled Agile, Inc. Include this copyright notice with the copied content.
Read the FAQs on how to use SAFe content and trademarks here: https://www.scaledagile.com/about/about-us/permissions-faq/ Explore Training at: https://www.scaledagile.com/training/calendar/ "
Note that I copied only the quote. But you can see this quote is eminently copyrightable. Hence the copyright notice.
And yes, that style is fashionable on some circles. I usually prefer to avoid those circles.
Does "run by" mean that dev has to justify their projects to product and vice versa? Or is this a "this is our area, we'll take care of it thank you" kind of thing?
In my team at AWS we have ~5 backlogs each planning cycle, which includes areas like 'operational risk reduction,' 'operational burden reduction,' and 'adoption'. What makes it work in our case is that both dev and product jointly own all the backlogs, and have to come to a single recommendation on allocation they put forward to the service GM. Dev has to defend projects they want to do in the more engineering focused backlogs, while product has to do the same for the feature oriented backlog. Over time, allocations have shifted significantly depending on where the service is and what customers are asking for. What I like about this is that it forces everybody to get along and to keep their eye on what's actually important (the customer). This does require that both product and dev are experienced enough to see the other perspective. Product will have to understand that it's not in the customer's interest if dev has a super high burden, while dev will have to accept that a perfect solution is usually worse than a good enough one.
The only place where there may be some crossover is “architectural runway” which works to ensure that your future goals are possible on the system that you have. This could mean that if you know you’re going to have a need to scale a system based on a near-future feature request from product that you put the work into the tech backlog to get things ready in advance.
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.
Developers are expected to have a lot more control in SAFe.
Like anything else though, it boils down to leadership understanding that giving up total control is more effective for the company. Usually technical leaders understand that.
I’ve found that in many cases, because the developers understand what needs to be done so clearly in that backlog that even big items go quickly.
The biggest thing is just to make sure that you’re not in a situation of 100% features where everything else is being ignored until it all catches up to you. 70/30 at least forces the issue.
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.
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.
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.
It's pretty impressive that everyone seems to have reduced their time to fix bugs. Linux is doing an amazing job there.
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...