The Superior Security of One or the Other is a Cultural Bias, Not a Fact
Many security experts will claim that either Open Source or Proprietary is superior, but there have been shockingly few reliable studies to back this claim. Most of the articles you find on this topic are opinion pieces that cite other opinion pieces (if they cite anything at all).
Those articles that do make a strong, apparently research based claim all seem to use flawed methodologies. When making arguments for Open Source or Proprietary, most articles will cite the best examples of one thing they can find and compare it to any sampling of the other that seems to prove their point. So if you want to "prove" open source is better, you can safely compare the Linux Kernel and mySQL to any random sampling of proprietary software, and if you want to prove proprietary is more secure you could compare something like iOS to any random sampling of open source. This sort of cherry picking is how you manipulate statistics to produce whatever outcome you desire, and the Open Source/Proprietary debate is ripe with it.
The only research I can find on the topic that is not using an obviously flawed methodology is a 2005 study Software Vulnerabilities: Open Source versus Proprietary Software Security. This paper studied a random distribution of hundreds of open and closed source projects and found that there was no noticeable difference between how often Open Source and Proprietary software actually gets breached. The one actual advantage you do see with open source, is that they typically release patches faster when a breach does happen... but that said, proprietary software is more likely to include functional auto updating features; so, while Proprietary often takes longer to release a patch, Open Source is more likely to not get patched after it is released. Frankly, I think this study needs to be repeated to account for cultural development changes in the past 15 years, but I suspect the results will remain the same. This is because most of a system's final security hardening comes from post-release community feedback which follows more or less the same patterns regardless of open/closed source.
How you should be approaching this problem
Since there is no statistically significant difference, you can not use Open Source versus Proprietary as a reliable measure of security. In fact, you can never prove that any given system is secure. What you can do though is gather specific evidence that a system may be insecure.
Step 1: Look up a products CVEs.
Many products have publicly reported security vulnerabilities which are in some cases yet to be fixed. Many products have open CVEs that demonstrate vulnerabilities that developers have put on the back burner because they are not considered critical: either because they grant so little, or because they rely on rare implementations to exploit. If you find open CVEs that would be a problem to how you plan to implement the product, then you can stop here and safely say you need to pick another product.
Step 2: Look at product's community size & patch log.
While this is less conclusive than CVEs it can give you a good idea about how to judge the product's maturity.
A product's community size tells you a lot about how many opportunities a product has had to be exploited in the past. If a product has millions of downloads, then you can assume that many of those users should statistically have the skill set or random luck to have discovered and reported most, of the major security issues by now. But a product with a community size of just a few thousand could easily have a lot of yet to be discovered exploits.
A patch log can quickly give you a feel for how capable the developers are at getting things right the first time. If the log includes a lot of security patches within the past few months, that could indicate that the developers are doing a poor job of addressing security issues themselves before releasing updates. I would not trust such a product with anything important. Another bad pattern is to see no patches at all released within the past several months. This typically indicates that the developers have abandoned the project and are not fixing issues even if they are being reported. The most reassuring pattern is usually seeing a lot of security patches in a product's more distant past, and mostly Quality of Life updates in the recent past, because that tells you that the product has actually been subjected to real world implementation testing, and been patched until the community could not find any more exploitable vulnerabilities.
Step 3: Vulnerability & Penetration Testing:
This last part requires a bit more of a specialized background and tool set to do right; so, I would not consider it necessary unless your organization has particularly high cyber security goals.
Vulnerability testing is the scanning of an application for cases of "not best practices" that may be exploitable. Often times if a vulnerability scan comes up with a lot of issues, there is a good chance that at least one of those is exploitable, but you don't really know until you test it.
Penetration testing is the actual testing of exploits against a system. Sometimes, a system will fail a vulnerability scan, but not actually be exploitable in its implementation. So, the real proof of if a system is actually exploitable comes down to this. If a product fails a single penetration test, then like an open CVE, you have a factual piece of evidence that the product is insecure.
Conclusion
There is nothing wrong with being skeptical of any piece of software, but making a judgement call based on Open Source / Proprietary in lue of more measurably significant factors could leave you with a less secure business solution.