Many security expert will back you in saying that Open Source 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).

When making arguments for Open Source, the most commonly cited metric is that mature, popular, open source projects like the Linux Kernel and mySQL have much lower defect densities than proprietary systems of similar complexities, but what studies I have seen on this topic use highly suspect methodologies by cherry picking from a very small number of open source projects that are already known to be well vetted, instead of using a random sampling of open source projects. This sort of cherry picking is how you manipulate statistics to produce whatever outcome you desire. This is equivalent to saying that Proprietary Software is more secure because Norton Antivirus is more resistant to hacking than a random sampling of open source projects.

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.

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 QoL 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.

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.

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.

How you should approach this problem

You can not use Open Source versus Proprietary as a reliable measure of security. In reality, you can never prove that any given system is secure. What you can do though is prove that a system is insecure, and that is done through penetration testing. If it is your job to make sure that the system a business uses is secure, then the best job you can do is to prove that it is insecure. As long as it holds up to everything you can throw at it, you know that it is at least as good as any other option you can not beat. Beyond that is just speculation.

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 QoL 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.