> There's no guarantees what you're getting even if it's open source, unless you read and understand the source code :)

Obligatory reference to Reflections on trusting trust [1]

[1] https://dl.acm.org/doi/10.1145/358198.358210

>The set of computer users who a) have the knowledge to do security code review and b) have the time to review the programs they run is, I would expect, fairly small.

Even a small number of those who understands can make a huge noise, because if comment is well grounded, it spreads exponentially by people who do not need to understand all the details.

And frankly how much those who understand you really need for each project? The thing is, if you are worried you can always look, which is not the case if you have nowhere to look.

Also expert is not always required just to see there is no brutal obvious harm intent, which covers a lot of cases

There are a number of cases, even with just bugs, which won't be deliberately hidden (unlike malicious software) where critical security issues have gone unnoticed in major open source software packages for year (e.g. shellshock).

Then you have the fact that if it's deliberately malicious things can be hidden such that even experienced code reviewers (who are not plentiful) could be fooled. A good example of this is the underhanded C contest http://www.underhanded-c.org/_page_id_2.html .

Sure an open source user may catch malicious behaviour, but then security researchers find malicious behaviour in closed source software pretty regularly via reverse engineering or binary analysis.

This isn't an anti-open source thing, it's a reflection that open source often isn't much of a signal of safety, unless further work has been done and continues to be done on a regular basis.