In the wake of Heartbleed, there’s been a chorus of “you can’t trust open source! We knew it all along.”
It’s amazing how short memories are. They’ve already forgotten Apple’s GOTO FAIL bug, and their sloppy rollout of patches. They’ve also evidently forgotten weaknesses intentionally inserted into commercial security products at the request of certain government agencies. It may be more excusable that they’ve forgotten hundreds, if not thousands, of Microsoft vulnerabilities over the years, many of which continue to do significant harm.
Yes, we should all be a bit spooked by Heartbleed. I would be the last person to argue that open source software is flawless. As Eric Raymond said, “With enough eyes, all bugs are shallow,” and Heartbleed was certainly shallow enough, once those eyes saw it. Shallow, but hardly inconsequential. And even enough eyes can have trouble finding bugs in a rat’s nest of poorly maintained code. The Core Infrastructure Initiative, which promises to provide better funding (and better scrutiny) for mission-critical projects such as OpenSSL, is a step forward, but it’s not a magic bullet that will make vulnerabilities go away.
So, what should you trust? I’m not going argue that you should “trust” open source code; it’s unclear to me what that kind of trust even means. But if your response is, “then, we’ll go back to the vendors to get good trustable code that has gone through audits,” well, forget about it. Count me out. Commercial code has failed us before, continues to fail us, and will fail us again. “As a dog returneth to its vomit, so a fool returneth to his folly.”
The bottom line is that, in the security game, there’s no one to trust. All trust is misplaced, and blind faith in any software provider will end up in misery. And that’s probably the way it should be. It’s like walking through a tough neighborhood on a dark night: be careful, keep your guard up, watch what’s going on. And keep your systems patched.