You live in some Detroit-like hellscape where everyone everywhere 24/7 wants to kill and eat you and your family. You go shopping for a deadbolt for your front door, and encounter two locksmiths:

Locksmith #1 says "I have invented my own kind of lock. I haven't told anyone how it works, the lock picking community doesn't know shit about this lock. It is a carefully guarded secret, only I am allowed to know the secret recipe of how this lock works."

Locksmith #2 says "Okay so the best lock we've got was designed in the 1980's, the design is well known, the blueprints are publicly available, the locksport and various bad guy communities have had these locks for decades, and the few attacks that they made work were fixed by the manufacturer so they don't work anymore. Nobody has demonstrated a successful attack on the current revision of this lock in the last 16 years.

Which lock are you going to buy?

If I can see the code, I can see if said code is doing something fucky. If I can't see the code, I have to just have faith that it's not doing something fucky.

It's not "assumed to be secure." The source code being publicly available means you (or anyone else) can audit that code for vulnerabilities. The publicly available issue tracking and change tracking means you can look through bug reports and see if anyone else has found vulnerabilities and you can, through the change history and the bug report history, see how the devs responded to issues in the past, how they fixed it, and whether or not they take security seriously.

Open source software is not assumed to be more secure, but it's security (or lack thereof) is much easier to verify, you don't have to take the word of the dev as to whether or not it is secure, and (especially for the more popular projects like the ones you listed) you have thousands of people with different backgrounds and varying specialties within programming, with no affiliation with and no reason to trust the project doing independent audits of the code.

The code being public helps with spotting issues or backdoors.

In practice, "security by obscurity" doesn't really work. The code's security should hinge on the quality of the code itself, not on the amount of people that know it.

One thing people tend to overlook is: Development costs money. Fixing bugs and exploits costs money.

In a closed source application none will see that your software is still working with arcane concepts that weren't even state-of-the-art when written 25 years ago. The bug that could easily be used as an exploit? Sure, the developer responsible for it did inform his manager around 50 times he needs time and someone from the database team to fix it. And got turned down 50 times as it costs time and "we have to keep deadlines! And none noticed this bug so far,so why should now notice now?"

With open source code you get more eyes on it. Issues get fixed quicker.

With closed source, such as Photoshop, only Adobe can see the code. Maybe there are issues there that could be fixed. Most large companies have a financial interest in having "good enough" security.

Because "some nerd out there probably would have found any exploits for the X years its been released" is the general assumption about open source software.

Others have mentioned this, but to make sure all context is clear:

• FOSS software is not inherently more secure.
• New FOSS software is probably as secure as any closed source software, because it likely doesn't have many eyes on it and hasn't been audited.
• Mature FOSS software will likely have more CVEs reported against it than a closed source alternative, because there are more eyes on it.
• Because of bullet 3, mature FOSS software is typically more secure than closed source, as security holes are found and patched publicly.
• This does not mean a particular closed source tool is insecure, it means the community can't prove it is secure.
• I like proof, so I choose FOSS.
• Most people agree, which is why most major server software is FOSS (or source available)
• However that's also because of the permissive licensing.

Zero day exploits, aka vulnerabilities that aren't publicly known, offer hackers the ability to essentially rob people blind.

Open source code means you have the entire globe of developers collaborating to detect and repair those vulnerabilities. So while it's not inherently more secure, it is in practice.

Exploiting four zero-day flaws in the systems,[8] Stuxnet functions by targeting machines using the Microsoft Windows operating system and networks, then seeking out Siemens Step7 software. Stuxnet reportedly compromised Iranian PLCs, collecting information on industrial systems and causing the fast-spinning centrifuges to tear themselves apart.[3] Stuxnet's design and architecture are not domain-specific and it could be tailored as a platform for attacking modern SCADA and PLC systems (e.g., in factory assembly lines or power plants), most of which are in Europe, Japan and the United States.[9] Stuxnet reportedly destroyed almost one-fifth of Iran's nuclear centrifuges.[10] Targeting industrial control systems, the worm infected over 200,000 computers and caused 1,000 machines to physically degrade.

Stuxnet has three modules: a worm that executes all routines related to the main payload of the attack, a link file that automatically executes the propagated copies of the worm and a rootkit component responsible for hiding all malicious files and processes to prevent detection of Stuxnet.

Wikipedia - Stuxnet Worm