开源软件仍然是软件，漏洞是预料之中的。与文件系统错误或内核崩溃不同，它们在发生之前不会引起任何痛苦。
上周，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 并不是建议每个人都应该从头开始编写东西，因为那样更危险。如果重点是依赖他人是危险的，那实际上是真的。您需要知道经过测试、经过良好审查并且可以信任能够快速响应问题的软件。有时是商业供应商，有时是蓬勃发展的社区。无论哪种方式，在您开始从互联网下载软件之前，您都希望进行一些尽职调查。
一切都很好，因为 GCN 采用了纠缠不清的论点并得出了正确的结论。NIST 关于软件开发的 SP 800-160 指南花费了大量时间讨论如何安全地开发和管理软件。其中包括 121 页关于信任、流程和持续改进的内容，并且没有提及开源。
非常感谢 David Egts 和 Shawn Wells，他们都为本文做出了贡献。
最初发布在 Gunnar 的博客 A Technology Job is No Excuse 上，标题为 Annus Mirabilis。通过 Creative Commons 重新发布。
2 条评论