OpenSSL Heartbleed 的大惨败没有任何异议的证明了人们一直怀疑的事情：仅仅因为开源代码只是用来检查用的，但并不意味着它已经完全被检查过了，而外是安全的。
这一点是至关重要的，原因在于开源软件的安全性完全依赖大量拥有专业技能的程序员检测代码，并迅速将含有Bug的代码移除或修复。这一点在Linus's Law（林纳斯定律）也提到了：“只要有足够多的眼睛，就可让所有问题浮现。”
但是我们来看看使用OpenSSL之后发生了什么事。Robin Seggelemann是德国Munster大学的一位程序员，通过添加一个新的Heartbeat保活功能来更新OpenSLL代码，但不幸的是，他错过了一个必要的代码验证来检查一个特定的变量是有现实价值的。OpenSSL开发团队的成员在发布更新版本之前也没有进行检查，这些疏忽都是导致Heartbleed Bug出现的最主要诱因。
如果他们觉得代码里没什么Bug的话，别说是一个审查员，即使是一大堆审查员也找不出这个微不足道的小错误。这个Heartbleed Bug一直存在了两年，在OpenSLL里面，在浏览器里面，在Web服务器里面，最终还是没有一个开源社区发现它。难道可以将此归咎于没有足够多的审查眼睛吗？
商业渠道缺乏对开源代码的审核
同样令人担忧的是，OpenSSL 此前一直被当做一个重要组件使用在硬件产品中，这些硬件产品由像 F5 Networks、Citrix Systems、Riverbed Technology 和 Barracuda Networks之类的商业公司提供，这些公司在使用它们之前都没有进行足够的审核。安全云网关厂商Forum Systems的CEO Mamoon Yunus透露了上述内容。
他说：如果把OpenSSL商业化，作为供应商是有责任提供更多的眼球进行审核，因为，一旦你打算建立一个基于开源组件的公司，对代码的所有权是必不可少的。
然而，Yunus 认为供应商只关心OpenSSL作为他们硬件产品上的一个有用的螺栓而已，而且，就因为它是开源的，所以他们假定已经有别的开发者对OpenSSL的代码进行过检测了，而自己却没有对它审核的责任。他说：“这就是从开源角度思考问题所产生的疏忽大意结果。”Yunus建议，商业厂商应该尽可能的花人力物力在开源代码上施行同行评审制度，并且使用静态和动态分析工具来确保代码是无Bug的。
OpenSSL、Truecrypt暴露出开源代码审核的短板
许多开源项目现在都面临一个问题，那就是很难明确的归责于Seggelemann 或者是其它的 OpenSSL 团队，实施一个严格标准的代码安全审核是一件及其耗时且需要很高的技术能力的事情。换句话说就是代价很昂贵。
这里来介绍一下另一个开源项目：TrueCrypt加密程序。此项目十年前就已经开始了，现在它的带安全开放，有兴趣的人都可以观看。但是最近，随着Indiegogo and Fundfill网站上募款活动的进行，最终筹集了6万美金的资金，帮助TrueCrypt的代码度过了一个适当的安全审计。
代码审计员说：总的来看，引导程序的源代码和Windows 内核驱动源代码并不满足源代码的预期标准。
令人担忧的是，只有在被曝光之后，他们才招聘大量人力资源进行代码审查。开源社区在过去的十年里有足够的机会做这些事，但事实是，社区根本没有时间、技能或资源（包括资金）正确地完成这项工作。
将安全性隐藏起来从来就不是一个好主意，但一旦漏洞被公开出来的话，他们就需要立刻将其修复。尚不清楚OpenSSL团队是否能够做到这一点，关键是这个项目只有一个全职的维护者，或者说，不管是使用OpenSSL的软件还是硬件产品，包括OpenSSL软件本身都需要及时的更新维护。
后Heardbleed时代更应该加强安全意识
现在有一个好消息，对于那些关心像OpenSSL这样的开源项目的安全的人来说，这是一个好消息：Core Infrastructure Initiative (CII)将会以自己的方式帮助这些开源项目，CII是一个由Linux Foundation建立的新项目，以应对Heartbleed事件。其目的是传送资金给像OpenSSL等需要钱的软件项目，因为这些项目对互联网的功能至关重要。
“我们全球的经济是建立在许多开源项目上的。”Linux基金会的执行董事Jim Zemlin说。“我们现在可以支持更多的开发者和维护者从事全职维护工作，通过他们对重要的开源项目施行全方位的支持。”
来自CII的支持可能还包括资金安全审计、计算和测试基础设施等方面的支持。到目前为止，约400万美元的筹款已完全可以支撑CII在未来三年对开源项目的维护，捐款的公司包括Google、Microsoft和Facebook。