What would have prevented Heartbleed

We all know the potential damage Heartbleed could have caused. So, what are the solutions that could have mitigated or prevented it in the first place.

I would attempt to rank what I feel is important for a security setup to protect it's keys.

1. PROPER AND SECURE CODING PRACTICE WITH PROPER CODE REVIEWS!
   
2. Use programming languages that will help lessen confusion and mistakes like these.
   
3. Ensure that cryptographic libraries should be doing what they are suppose to do ! Cryptography is a hard subject and not everyone is good at this subject but everyone wants to use Cryptography to protect their digital assets. An application programmer who uses a particular cryptographic library may not properly understand encryption so it's hard to proof if the library is stable and "sane".
   
4. Basic education on Cryptography to CS/IT/BIS students should be made mandatory due to the wide spread use of Cryptography in modern computing.
   
5. Key handling to be performed somewhere else. Segregate the system into layers and sandbox. If one part is compromised, you have other layers to support and maintain a certain level of security.
   
6. Integrate a FIPS-140-2 Level 3 or higher installation of  Hardware Security Module (HSM) to solely handle the keys. Keys should always be handled in a HSM with FIPS-140-2 Level 3 or higher environment whereby the keys will never leave the secure environment and the HSM should be in working condition clean of no recent tamper events. Not everyone can afford a FIPS-140-2 Level 3 or higher HSM so it's pretty much a luxury item for those who can afford them. For those who can afford these HSMs, they should be using them properly.

If you noticed, proper education and secure coding has been ranked on top of everything else. The reason is due to the fact that, no matter how good the libraries and hardware/software are, proper understanding and usage is the key to security. Most of the standard algorithms out there that are well known are usually secure. It is the mismanagement on the human aspect that is causing so much security problems.

Don't frequent your forums

Read:

• http://jeff-vogel.blogspot.com/2011/01/three-reasons-creators-should-never.html

This blog is good advise and it's true that you need to filter the good ideas and the bad ideas in a forum. It isn't something easily done at all and users can give ideas that really spoil the next version or release of your software. But that doesn't mean that you should ignore ideas.

I personally feel that it is a balance between visiting a forum and taking in ideas and criticism and trying to stay focus and true to your project goals. It is very hard to give a sweeping statement like 'don't visit the forums'. No... it's a sweeping statement in anyway and too extreme. I would still advocate visiting the forums to find some ideas but it's up to the project leader to balance the fulfilment of ideas from users and the main project goal by retrospection and self understanding.

If people have something personal and negative for their hate messages... all you do is smile at them and leave them as they are or if you are an admin, you simply ban them and remove their messages for the act of committing personal insults.

Things like feature requests and bugzilla are for submitting bugs and feature requests anyways. These are the places bugs and features requests should go... rather than forums.

In the arts of Knowledge Management in IT, forums is a good place to find ideas but because it's a place that is rather 'fuzzy' it can be a 'love-hate' affair. It is nevertheless a place to go but it all boils down to attitude, goals, principles.... things that manages the person who drives the project. The people out there can say all the want.. helpful or not helpful stuff... but it is the people in the project rather than the people sharing their ideas that matter when it comes down to project planning and design.