I agree with Neo. I'd like to split the matter into two distinct parts, a theoretical and a practical one.

Even theoretically-only spoken the matter of closed-source versus open-source remains complicated. A possible advantage of open-source is the peer-review process which can take place. But to capitalize on this advantage this process has to take place at all, which is in no way guaranteed by something being open-source at all.

A possible advantage of closed-source software would be the "security by obscurity" approach. Experience suggests that this is not a (lasting) security measure at all and in the case of compromised security there is a single possible source able to provide corrective services, whereas open-source software could be changed by everybody in theory, which still leaves a lot of possible authors of corrections in practice.

Approaching the problem on a practical level it has to be stated that "security" is - like "performance" for that matter - a relative term and cannot be used absolutely. There is some value of x you want to protect and there is some estimated effort of y needed to overcome your security measures. If x is (much) bigger than y you have a security problem, otherwise you haven't.

To appraise your security status simply put yourself into the place of the intruder: will it possibly pay off to overcome your defenses? Act, if the answer is "yes" or near there, otherwise don't bother.

It is similar to what i have countlessly told executives in meetings regarding "performance": you have some demand, which can be measured (in seconds, transactions completed, kilobytes, whatever) and there is a system having to meet the demand. It comes down to "does the system meet the specified demand - yes/no?" Performance is not being "fast" but "fast enough".

The same is true for security: what you protect and the efforts for protecting it have to be in proportion and the question is not "safe" but "safe enough".

bakunin