Open source is not inherently more secure than closed source.  If you have doubts about the preceding statement, Dare Obasanjo's The Myth of Open Source Security series of articles is a good place to start.

Two main problems I see from my perspective with open source security are that a) there are no compelling incentives for open source developers to examine the code, and b) they have to examine everything.  Even if all the developers are coerced into doing so, not everyone will do a good job and everyone is not the same as everything.

On the other hand, blackhats have compelling incentives to look at the code and they only need to look at a fraction of the code developers have to look at since they only need to find one vulnerability to hit paydirt.

While I agree with Dare on most points, I think his suggested solution of adopting software quality enhancing techniques and practices is unimplementable for most open source projects.  As software developers and managers, we tend to focus too much on how we doing things and what we use to get things done, meaning skills, techniques, and tools we use every day.  The open source movement is not about those things.  It's not about how or what but who, people doing things together.

Quality of open source software cannot be improved by asking people to wear straight jackets and drawing lines on the floor telling people where to go next.  Instead, we need to see the entire open source community as a global ecology and find subtle ways to change the antfarm environment so that the ants people will naturally respond in the direction that improves the quality of goods they produce.

One such solution is the introduction of open source inspectors backed by inspector rating and reward systems.  An open source inspector is a software engineer whose responsibility is to inspect the quality of software.  Unlike developers who tend to stay with a small stable of projects for extended periods of time, inspectors are gypsies who move from projects to projects.

Each inspector examines code for quality and security.  Result of an inspection is a report and a rating assertion signed by the inspector.  Rating assertions by an inspector ultimately affects the proficiency rating of the inspector.  Each bug or vulnerability discovered in the code they inspected lowers their proficiency rating.

Achieving and maintaining high proficiency rating is the lure reward motivating inspectors to dedicate a substantial portion of their time to inspect open source projects of their choosing pro bono.  If they are any good, they will find plenty of paying customers.

In summary, I am advocating the use of social engineering over software engineering to enhance open source security.  Designing, developing, debugging, and deploying social forces is the ultimate engineering profession IMHO.  The only problem with such a profession is that lifecycles of such 'wares' literally means lifecycles.