I agree that binaries aren't as obscure as many programmers think they are, and that mixing black box and white box techniques is the preferred method of testing security, but I don't think it's quite as simple as there being no difference between open source and closed source.

It's true that you can audit closed source binaries, but the fact that it's possible doesn't make it easy or cheap. It's clearly easier and faster to audit code when you have the code, even if you are a skilled reverse engineer, which most software engineers aren't. Given limited amounts of time, money, and personnel, I'll choose the easier task of auditing code (with comments and structure) that I have over reconstructing the code, then auditing the resulting uncommented and generally messier code.

One could reverse your argument as one against closed source, as the fact that you can get the source from the binary is a counter to the argument that closed source software is more secure than open source software because of the obscurity of closed source binaries. Crackers already do have a high degree of reverse engineering experience, unlike your typical software engineer.

Hey James,

I agree its easier to audit the code over disassembly. However, in an earlier post (http://silverstr.ufies.org/blog/archives/000525.html) I explained why this is rarely the case.

In THEORY code quality and code correctiveness are enhanced with access to source code. In REALITY that is only the case if code audits are actually done. And done by those that know what they are doing.

I am trying not to take sides in the debate of open vs closed source. That's because I don't think it matters. The point shouldn't be if access to source code is the issue. It should be about the design and audit practices that are applied to the code base. Those who know what they are doing can just as easily do a combination of static analysis and blackbox testing against the target process without much difficulty and find flaws.

When the code is incorrect, you can’t really talk about security. When the code is faulty, it cannot be safe. When code isn't audited, you will never be able to know the difference.

Of course, I agree that having the source code only helps if you actually do security audits of the code, which is one of the primary reasons why OpenBSD has a better security record than both open source Redhat Linux and closed source MS Windows. I also agree that the open or closed nature of the source code isn't one of the major indicators of the quality of the security of a software system, because security is rarely a top concern for most software developers. However, having the option to audit viewable source code is better than not having that option.

Open source is also relevant to design, since it offers software engineers a chance to learn from good and bad examples of security design. While most of us spend much time on the job reading code, it's generally code written in our current organization. I think our profession would benefit from reading more widely, spending more time in examining code from outside our current organization. Open source offers that opportunity to learn from many different groups of developers that closed source does not.