糟糕的政策 存在漏洞的软件 研究表明，只有少数企业部署或强制执行了关于使用第三方代码的政策。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应用框架的这些关键警报和更新，让其客户和用户面临攻击的风险。 漏洞将不可避免地进入生产代码，因此企业必须保存所有相关信息，例如源代码、二进制文件、文档、应急响应计划和第三方软件的许可条款，以允许对应用的发布后的维护。企业应该部署应急响应计划来处理关键补丁修复。互联网上的所有应用都需要快速的响应来防止攻击者成功地利用新发现的漏洞。 |
