I sometimes see people still trying to make the argument that secretive programming is more secure.

Nowadays they tend to attack the pros first, so I will counter their counters first oo.

An argument often made against the "thousand eyes" argument for open source security is that nobody works up the guts to check it anyway.
In practice there're several methods to ensure this happens.
First open source projects have a single maintainer who's often in that position for several decades who has to approve every line of code, it's their position to ensure every line is checked.
Now you might rightfully point out this causes two problems
a. We're still trusting this one maintainer.
b. On large projects one maintainer isn't enough to check every line of code
The solution for b is more maintainers on specific aspects of the code base reporting to one central maintainer who still has to sign of on everything, but can now be slightly more selective.
On a. the answer multifold
A. Many enterprises publish their independent security assessments of larger open source projects.
B. That maintainer got in that position by providing a product people wanted. For some reason malware makers tend to avoid that and simply provide pure malware.
C. Hosting providers tend to get skittish with hosting malware and for them its also easier to check it for malware.
D. The open source ecosystem itself has an internal distribution system that involves checking the changes made to the source code every version(repository maintainers).

Second open source projects tend to be more verifiable when running.
Open source projects don't have any ip to hide and thus less reason to sabotage debugger functionality in production. Also they tend to be run by people who value transparency and thus generally shun obfuscation techniques
As such virus scanners and other malware analysis tools should have a more easy time detecting malicious behavior, since the behavior in general is more clear.

I also think there other more important reasons, why open source software is more secure against many attacks.
1. Malware developers operate in the shadows, because their work is actively fought by agencies and private companies. A central part of malware analysis is attribution. This is most often done by determining which tools the attacker used from the patterns in the code. This is much easier with source code and binary code than binary code alone.
2. Open source projects tend to have disproportionate amounts of access to developer time in comparison to their access to capital assets. As a result of this many open source projects tend to operate more strictly to the principle of least privilege, because privilege often costs money. This includes things like: operating by default in user space, because root could open them up to fees and liability, airgapping the application, because hosting a server costs money and avoiding integration with payment providers, because that requires lawyer time and once again fees.
3. The zeroth right assures no legal blockades for legal security researchers reporting bugs.
4. "Sanction attacks" where a government decides to block your access to some software are solved with a fork.

Now the arguments for security through obscurity.
The bad guys will need a longer time to figure out bugs. Yeah and you will need a longer time to figure out where the bug comes from, since the researcher who discovered it can't just point to the offending line of code and thanks to binary diffing the bad guys can at least figure it out next update.
Also since nobody can see what you do

How would I openly increase security for open source projects.
Most proposals for more security in open source tend sacrifice openness.
Here are some that increase it.

• 
  Stricter "full source" policies in the sense that binary blobs shouldn't be allowed anywhere. If it seems unavoidable just write a script that generates your blob from arbitrary data or random generated data. This would've caught the xz before maintainership was even transferred.


• Enable/force pull request senders to explain the value of the current addition, because every supply chain attack on open source I can name had no clear value proposition for their commits, while this tends to be the norm for commits.


• Make compilers also generate security manifests with the things they need access to. When this manifest expands something is happening.


• Automate maintainer change detection mechanisms, so one can make the new maintainer start the trust building process again.


• Allow one to set privilege for git maps. Testing code shouldn't be able to edit other software ever.