开源软件仍然是软件，漏洞是预料之中的。与文件系统错误或内核崩溃不同，它们在发生之前不会引起任何痛苦。
上周，GCN 的 CyberEye 发表了“针对开源的攻击呼吁改进软件设计”，其中夸张地宣布 2014 年是政府部门开源的灾难之年。他们的最终建议是每个人都专注于良好的软件开发实践和自动静态分析。就目前而言，这很好。不幸的是，这种推理方式留下了一些关于开源和安全性的扭曲的比喻和误解。这对我来说就像猫薄荷一样，所以我们开始吧。
我们从 Drupal 项目的 最近的不愉快事件 开始说起。SQL 注入漏洞虽然严重，但并非不常见。它实际上是世界上 最常见的漏洞。使该漏洞利用成为新闻的原因是在披露和广泛利用之间的时间非常短：“如果未及时应用补丁，则 Drupal 安全团队概述了将网站恢复到健康状态所需的漫长过程。” 基本上，您有七个小时的时间来修复它，然后邪恶的机器人就会降临到您的服务器上。
这不是开源问题，而是软件管理问题。
漏洞是预料之中的。WhiteHat Security 表示，86% 的网站（包括开源和专有网站）都存在像 Drupal 这样的缺陷。是的，我们可以期望有更好的开发人员和更好的工程流程，静态分析可以帮助及早发现问题，但更重要的是制定计划和策略，以便快速识别这些问题，验证补救措施并应用它。
在这种情况下，GCN 的下一个论点更加愚蠢：“……开源本质上对最广泛的可能损害它的坏人开放。” 这是有充分理由未署名的。像 Bruce Schneier 这样的世界级安全专家曾多次 多次 声明，这表面上是错误的。GCN 自己也发表了一篇关于 DHS 与 Coverity 合作 衡量开源项目中的缺陷密度的文章，这证明了这一点。作为一个论点，它就像一个精疲力尽的街头艺人，从昏迷中醒来，每当开源与安全性同时被提及时，都会睡眼惺忪地跳踢踏舞。无论如何，您对开源的看法都不会对 Drupal 漏洞产生任何影响。重要的是响应的速度，而不是缺陷的来源。
值得花一点时间来讨论商业支持在这种情况下的重要性。开源社区可以做很棒的事情，他们的协作动态在很大程度上 解决了集体行动问题。然而，安全漏洞的诀窍在于，与文件系统错误或内核崩溃不同，它们在发生之前不会引起任何痛苦。这使得项目很难识别和修复问题，除非他们有技术娴熟、警惕的开发人员寻找问题。获得这种关注的最佳且最便宜的方法是付费请人。这就是您在使用商业支持的开源项目时所购买的东西。
商业支持还意味着通过可信渠道及时交付修复程序。Drupal 问题如此棘手的原因之一是该漏洞利用通过假装已自行修复来掩盖其踪迹。因此，人们会登录 Drupal，检查漏洞但一无所获，即使他们没有应用修复程序。非常糟糕的事情。您可以通过使用受信任的软件包管理工具并仅应用由您的提供商数字签名的修复程序来避免此问题。
安全软件管理实践的概念并不新鲜。2003 年，GAO 告诉众议院技术信息政策小组委员会，超过 80% 的已知漏洞归因于 错误配置和缺少补丁。今天，我们有像 SCAP 和 DHS 的 持续诊断和缓解 (CDM) 计划 这样的工具，这些工具使机构能够持续识别安全风险。这些风险可以被优先排序，以便工作人员可以首先缓解最大的问题。因此，我们可以赞扬政府做对了。
回到 GCN 的论点，我们现在已经背负了 Drupal 的故事以及关于开源安全性的愚蠢说法。这使我们可以用像 Heartbleed 和 Shellshock 这样的臭名昭著的漏洞来抹黑整个问题，给人留下他们称之为“灾难之年”的烂摊子的印象。
“灾难之年”这个短语的历史很有趣。它实际上是指约翰·德莱顿 1667 年的诗歌“奇迹之年”，该诗歌讲述了 1666 年伦敦大火。德莱顿说，尽管遭受了所有苦难，但 1666 年是“奇迹之年”，因为火灾可能要糟糕得多。
2014 年的开源也是如此。我们可以看到开源社区在应对这些漏洞方面是多么有效，而又没有削弱缺陷本身的严重性。当然，将来还会有更多的漏洞：无论训练多么有素，无论审查多么仔细，我们的软件都会存在错误。重要的是，有报酬的开源开发人员以及志愿者迅速开发了补丁，并且数百万人能够在几个小时内解决问题。这是一个奇迹。
想象一下像 Heartbleed 这样的缺陷隐藏在专有软件中。它会被发现吗？它会被快速修补吗？我们不知道，因为唯一可以识别和修复问题的人是编写该软件的公司雇用的。他们可能很聪明，他们可能训练有素，技术精湛，并且只使用最好的软件开发最佳实践，但他们仍然无法聚集起高效运行的开源社区所能调动的眼球数量。我将提交 VMWare 对 Shellshock 的回应 作为证据。
GCN 以软件重用的风险结束了它的狂热梦想，将潜伏的危险归因于 90% 的软件是组装的而不是编写的事实。让我们假设 GCN 并不是建议每个人都应该从头开始编写东西，因为那更危险。如果重点是依赖他人很危险，那实际上是真的。您需要知道经过测试、经过良好审查并且可以信任能够快速响应问题的软件。有时那是商业供应商，有时那是蓬勃发展的社区。无论哪种方式，您都希望在开始从 Internet 下载软件之前进行一些尽职调查。
结局皆大欢喜，因为 GCN 采用了错综复杂的论点并得出了正确的结论。NIST 关于软件开发的 SP 800-160 指南花了很多时间讨论如何安全地开发和管理软件。其中包括 121 页关于信任、流程和持续改进的内容，但没有提及开源。
非常感谢 David Egts 和 Shawn Wells，他们都为本文做出了贡献。
最初发布在 Gunnar 的博客“A Technology Job is No Excuse”上，标题为 Annus Mirabilis。通过 Creative Commons 重新发布。
2 条评论