Slashdot Mirror
Linux Foundation's Census Project Ranks Open Source Software At Risk
jones_supa writes: The Core Infrastructure Initiative, a Linux Foundation effort assembled in the wake of the Heartbleed fiasco to provide development support for key Internet protocols, has opened the doors on its Census Project — an effort to figure out what software projects need support now, instead of waiting for them to break. Census assembles metrics about open source projects found in Debian's package list and on openhub.net, and then scores them based on the amount of risk each presents. Risk scores are an aggregate of multiple factors: how many people are known to have contributed to the project in the last 12 months, how many CVEs have been filed for it, how widely used it is, and how much exposure it has to the network. According to the current iteration of the survey, the programs most in need of attention are not previously cited infrastructure projects, but common core Linux system utilities that have network access and little development activity around them.
What they did is getting a basic overview of which projects need most attention. This is the first stage in improving the situation the most effective way. Now people/companies which have an interest in linux security as a whole (e.g. redhat) have a list of projects they can contribute to, even sorted by which to contribute first. I think the list is incredibly useful. Before heartbleed nobody did this kind of research, or it didn't get any attention.
As FOSS projects become more widely used (privately and by companies), it's an excellent idea to actually collect some statistics that give an idea of how well and how actively a project is maintained.
An attacker might e.g. get commit rights to several low-activity projects, insert malicious code, and wait for people to download updates and become easily exploitable.
No FOSS end-user ever checks code: they rely om the maintainers to produce clean and honest code. Large and tech-savvy businesses tend to be a little more cautious, but in the end only a minority have the staff and the budget to actually vet the code. So unless they're going to expose themselves by redistributing the code, or they know they're going to use it in mission-critical ways, they won't look into it very deeply.
This leaves users vulnerable. Because when a project is "asleep", it's a good candidate to slip in some backdoors.
Given the number of FOSS projects, it can be quite hard for any organisation to get an idea of (let alone metrics on) how well maintained those projects are. Doing this and making the numbers public is a very useful service.
Of course, as no doubt various FOSS enthusiasts will rush to point out, it's not a perfect indicator.
Well ... it isn't and it doesn't have to be, but it's a very useful indicator all the same. And if you can easily look up a project's rating, that will sharply increase the likelihood that it will be used.
> Sometimes its just better to salvage the working stuff and jettison the rest, which is the approach LibreSSL takes.
This kind of work pays for a great deal of my salary. My favorites are the long term architects who built up complex systems themselves that *no one else in the world uses*, but refuse to move to the safer and better supported modern tools. Examples written by software architect I know include:
RCCS - (an RCS based shared repository source control tool, replaced by CVS even before it was written)
Tuttle - (system config tool, replaced by cfengine and puppet even before it was written)
ypmake - (perl based replacement for GNU make, written by someone who loved perl and couldn't be bothered to learn shell)
And oh, there's my favorite reasons for why such folks won't review their code with me.
The code is the documentation. (This was popular over at the FSF in its early days.)
The Wiki blew up last time I used it, so I refuse to use it.
Schedule a meeting! (and then refuse to show up five meetings in a row)
Cleaning up freeware and open source code is often thankless.
Did you read how the derived it? Patches mean less risk (for some bizarre reason) and systemd patches hourly!