This would be much easier than compromising specific algorithms or KE protocols. Cheap, too. All it takes is plenty of patience.
"patently false". Proof needed, please, we have enough FUD.
Meanwhile, in OSS land, we have a steady stream of easily-prevented or detected defects that compromise security. Just like in most proprietary shops. Like proprietary, those OSS projects producing highly-secure stuff are done by great designers/coders with careful review and testing processes. The community-developed OSS hasn't reached the assurance of aforementioned proprietary systems or some in academia. Yet, highly correct or secure stuff seems equally rare in both types of development with proprietary having a bit more just because there were people paying professionals to build those. In theory, with free/cheap labor, OSS could eventually produce more but there's not enough interest.
So, the endless stream of bugs in both closed and OSS software that are often really old disproves many eyes argument. It didn't work for even shallowest bugs consistently, much less deep ones. Software quality comes from people taking responsibility and putting time into QA, esp design/code review. OSS, shared-source proprietary, closed-source... always same requirement that gives quality.
Software security is unfortunately, a goal, not an absolute. The process is both fluid and dynamic, and the improvements iterative.
To directly address the tenor of your comments, perhaps it would be better to say, "More eyes make bugs more shallow."
Landmark work by Myer in 1980 fleshing it out http://csrc.nist.gov/publications/history/myer80.pdf
Demonstration of simplicity of it against NFS by Anderson http://www.dtic.mil/dtic/tr/fulltext/u2/a401762.pdf
Lack's use of one against Windows XP https://calhoun.nps.edu/bitstream/handle/10945/962/03Jun_Lac...
All the same group, Navy Postgraduate School, with some of the professors being founders of information security field. They never forget the old stuff that works. Always mention the old strategy, high-assurance, as a solution as it was only thing proven to work. People never learn, though. Hence, endless opportunities in new projects for 0-days and subversion. ;)
When the bug is a security vulnerability (e.g. Hertbleed), then everything work as it should, I can log into all the servers I have access to and all the functionality I want is there. The difference is that someone else can get access to my system or get access to information they are not supposed to. You don't discover this by using the system, you have to actively be looking for vulnerabilities. This is quite different from other kinds of bugs.
Whether or not an open source project is popular, whether contributing looks good on a resume, the number of competent programmers in the relevant fields with time to spare, and even the aesthetic quality of the code probably have influence on how much attention it gets. A hip framework is bound to get much more attention than an old, horrifying to look at mess of C, even if the latter happens to be mission critical to the internet.
All bugs might be shallow, if the number of eyes scaled in proportion with the amount of code, and the number of languages remained constant. The problem might be that people simply assumed Linus' law to be axiomatic, which results in kind of a Someone Else's Problem field permeating the community, as well as an implicit trust in the security of FOSS code which might not necessarily be warranted.
Are there examples of this actually happening— that is, a nominally trusted committer intentionally adding a backdoor to a widely used OSS project? If this is in fact "the MO for said agencies", then there should be several examples you can point to.
