This is where statistics of "many eyes" and "sunlight as disinfectant" hits home. However bizarrely improbable that anyone would just wander along and find a a bug, people do, because they can. With proprietary/closed code, the probability is zero.
1) Someone noticed something that was odd. They were able to go look at what was happening, along with source code and see that suspicious things had happened.
2) They were able to reach out to security experts across almost all the main distributions and get additional eyes on it who also confirmed there was a security thing and were immediately able to take actions to deal with the insanity.
3) Disclosure went public, and lots of eyes with expertise across all kinds of aspects of software and security have been able to tease apart what was done, and how, figuring out risks etc.
4) Other suspicious commits across other bits of software, from the same developer, have been tracked down and identified and the work continues in figuring out consequences.
5) Every distribution has become alert to the minutia of the ways that things were compromised around the build archives etc and have been able to start figuring out how to catch other cases and stop this in future. Stuff will start to spread to various open source projects as distributions work on their packaging tooling/processes, helping ensure other projects don't become vulnerable to compromise through the same mechanisms.
If you contrast this with closed source, where unless there is an exploit, it's reports of e.g. "Your software is running slightly slow" like in the xz/openssh case, is unlikely to get much attention, if any. Then once the closed source company finally finds out about it, at best you'll get a very carefully phrased explanation of what happened, revealing just the bare minimum amount of data they think they can possibly get away with. That badly harms the whole industry's ability to avoid repeats.
On top of that, the vast majority of people won't know what to do if they find a bug. In the distant past I was one of those people, and only realized some of the bugs I saw in hindsight. It's been nearly 30 years so the details are mostly gone now, but I remember messing around in Windows and I could make the Microsoft Netmeeting application crash with a buffer overrun error.
Of course I was really new to computers then and understanding that buffer overflows in networked applications were really bad things (and seemingly beyond a lot of people that had been in the industry). Even then attempting to report security issues back in those days would have been far more difficult (hell and even risky in many cases).
So really it is many things that are required. Running into the issue. Having a deep enough understanding of computing to realize the issue is bad. Having a means of reporting the bug to a place where people will look at it. And a security culture that knows when and how to act on the bug report.
1) Observing
2) Understanding as bad
3) Reporting (or fixing)
4) Closing the loop on remedy
Both proprietary and open code runs into problems at (3) because people don't want to hear it, for commercial or ego reasons.
With FOSS at least you get the direct intervention route of simply fixing and publishing the patch, which done responsibly may or not force a maintainer's hand. With proprietary you can piss into the wind and be ghosted, or sued, hence more irresponsible/anonymous disclosure.
Anything that maximises the likelihood of getting from (1) to (4) safely must be a good thing, so I think FOSS yields the better security model.
People discover bugs all the time in closed source software...
Ah I see what you mean.
Problem of language then.
"Finding bugs", to me as a coder, means something different from observing the effects of bugs.
Sure, I can see incorrect behaviours in lots of proprietary software. And I can guess what might cause it. But without the source code that's not the same as "finding bugs".
Reporting bugs vs finding them is perhaps what you're looking for, but I'd argue finding is overloaded. It's perfectly valid to kick the tires on some software and find some bugs.
I've found thousands of bugs in closed source software before, and subsequently reported those bugs.
This is a good point of course. Implementation, protocol and runtime bugs are indeed invisible from the source POV. As are lower level Ken Thompson "trusting trust" [0,1] bugs in your tool chain.
Most of all though, many "bugs" are just malicious functions the coders meant to put in there.
[0] https://cybershow.uk/episodes.php?id=2
[1] www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf
They however didn't find the cause of the bug.
And in many software, open source or proprietary, there are a lot of bugs sitting out in issues tracker for days, weeks, months or even years.
I can think of at least two or three occasions where I discovered an exploitable vuln, didn't have a contact to report it to, decided I didn't want to have the back-and-forth of some non tech company threatening me with a lawsuit, and took no further action (typically for lower severity vulns in less important services).
With open source software you can hop on GitHub and dig deeper into a vuln or other bug and actually report it somewhere.
What I was wondering when I read the same sentence you quoted: how many really serious security bugs like Heartbleed, CVE-2008-0166, or the zx drama are happening without people finding out about it and publishing their findings?
The problem with closed source is there is a third possibility: ignore the problem and save on the cost of fixing it. The responsible disclosure regime we have now is because companies almost always chose this option, ie denied it was a problem and refused to invest to fix it. When the discoverer then released the bug anyway they we so enamoured this this approach tried solving the disclosure problem by suing the researcher.
If you think companies still don't ignore security issues when they are given a choice, you are kidding yourself. The problem compounds because when you do find a bug open source makes it easy to see if you can use it to create a security issue. In proprietary code that's much harder, so I'm 100% certain a fair number of potential security issues don't get patched because it isn't obvious how to exploit them. Nonetheless they are chinks in the armour, so they give the bad guys a excellent set of starting places to start looking.