By Mamoon Yunus | Date posted: May 12, 2014
The flensing began rather quickly with the OpenBSD team cleaning up 90,000 lines of code within a week of Heartbleed. OpenSSL then got royally fṓṝked by OpenBSD and LibreSSL was born. The divergence between OpenSSL and LibreSSL continues while OpenSSL fights against change and LibreSSL tries to modernize and flense the OpenSSL codebase.
Larry Seltzer, contributing editor at ZDNet published “OpenBSD forks, prunes, fixes OpenSSL” where he reports that OpenBSD has removed 150,000 lines of content and 90,000 lines of code as a part of the OpenLibre initiative. The activities of the OpenBSD team is tracked in a blog site:
As you review this blog, here are a few items that become apparent:
- OpenSSL is unequivocally fṓṝked.
- OpenSSL and OpenLibre continue to diverge.
- OpenSSL has to be modernized – a process that will take significant time and resources.
- OpenLibre offers a blueprint to all that’s wrong with OpenSSL. It might as well offer a new set of attack vectors for OpenSSL.
A word of advise to those that use open source components in commercially released products such as load balancers, switches, application and web servers:
- Review competing open source initiatives: see checkin intervals, activity levels, full-time engineers, history of vulnerabilities and coding practice as a part of your evaluation process. Do your homework.
- Know what you’re adding to your code base. Once you have added an open source component, it’s your responsibility to ensure security, integrity, and robustness of the product that enterprises pay you for.
- Build a QA team that performs white, gray, and black box testing, especially when you upgrade your components.
- Build a Security team that audits security specific components in your product.
With “millions of eyeballs” examining OpenSSL code one would expect a more robust, well maintained, up to date and optimized security library. Clearly this is not the case. OpenSSL is a case of everyone thinking that someone else is responsible while the reality is that no one is responsible. A technology company that bolts-on such components onto their code-base has to take responsibility for their engineering process of testing and auditing their products.