Did you patch OpenSSL? If not, why are you reading this? Go patch!

For everyone else, go ahead and calm down. Let’s be reasonable here. The danger has passed for now. The real danger here is not even Heartbleed, frankly.

We’re not saying Heartbleed wasn’t dangerous. What we are saying, however, is that the real problem wasn’t the ability to read data from OpenSSL’s RAM cache. The real problem was the fact that an entire world of Web-based computing relies on a project that amounts to little more than four or five people who aren’t paid very much.

(Related: Some tech giants are banding together to prevent the next Heartbleed)

The industry needs to support OpenSSL with more resources, more eyeballs, and more developers. As of this writing, the OpenSSL development team consists of 11 people. We’ve heard that only about two of them were actively maintaining the project. This is exactly why the OpenBSD folks decided to turn their gaze upon OpenSSL. The expertise of the OpenBSD team will shine a lot of light into the narrow corners of the OpenSSL project.

But we’ll need more than them. Everyone needs to tuck in and fix OpenSSL. (Perhaps “fix” is not the right phrase for what needs to be done, however. Perhaps the proper word is “advance.”)

A lot of ire came out during the weeks following Heartbleed, and much of it was aimed at the way OpenSSL behaves and how it is designed. One spurious criticism was that C and C++ should not be used for security-critical infrastructure.

That’s no solution, and we’ve all known how to develop securely in C for many years. Often exploits come from lazy coding, not the fact that the language does not support memory management.