Slashdot Mirror
Is Code Auditing of Open Source Apps Necessary?
An anonymous reader writes "Following Sun Microsystems' decision to release a raft of open source applications to support its secure cloud computing strategy, companies may be wondering if they should conduct security tests of their customized open source software before deployment. While the use of encryption and VPNs to extend a secure bridge between a company IT resource and a private cloud facility is very positive — especially now that Amazon is beta testing its pay-as-you-go private cloud facility — it's important that the underlying application code is also secure. What do you think?"
Next Question.
OpenBSD does code audits. All security-sensitive applications should be, if not by the developers, by the people deploying them, if they have the resources.
How are they auditing the code of the closed source apps they're using? If there are steps in place, use those as a minimum. If there aren't, then how's the blind faith of using those programs different than what's needed for open source?
"Common sense will be the death of us all"
The answer is Yes. When you run software, you are running it under 1 of the following 3 assumptions:
1. You implicitly trust the vendor
2. You have tested it yourself and trust your tests
3. You are oblivious (the vast majority of users are)
What's more, since Open Source software lacks any single person you could possibly sue in case things go terribly wrong, it makes sense to mistrust it a priori. OSS isn't magically secure because it is open. It still needs testing and validation if you intend to run it in any serious corporate environment.
To simply accept a software package without assuming it is riddled with bugs and security vulnerabilities is foolish. No matter if it is a proprietary software package or an Open Source community project, any sane CIO will want some sort of evidence that the product will not end up losing them money and customer trust due to security vunerabilities.
How are they auditing the code of the closed source apps they're using? If there are steps in place, use those as a minimum. If there aren't, then how's the blind faith of using those programs different than what's needed for open source?
Flipping the question does not answer the original one, which is a valid one and which deserves an answer. The answer is, just like anything, it depends. It depends on the open source artifacts in question; it depends on the specific audit/security requirements; it depends on how critical the app under development is; it depends on SLA agreements (if one exists and requires it.)
As you said, if there are steps in place, use those as a minimum, provided that they are sufficient for the requirements at hand.
If there aren't any, you can't just cross your arms and say "well, if I didn't do them with COTS, why would I with FOSS"? If there aren't, and your project requires them, then shit, you implement them.
The question of whether to sec audit something, be it COTS or FOSS is predicated by the requirements at hand, not on whether a previous usage of COTS (or FOSS) was properly audited in the past.
King of Swamp Castle: When I first came here, this was all swamp. Everyone
said I was daft to build a castle on a swamp, but I built in all the same,
just to show them. It sank into the swamp. So I built a second one. And that
one sank into the swamp. So I built a third. That burned down, fell over,
and then sank into the swamp. But the fourth one stayed up. And that's what
you're going to get, Son, the strongest castle in all of England.
That sounds a lot like the development history of Windows.
Only to idiots, are orders laws.
-- Henning von Tresckow
Open source code development by definition is a sort of "self-auditing" process. That is all good. The bigger problem that is unaddressed in the the FOSS community at large that I see is when the projects that run them fall apart. For example, in this case is the Sun going to set on Sun is still not known. What about Mysql?
More commonly it is the problem of rag tag bands of volunteers (that are increasingly novice these days), where a couple major players move the project along and if something happens to them the project goes off the rails. The rather high profile example of this was CentOS fiasco earlier this year.
I know everyone is going to come back and say things like, "if you don't like it, fork it". That is a nice sentiment, but much harder to do in practice. Often it is like saying if you don't like the service you get at Wall Mart start your own department store chain, bank, pharmacy, or whatever. Not something even most larger companies can do, let alone end private users.
We need a system for auditing and reviewing open source projects for their viability and overall health so users (individuals, companies, and other projects that depend on them) can make real decisions about using what they produce. Right now it is more of an art than a science to determine if a project is going to live. I am not saying limit open source creativity or stop small projects, but provide transparency as to the health of the projects. We can see the structure of the code, we should be able to see the structure of community that builds and maintains it.
Living in Chile
The funny thing is, how many people are actually eyeballing the code? Are you, or do you just assume thousands of other people are?
Except for the part about the 4th one staying up.
Intron: the portion of DNA which expresses nothing useful.