How Much Will It Cost To Secure Open-Source Software? OpenSSF Says $147.9 Million (venturebeat.com) 9
Today at the Open Source Software Security Summit II in Washington, D.C., OpenSSF announced an ambitious, multipronged plan with 10 key goals to better secure the entire open-source software ecosystem. From a report: While open-source software itself can sometimes be freely available, securing it will have a price. OpenSSF has estimated that its plan will require $147.9 million in funding over a two-year period. In a press conference held after the summit, Brian Behlendorf, general manager of OpenSSF, said that $30 million has already been pledged by OpenSSF members including Amazon, Intel, VMware, Ericsson, Google and Microsoft.
Re: (Score:2)
did you submit it from an inane "technology" website and did you pay the regular canon for clickbait submissions?
Re: (Score:2)
Some time ago? That's amazing considering it happened today. I would like to learn more about your velocity.
Re: (Score:2)
bullshit associations on behalf of corporations eager to recklessly exploit opensource without contributing back and worrying about getting caught pants down security wise while doing so have been making this noise for a while.
Re: (Score:2)
i mean, it's nice that they finally put their money where their mouth is, but i'm somehow still unimpressed.
Re: (Score:2)
Not much of it, for 4 or 5 of those names $143m is 1 less all hands meeting, a super bowl ad, or a small fraction of the taxes they didn't pay - and there is only is only $30m between them? Lol. Most of them have billions built on the backs of volunteers...
Depends on what they mean (Score:5, Interesting)
If they mean a detailed, systematic analysis of every piece of significant OSS with the object of reducing the density of defects that could be used for malicious access or corruption of software or data to near-zero, I'm reckoning it would take nearer $2.4 billion.
The Linux kernel is somewhere around 30 million lines of code. GCC and GLibc combined add another 20 million lines. It takes, on average, 1 person 1 week to formally analyze 10 lines of code and establish correctness, although there are now theorem provers that accelerate the process somewhat, which is great when dealing with evolving code. Let's say that it speeds things up a hundred-fold. You also want to test lots of other software, so we're not hiring these people for a week but maybe a full year to audit and bugfix everything, then cycle round to make sure that subsequent updates didn't break anything.
In order to find bugs before any code has changed, you'd be looking to hire in the region of a thousand mathematicians/computer scientists full-time. If we assume $120k per person (as these sorts of people aren't cheap), just the wages for the front-line staff come to $120 million per year. You now need twice as many people again to handle the coding and testing of solutions. So $360 million a year for your 3,000 full-time frontline staff.
If we're going to do this as a corporation, you'd need quite a lot of extra staff to keep all the administration, task distribution, liaising with the projects, making sure that rejected fixes got re-examined to meet objections, handle the finances and handle the catering. (Trust me, you do NOT want catering at Intel's standards, where the stench of rot from the bins and the decay in the food in the refectory were significant health hazards.) To keep teams reasonably small, maintain good lines of communication and avoid management becoming a deterrent to good practices, you need a lot of support staff.
The usual rule is that you want teams of size 4, to avoid communication overheads swamping actual work and to reduce the psychological harm of meetings and groupthink. If we do this at each level, we would need 750 managers at the first level, 188 at the second, 48 at the third, and 12 at the fourth, with 3 people at the top. 1001 staff to support and manage the teams. You've got to handle the feeding and financing of those 4,000, for convenience let's make it another 1,000 people. So a corporation of size 5,000. Plenty of corporations are much larger than that.
We've figured on a cost for the 3,000 front-liners. To make the maths simple, I'm going to say that you can match a manager against a caterer such that the average cost of the two is the same as for two software engineers. This would give us a cost of $600 million per year for all the staff needed.
You'd then need a building, equipment, and everything else needed. I can't find a figure for the typical fraction of employee cost to total company expenses, because nobody seems to regard that as a useful figure. The minimum seems to be 25%, so let's use that. Then the above total cost per year is $2.4 billion, considerably greater than their estimate.
It wouldn't give you total security, but it would mean that the defect density for OSS would, after some time, approach (although not reach) the sorts of levels you see in aviation software and that security risks through software defects, as opposed to operator error, would be minimal. In other words, we'd have a software singularity event. A complete reset to a secure, reliable baseline, from which to develop and grow.
I've also made this time-limited. It's too expensive to be ongoing. I would suggest one year, two tops, to get everything cleaned up without impacting how things are developed, how people experiment with software, or what people submit. All you'd do is use the existing processes to take on additional patches, letting people adjust their own approaches if they so wish.
Clearly, because their estimate is much much lower and they're not talking about remo
The first step to making software more secure... (Score:2)
It's an attitude change. TFA mentions training and tools. Both of these are downstream from attitude. It's a poor workman who embraces bad tools.
It's a disgrace that we use pointer-unsafe programming languages in the 21st century. Malfeatures such as script embedding in documents can be blamed on marketing terds, but the geeks are solely to blame for C/C++.
As for all that legacy code out there, a better stdlib could sneak some canaries in, and then sprinkle in some calls to ch