Heartbleed事故后：软件政策何去何从？

通过重写开源和第三方组件开发使用的脚本来降低企业的风险。

首席信息安全官（CISO）的工作正受到密切关注，面对持续的挑战，他们必须最大限度地利用安全举措来确保企业资产得到充分保护，其工作的重点在于严格控制用户对关键数据和资源的访问。但对于管理这些数据（包括加密、身份验证和权限检查使用的代码）访问的软件，却很少得到这种相应水平的关注。

面对资源限制，企业越来越多地使用开源库和第三方组件来开发复杂的应用。为什么重写已经存在的功能呢？因为很少有企业会像检查内部创建的软件一样严格检查这些代码。

由已经离职的老员工维护的应用和数据库，以及通过合并和收购获取的软件系统，都会带来安全隐患。有些IT团队可能会假定这些代码是安全的，因为别人已经完成了检查缺陷和漏洞的工作。而OpenSSL加密软件库中的Heartbleed漏洞让我们明白，单纯地依赖别人来正确部署和提供安全性可能让企业和客户数据处于风险之中。

对于使用开源和第三方软件涉及的风险，安全管理人员该发挥怎样的作用呢？根据《高管的观点：(ISC)2全球信息安全工作力CXO报告》（The View From the Top: (ISC)2 Global Information Security Work-force CXO Report）显示，在2013年接受采访的1634名安全高管列出的威胁问题中，应用漏洞名列榜首，同时它也是最少受关注的问题。只有7%的受访者花了很多时间在软件安全上。

和企业移动和BYOD要求一样，软件安全政策合规低得令人沮丧。修订安全政策对决定着企业的赔偿责任和漏洞问题的开发做法会有什么影响？

尽早且经常发布

首席信息安全官面临的困境是：确保软件项目内使用的代码的安全性，同时不会惹怒企业业主以及开发团队，要知道，当预算紧张又需要按时交付应用和更新时，开发团队通常承受着巨大压力。对于不安全的软件，随着威胁逐渐超过其带来的优势，安全人员需要重新评估使用开源软件和第三方组件涉及的风险，并研究如何能最好地管理它们。

开源软件的安全性和质量（这是企业选择使用这些库和组件的两个原因）取决于每个项目的开发人员团队的规模是否足以大得让人能够发现缺陷和漏洞。这即是所谓的林纳斯定律——“足够多的眼睛，就可让所有问题浮现”，该概念根据Linus Torvalds的名字命名，他是Linux的创造者，也是自我修正、社区驱动的软件开发模式的早期支持者。然而，这一理念在现在的威胁环境存在的问题是，发现和利用漏洞的金钱奖励要高于发现、发布和修复开源软件漏洞的奖励。

开源安全举措也有金钱奖励，微软和Facebook赞助的Bug Bounty会对“提交在主要开源软件（例如PHP、Perl和Apache httpd）中发现的漏洞，用以打造更安全的互联网的黑客”进行奖励。

约翰霍普金斯大学的计算机科学教授Matthew Green以及由社区资助的对TrueCrpt磁盘加密工具进行审查工作的另一些人，提出了一个漏洞赏金计划，作为该安全审计工作的一部分。由于不知名的“安全漏洞”，这个开源加密项目在5月份突然被其开发者关闭。

有关美国国家安全局的监视活动的新闻已经导致很多国家（包括中国和其他民族国家）质疑开源项目以及有美国公司故意将漏洞引入到主流安全协议和功能中，以为NSA提供后门程序。RSA（EMC公司的安全分支）、微软和TrueCrpt都是面临审查的公司。

企业开发团队在构建应用时，可以轻松地使用100或以上不同的开源库、框架和工具，以及从互联网复制代码片段。2014年Sonatype开源开发调查发现，90%的典型应用是由开源组件组装，其中很多包含已知的安全漏洞。漏洞组件引入至新应用的问题已经非常严重，这已经出现在OWASP的Web应用漏洞前10名的榜单上了。

糟糕的政策 存在漏洞的软件

研究表明，只有少数企业部署或强制执行了关于使用第三方代码的政策。Sonatype调查发现，在3353名受访者中，75%表示其企业有关于代码和组件使用的政策，但只有68%的受访者（管理人员、架构师和开发人员）遵守这些政策。事实上，77%的受访者表示其企业从未禁止开源组件，即使有31%是开源软件的受害者或者可能遭泄露事故。

显然，负责管理企业软件安全状态的信息安全主管需要重新审视政策、程序，以及管理代码和组件使用的指导方针，以确保其安全程序对开源代码的使用拥有足够的控制。软件开发生命周期应该建立起“将安全做法实际引入到开发过程中”的框架。

根据Cigital公司首席技术官Gary McGraw表示，软件安全组（SSG）应该监管应用安全，SSG属于安全部门，并作为孤岛式安全团队和开发团队之间的中介。SSG的主管应该由董事会来委任，以确保安全代码被视为企业的重要组成部分；它是企业管理流程中的必要费用之一，且等同于其他业务驱动因素。Cigital的成熟模型中构建安全（BSIMM）调查使用了67个真正软件安全举措的数据，这些数据来自于美国银行、EM、富达、汇丰银行、微软、McAfee、Salesforce和Zynga等，该调查发现，具有成熟软件开发操作的企业通常有高级管理人员来管理软件安全，以及SSG来管理开发程序。（在Creative Commons Shared Attribution 3.0 License下可查看BSIMM-V项目的数据和相关文件）

开发团队应该在最开始就参与制定软件安全政策的工作，否则遵守程度会很低。SSG和开发团队领导者需要商定代码和组件选择的具体参数，包括业务用例、支持论坛和文档的质量、可接受许可证，最重要的是代码质量。

让开发人员负责代码和组件选择过程，可以让他们的声誉面临压力，这意味着他们可能需要为代码的未来问题承担责任。这种水平的参与度可以帮助开发团队意识到，速度和花哨的功能并不是最重要的编码因素，还应该考虑开源组件以及与内部代码和软件组成的依存关系。SSG以及开发团队可以根据整体企业风险来确保每个代码选择或组件，以确定所需的安全审查范围。

符合成本效益的代码分析

开发团队需要同时使用静态和动态代码分析。代码的静态分析（常发生在执行应用之前）为代码审查提供了可扩展的能力，可以帮助验证编码政策的合规性。而在正常运行时执行的动态分析可以确保代码得到正确的集成，以及按预期工作等。安全管理人员需要确保为开发人员和运行这些工具的质量保证测试人员提供充分的培训。

虽然分析工具可以完成大部分发现和标记漏洞的工作，但它们并不完美，特别是对于凌乱和复杂的代码库。对于处理或存储着敏感数据的应用，请做好对其关键组件使用手动代码审查的准备。如果代码过于复杂难于理解，应该重新考虑是否该使用或者请求外界的协助。而对于高技能任务，外包则更符合成本效益。有些企业的安全团队缺乏人力和资源，相比之下，采用基于云的扫描来测试漏洞的服务可提供对漏洞的更深入的视图。

应用安全测试服务也已出现，例如惠普的Fortify Software Security Center、Check-marx和Veracode的VAST按需服务，它们分析代码而不需要访问源代码。然而，依赖于第三方服务或咨询顾问意味着需要完全理解测试的东西以及测试情况。例如，OpenSSL有一个FIPS 140-2认证，但FIPS认证只检查加密例程，而Heartbeat协议不是加密模块的组成部分，所以它在FIPS的范围之外。同样重要的是要记住，一次性的认证或审查只会涵盖那个时间点的威胁情况，因此应该执行定期审查。

谷歌的单一代码TRUNK

在获得批准后，代码应该存储在内部资源库，同时，开发者工具应被配置为只能从该资源库审查代码，而不是从互联网。谷歌将其所有项目的源代码保存在单一代码trunk中，其所有开发人员都可以访问这个相同的资源库。这是版本控制的重要方面，这减少了交叉编译注入攻击的风险（在这种攻击中，攻击者感染承载组件的服务器，并使用恶意副本来替换它们）。

企业应该记录所有第三方代码，包括所有依赖关系和资源，将其保存在资料库中，并指派一个人来监控所有相关安全邮件列表，以及获取、测试和分发所有更新和修复。

在2013年，开源框架Ruby on Rails受到多个安全漏洞影响，这些漏洞允许远程代码执行。有些开发团队不知道该流行web应用框架的这些关键警报和更新，让其客户和用户面临攻击的风险。

漏洞将不可避免地进入生产代码，因此企业必须保存所有相关信息，例如源代码、二进制文件、文档、应急响应计划和第三方软件的许可条款，以允许对应用的发布后的维护。企业应该部署应急响应计划来处理关键补丁修复。互联网上的所有应用都需要快速的响应来防止攻击者成功地利用新发现的漏洞。

企业现在依赖于可靠的安全的软件。在应用开发过程中使用开源代码可以带来效率、成本和安全方面的好处，但对这些代码的审查需要更实际的项目时间表，以及一定的预算来支付工具和培训费用。通过维护良好的资源库来自动化政策执行可以让开发人员保持足够的开发灵活性，同时减少应用的复杂性和漏洞。如果企业使用过时的且不能强制执行的软件安全政策，也不奖励那些对代码维持良好控制的开发人员，那么将毋庸置疑地在未来面临更高的风险。