第七城市开源奇迹mu

开源软件仍然是软件，并且存在漏洞。 与文件系统错误或内核崩溃不同，它们不会引起痛苦，直到它们发生为止。

上周，GCN的Cyber​​Eye发布的“ 开源呼吁更好的软件设计的攻击 ，”这双曲线宣布2014 可怕的一年为政府开源。 他们的最终建议是让每个人都专注于良好的软件开发实践和自动静态分析。 就目前而言还可以。 不幸的是，这种推理方式在其后留下了许多关于开源和安全性的曲折比喻和误解。 对我来说这就像猫薄荷，所以我们开始吧。

我们以最近在Drupal项目上的不愉快开始。 SQL注入漏洞虽然很严重，但并不罕见。 它实际上是世界上最常见的漏洞 。 使漏洞利用具有新闻价值的原因是，从披露到遭到广泛利用之间的时间非常短：“如果不及时应用补丁，那么Drupal安全团队将制定一个漫长的过程来使网站恢复正常运行。” 基本上，在邪恶的机器人降落到您的服务器上之前，您有七个小时的时间来修复它。

这不是开源问题，而是软件管理问题。

预计将存在漏洞。 WhiteHat安全机构说，有86％的网站 （包括开源网站和专有网站 ）都存在类似Drupal的漏洞。 是的，我们可以希望有更好的开发人员和更好的工程流程，并且静态分析可以帮助您及早发现问题，但是制定适当的计划和政策来快速识别这些问题，验证补救措施并加以应用就显得尤为重要。

在这种情况下，GCN的下一个主张更加愚蠢：“……从本质上讲，开源是向可能危害它的最大范围的坏人开放的。” 这是没有归因的充分原因。 世界一流的安全专家喜欢布鲁斯已经宣布， 很多 时候 ，这是它的脸上假的。 GCN自己在DHS上与Coverity合作进行了测试，证明了开源项目中缺陷密度的测量。 作为一个论点，它是一个精疲力尽的街头艺人，每当提到开放源代码时，就会从其木偶中唤醒并轻敲轻舞。 无论如何，您对开源的感受不会一点儿影响Drupal漏洞。 重要的是响应速度，而不是缺陷的来源。

在这种情况下，值得花一点时间来考虑商业支持的重要性。 开源社区可以做奇妙的事情，而其协作的动力对于解决集体行动问题大有帮助 。 但是，安全漏洞的窍门是，与文件系统错误或内核崩溃不同，它们不会造成麻烦，直到它们发生为止。 这使得项目很难识别和修复问题，除非他们有熟练，警惕的开发人员来寻找问题。 获得这种关注的最好和最便宜的方法是付钱给某人。 那就是您使用商业支持的开源项目时要购买的东西。

商业支持还意味着通过受信任的渠道Swift提供修复程序。 Drupal问题之所以如此棘手，原因之一是漏洞利用程序通过假装自己进行修复来掩盖其足迹。 因此，即使他们没有应用此修复程序，人们也可以登录Drupal，检查漏洞，却一无所获。 非常讨厌的生意。 您可以通过使用受信任的程序包管理工具并仅应用提供商提供的数字签名的修补程序来避免此问题。

安全软件管理实践的概念并不新鲜。 2003年，GAO告诉众议院技术信息政策小组委员会，超过80％的已知漏洞归因于配置错误和补丁缺失 。 如今，我们拥有诸如SCAP和DHS的连续诊断与缓解（CDM）程序之类的工具，这些工具可使机构不断识别安全风险。 可以优先考虑这些风险，因此员工可以首先缓解最大的问题。 因此，我们可以称赞政府做正确的事。

回到GCN的论点，我们现在充满了Drupal的故事，这个关于开源安全性的愚蠢说法。 这使我们可以通过臭名昭著的漏洞（如Heartbleed和Shellshock）来解决整个问题，给人以“他们的年鉴”（Annus Horribilis）很大的印象。

短语“ Annus Horribilis”的历史很有趣。 它实际上是对约翰·德莱顿（John Dryden）1667年的诗《 安娜·米拉比利斯 （ Annus Mirabilis ）》的提法，该诗讲述的是1666年的伦敦大火。德莱顿说，对于所有苦难，1666年都是“奇迹之年”，因为大火可能很多很多更差。

2014年的开放源代码也是如此。我们可以看到开放源代码社区在应对这些漏洞方面的有效性，同时又不降低缺陷本身的严重性。 当然，还会有更多的漏洞：无论训练有素，仔细审查如何，我们都将拥有带有错误的软件。 重要的是，有酬劳的开源开发人员以及志愿者Swift开发了补丁程序，成千上万的人能够在几个小时内解决问题。 那是一个奇迹。

想象一下像Heartbleed这样的漏洞隐藏在专有软件中。 会被发现吗？ 会Swift修补吗？ 我们不知道，因为唯一能够识别和解决问题的人员是编写该问题的公司。 他们可以很聪明，可以训练有素，技术娴熟，并且仅使用软件开发的最佳实践中的最佳实践，并且仍然无法满足功能强大的开源社区的要求。 我将提交VMWare对Shellshock的回复作为证据。

GCN以软件重用的危险结束了其发烧的梦想，将潜在危险归因于90％的软件是组装的而不是书面的。 让我们假设GCN并不建议每个人都应该从头开始编写东西，因为这更加危险。 如果关键是依靠他人危险，那是真的。 您想要知道的软件已经过测试，良好的检查，并且可以信任以对问题做出快速响应。 有时这是一个商业供应商，有时是一个繁荣的社区。 无论哪种方式，您都需要先进行一些努力，然后再开始从Internet下载软件。

万事如意，因为GCN纠缠不清，争论不休，得出正确的结论。 NIST的SP 800-160软件开发指南花了大量时间讨论如何安全地开发和管理软件。 其中包括有关信任，流程和持续改进的121页，而没有提到开放源代码。

非常感谢David Egts和Shawn Wells ，他们都为这篇文章做出了贡献。

最初发布在Gunnar的博客上的“技术工作是没有借口”，如Annus Mirabilis 。 通过知识共享重新发布。

翻译自: https://opensource.com/government/14/11/open-source-software-security-vulnerabilities

第七城市开源奇迹mu