I work for a company which develops tools for software quality, a company which not only offers its services for free to open source developers but also unilaterally runs its own tools against many high-profile open source projects, and Debian packages in particular. This company also publicly pursues and promotes awareness of the sorts of bugs you're talking about, because the fact that we can find them and our competitors can't is a major selling point.
So bear that all in mind when I tell you that you're full of ****.
Closed-source software is universally worse than open-source. Most people who write closed-source software are five flavors of don't-give-a-**** between boredom and bad management, and that's before you consider the (I would have expected) even more obvious and direct means for a closed-source project to be sabotaged under a secret court order than to hide security flaws inside code anybody can read or even just run cppcheck against. All of this compounds against the fact that software development is an inherently difficult activity requiring utter perfection the first time around, which isn't something that human beings can deliver, and is the real reason that open-source software is buggy.
Let's look at a couple of recent open-source SSL bugs, since you seem to be interested in those sorts of bugs specifically.
Apple's open source SSL bug from back in February looked like this:
What does this mean? If the conditional branch isn't taken, it jumps to the fail label. If the conditional branch is taken, it jumps to the fail label. So any code following the conditional is skipped. Sure hope it isn't important! (Spoiler: it is).
Clearly a dastardly NSA plot, right? Except this sort of bug shows up all the time, thanks to distracted developers resolving merge conflicts under a time crunch. You want to know who's the real culprit here? Here are some clues for you: open concept offices where nobody can concentrate, poor code style guidelines, no institutional use of static analysis (which can detect that a huge chunk of code can no longer be entered), poor testing standards (since the tests covering the rest of the method should always fail after this change), and no measurement of test coverage (since you'd immediately notice that some of this code is no longer covered by tests). i.e. poor management and technical leadership company-wide.
Heartbleed is an out-of-bounds array access bug in OpenSSL. Clearly a dastardly NSA plot, right? Except this is the most common form of C/C++ security bug. It's practically guaranteed that any significant C codebase has at least one of these bugs, because C is among the worst possible languages for writing secure code and it's actually impossible to do without invoking at least some non-portable behavior. On top of the inherent difficulty of writing secure C, the developers of OpenSSL are frankly very poor engineers in a lot of ways. The internet has beaten them up a lot so I won't expound on this, but it's just not very surprising that they would accidentally introduce an error like this one.
And finally, be realistic here. The NSA isn't dropping security vulnerabilities in SSL. They don't need to. SSL is terrible and it doesn't work; the chain of trust is already controlled by American companies, users are trained to ignore all potential MITM attacks, and for the rare few people technically sophisticated enough to self-sign they will just threaten and shoot and subpoena until they control the endpoint, which statistically speaking is in a Five Eyes nation anyway. And even if your conspiracy isn't bull****, now that Raytheon employees carry burner laptops there are an awful lot of folks in the world who'd love to crack their VPN, and lil hint: none of those folks work for the NSA.