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.
You *think* the VPN and encryption software is secure. But flaws have been found in the past. The the basic underlying strategy of security is a multi-layered defense.
putting the 'B' in LGBTQ+
If you're trying to build a secure system, why would you *not* audit every piece of code, open- or closed-source? Doesn't kinda defeat the purpose if you have no idea how secure a piece of software you depend on is? For that matter, is there anyone on /. that would (seriously) suggest the opposite?
The fact that this question has to even be asked, tells you a lot about how applications are developed.
The US has dedicated itself to a race to the bottom in quality and price. Testing is just one of those things companies throw out because it is an expense with no obvious benefits, to those who are not vested in the long term for their products.
If you want publicity in any way you can get it, feel free to skip testing. Data breaches make good news. It may not be the kind of publicity you want.
Seriously, it depends on your level of trust and you level of need for security. Though, if you are using a supposedly secure transport, I imagine your need for security is relatively high. Besides, you are putting your trust in an external company, which means if that company gets breached your data is right there. If you don't encrypt it with a second layer, anyone who gains access to your VPN provider also owns you. You have just extended your circle of trust to include all of the employees of your vendor, a whole bunch of people you will never meet. If they have cleartext access to your data, you have a problem.
Security is done in layers. If someone breaches one layer, it's best if they get stopped by another. The more layers (within practical limits) the better.
To put it another way, as wed128 so succinctly put it above, "Yes." Though I'd add "HELL, YES!" about 100 times after it.
"This post contains words, known to the State of California to cause thought. Wash brain thoroughly after reading."
I think the answer reasonably is anywhere between "yes" and "absolutely yes". For example, auditing should probably be considered very important for software such as slashdotter Fyodor's Nmap.
You can't trust everyone in the open source community to be completely white-hat all the time...
"linux is just DOS with a UNIX like syntax" -- Galactic Dominator (944134)
If you have the resources to vet the code without draining resources, then it may be useful for you to do it. If you use closed source code, you just have to trust that (and maybe black box test it). At a minimum, test everything to the same standard.
If you barely have the resources to cobble together a quick and dirty IT system, then trying to security test open source software may not be the best way to grow your company (unless that's what you're intending to do as your business, in which case, you'll probably need more than the quick and dirty IT system).
If you rely on being as secure as possible, and any breach would be the end of you, and you also have loads of spare cash rattling around (*Cough* Financials *cough*), then having an extra possibility of vetting is never something to be sniffed at. Get a bunch of people to pore over it. If they find holes, submit patches and patch internally as required.
Still, you're only as secure as the bunch you hire to vet the code.. If you give it to 'a person' to vet, and they happen to put in a back door..
It really all depends on where you think the biggest risks are, and who you choose to trust. But it's still nice to have the extra chance to at least look if it worries you.
It's not just a matter of security. I would think you would want to verify, via some method (code review, etc) that the code is correct and provides the desired results, doesn't crash, is properly integrated, etc.
Brett
> companies may be wondering if they should conduct security tests of their customized open source software before deployment ..
If they haven't already conducted penetration tests before deployment and implemented a secure irrevocable auditing system, then they shouldn't even be in the business ..
...the next question that's a posted article [rubs crystal ball]Is Code Testing of Open Source Apps Necessary?[/rubs crystal ball]
The consequences of fixing a problem while it's being exploited are usually much more severe than not having the problem in the first place. Proactive security is the way to go. That's why BUGTRAQ is peppered with statements like, "This problem was fixed in OpenBSD about 6 months ago"
-- "At Microsoft, quality is job 1.1" -- PC Magazine, Nov. 1994
http://www.nytimes.com/2004/02/02/opinion/02SAFI.html?th
and here
http://en.wikipedia.org/wiki/Farewell_Dossier
Seriously, this is a dumb question and reeks of someone trolling for a reply.
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.
Uh, isn't one of the points of open source that you have thousands of eyeballs auditing the code? What the hell kind of question is this to ask, really?
The problem is that code auditing generally tries to detect bugs. Even in the best case scenario where you can have a complete, manual audit of the entire codebase, you will miss many, many bugs. A much cheaper and in many ways better option is to just take a look at the code. Would you be proud of having written it? Ashamed? If you'd be ashamed of it, I say auditing is useless - there will always be vulnerabilities you've missed. If you're proud of it, an audit might be worth the cost - but, then, you could also spend the money on refactoring the code, use more privilege seperation, add better input validation, more sanity checks...
In a perfect world, all code would be statically checked, audited manually and by automatic tools, etc. But we're not in a perfect world. Auditing is very often NOT the best thing to spend money on.
Bear in mind that security is only as strong as it's weakest link. Do you trust the framework you're building on? The libraries you use? The OS? Your cloud provider?
Rest assured, any bits they feel will help them make Oracle an even more ubiquitous player in the database niche of IT will not see the light of day any time soon. Frankly, I'm surprised they haven't killed MySQL yet (although they may have plans for it; and the fact that it was previously open-source may make it impossible for them to truly kill it).
Anybody here trust Oracle? I mean, I've worked with their products before, and while I don't want to say anything denigrating or derogatory about them here I'm just glad that's worked with before (past tense) and not work with (present tense).
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.
Companies should audit the code for these apps the same way they audit Linux, Bash, JBOSS and the various other OS applications they deploy. Why should this code be any different.
If someone is passing you on the right, you are an asshole for driving in the wrong lane.
Being open source in now way means a program is bug free, or even does what it claims. Sure, chances are someone else has already found if there is something horribly wrong, but the whole point of it being open source is so you can audit it yourself. If you don't bother to actually look at the code, it might as well be closed source, since you aren't looking at the code anyway.
"Information wants to be expensive" - Stewart Brand, the same guy who said "Information wants to be free"
Somebody said "it depends" with a certain level of sarcasm above, but I'm going to say it in all seriousness, and echo the "why was this posted" question, also coming from a different angle.
The headline says "open source apps" without qualification, so I'll address all open source apps first
The criteria for wanting an audit are the same, and not all software requires an in-house audit for various and I would have said obvious reasons.
But there are some observations that apply to open source that do not apply to closed source:
Every single proprietary-software vendor on the planet has a huge incentive to find major flaws in every competing product, but only with open source do they have the opportunity.
More specifically addressed to open-source security software, but still widely relevant:
The open-source security components are available for any use (BSD) or any open-source use (GPL). They get re-used. OpenSSL is surely among the most intensively-audited software components on the planet, not least because banks use it to protect financial transactions of all sizes. And OpenSSL is everywhere.
That leaves the following summary of my answer:
And now for something completely different: /. editors, don't you know that sometimes it actually matters?
This story scarcely have been intentionally constructed to more reliably produce a sales pitch for closed-source companies: "Here's a world-famous bastion of open-source advocates — ask any of your geeks, they'll know about slashdot — and look at this, almost everyone there says you have to audit open source. Do you have the resources to do that? No? That's what we thought, so we can dismiss that idea. Now, let's talk."
And that's precisely because the headline doesn't even mention the "security" part. It's "Open Source Apps". All of them. Even here, not reading the summary is rampant. How closely do you think a busy manager who starts out suspicious of the whole idea is going to examine this?
Bad money drives out good.
As always, all IMO. Insert "I think" everywhere grammatically possible.
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
uh... look.. part of the whole point of open source software is the fact that it CAN be audited! any and all software should be audited and tested to its fullest extent before going into production. i know this doesn't always happen in the corporate environment, but that does not change the fact that it SHOULD be done! people are right, just because something is open source doesn't mean it's automagically secure, it means that people can audit code and submit bug reports when they find insecurities which, in turn, lets the developers make the code more secure. Christ, why does this question even need to be posed? has everyone forgotten how the open source community is supposed to work? i think it may just be that the corporate people are coming in without a clue.
Not necessary if the application is not critical.
CERN's LHC and my bank's software system are typical examples of critical applications. My neighbour's wifi router is not.
If there is a good reason to do this then companies will do it because it serves their own self interest.
We usually call that "pile of cement over a chasm" a "dam"
Watch your mouth ;-)
"Due diligence". That's all I have to say. Do I audit the code for my personal website? No. Would I audit code for a large commercial site? I should think so.
I'll go against everyone and say that no, you should not have to audit the code.
The fact that in order to use a software package safely an expert has to go through every single instruction is an aberration that would be done away with by using a capability operating system like KeyKOS, CapROS, or Coyotos.
Start OpenOffice or PDF reader or whatever with 1) authorization to interact with its X11 window 2) a means to call out to a trusted system dialog box for reading and saving files from/to the user's space. Nothing else. What do you care if there is malicious code in the application? It is surprisingly simple to extend the concept to everything in the system when you are designing the system.
Unfortunately KeyKOS is old (1970, PDP-10), the Coyotos lead was hired by Microsoft last spring, and CapROS hasn't enough coders. Maybe sometime in fifty years or so we will have a secure operating system.