自欺欺人的“众人之眼”，与软件开发的三重门

显然，开源代码所谓的“众人之眼”，并不能有效地杜绝安全漏洞，至少不能保证在黑客降临之前消灭隐患。

如今，开源代码爆出安全漏洞的事件还在不停发生，而很多项目并没有查找和修复问题的机制。这么一想，GitHub的程序员用户算是幸运多了，至少他们还能掏赎金把自己的代码买回来。而那些被盗走了信息的普通用户，也许只能成为黑客们的“肉鸡”了。

但问题是，如果我们吃了一家餐厅的食物而中毒了，那么可以起诉这家餐厅。但同样的逻辑在数字世界却不成立了。如果用户因为一个软件而中毒／被盗窃个人信息，他几乎没有办法找平台负责（参考Facebook隐私门）。而且软件开发商还会在用户许可协议中进行“免责”，要求用户同意不因为安全漏洞而起诉它。

为此，剑桥大学安全研究员Richard Clayton博士曾提出，要让软件开发商为可避免的安全漏洞带来的损失负起责任。欧盟官员也一度考虑，试图将开发人员的草率编码行为导致的恶意漏洞引入法律。但最终都不了了之。

微软是这么反驳的：软件公司也是（黑客／罪犯）入室抢劫的受害者，大众不能起诉门和窗户的制造商。

听起来是不是快要被说服了呢？打脸的是，在一个针对500多名开源项目维护者的调查中，清晰地展示了，只有30％不到三分之一的开源工程师具有较高的安全意识。这意味着，程序员和软件开发商并没有如大众期望的那样，将门和窗户建造的更牢固一点。

导致这一现象的，是一种蔓延在整个软件开发产业链上的“迷之自信”：

首先，开源社区顾此失彼的安全审查。一般情况下，为了让开源项目免于灾难，社区会依据Linux的Linus Torvalds，用他们的“千眼”不断地审查代码。运维人员必须十分小心，筛选代码，检查潜在的漏洞，并将其报告给安全数据库。

但是，由于开源资源分布散而广泛，很多漏洞软件会在GitHub，nowhere．net等网站上肆意流通，因此因此持续监控、赶在黑客前面发现漏洞也就成了一项艰巨的任务。

其次，日益消弭的开发门槛和随性的开发者。以往，能够开发开源组件的开发者本身素质相对较高，代码质量较高，也使开源组件出漏洞的可能性较小。但随着许多界面友好的平台出现，像是GitHub，即使是新手编程也可以利用Git；任何人都可以免费注册和托管公共代码存储库，还有人利用GitHub来进行其他类型的项目，比如写书。

缺乏安全基础的开发者增多，许多潜在的组件安全特性被忽略，而这些特性往往是造成漏洞的罪魁祸首。

而且，即使是成熟的开发人员，也需要不断在应用更新过程中解决新漏洞。但很少有程序员会审查旧工程中用到的库，一般就是到开源项目页面下载下来，集成到自己的应用中，然后就再也不管它了。这些软件自然也就像凤梨罐头一样，很快就过期。

在此基础上，企业利用开源软件或组件来进行开发，就像在一个摇摇欲坠的积木塔上盖楼一样，全靠运气。

绝大多数企业的开发团队，对开源软件的使用都非常随意，这就给应用的安全风险管控带来了极大的挑战，运维人员也无法知晓软件系统中是否包含了开源软件，包含了哪些开源软件，以及这些软件中是否存在安全漏洞。

而大多数云供应商在将企业数据上传到集群之前都不会加密数据，比如OpenStack就不提供任何数据加密方法。这就需要企业和用户自己先加密数据，再上传加密后的数据和管理密钥本身。

还有一些公司由于兼容性问题、合规问题等原因，无法迁移到最新版本的开源代码，只能继续使用包含漏洞的旧代码。据Snyk称，只有16％的漏洞补丁是向后兼容其他版本的。这也给黑客们创造了不少机会。

总而言之，在这样从源代码创造、分享、开发等一系列产业链上的“不着调”，造成了“涟漪效应”，最终缔造了令人头痛的安全事故。

那么，除了改密码、打补丁之外，产业端有没有一些更“治本”的办法来杜绝此类隐患呢？