源代码级的安全性：在 IBM Rational 软件开发生命周期中实现源代码安全分析

文档选项 未显示需要 JavaScript 的文档选项 讨论 英文原文

级别： 初级

Claudia Dent, 高级副总裁，产品销售, Ounce Labs

2008 年 2 月 15 日

了解 Ounce 5 源代码安全性分析如何与 IBM Rational 统一过程（IBM Rational Unified Process，RUP）结合成为 IBM Rational 软件开发生命周期的一部分，由于较早地对软件安全威胁的发现和缓解，提高安全性，并减少成本。

来自 The Rational Edge.

参加 Ounce 5 Webinar！参见本文末尾的链接，了解更详细的内容。

本文讨论了如何在 IBM® Rational® Unified Process（RUP®）和 IBM Rational 软件交付平台中实现 Ounce 5 源代码安全性分析，交付发现、纠正和信息仪表板的封闭循环，最终结果是向软件开发团队提供安全性治理。本文涵盖以下主题：

• 为什么代码分析对软件治理很重要
• 对于每个 RUP 阶段，必须达到的具体的软件安全性的目标和里程碑
• 讨论 Rational 软件交付平台如何与 Ounce 5 源代码分析集成，包括集成到每夜的构建和开发人员的桌面上
• Rational 和 Ounce 的集成如何将软件安全性治理自动化，令团队更有效地达到项目里程碑，满足法规需求，并减少整体风险

早期安全性测试的重要性

软件治理的关键维度是确保组织交付的任意软件系统都是安全的。首先，有法规遵循和数据保密性规则，其中让客户数据不受到不安全的应用程序的影响是不可协商的需求。然而代替等待对完全的应用程序测试安全弱点，组织认识到在软件开发生命周期中尽可能早地确定安全弱点可以减少整体成本。许多研究已经表明在部署之后修复弱点的开支比起在开发应用程序时解决该问题来说成本是一百倍。 ¹

自动的源代码分析被普遍接受为生命周期早期安全性测试的最有效的方法，因为它允许在不需要完全的应用程序的情况下，对任意代码段进行评估。这些技术中最好的是通过在所涉及的精确代码中查明弱点，以及详述有关缺点的类型、关键的程度，以及如何修补它的信息，来提供最有价值的结果。渗透测试也是软件安全性的重要元素，但它的价值在生命周期较晚时（当利用功能接口将它用于完全的应用程序时）才显现。根据最近的 Gartner 报告显示：

组织应该将源代码安全扫描工具作为软件开发生命周期的一部分，从而在项目的早期找到并修复最高数字的安全问题。这将形成更高质量的产品并降低整个的应用程序生命周期成本。 ²

Ounce Labs 的解决方案分析应用程序源代码，从而提供最完全且最精确的应用程序弱点及其相关的优先级的分析，向开发人员提供纠正指导，并让开发团队有效地消除源代码中的弱点。Ounce 5 是有效的“Ready for Rational”合作伙伴，它与 IBM Rational ClearQuest® 和 IBM Rational ClearCase® 变更管理解决方案，及 IBM Rational Application Developer 无缝集成。

Ounce 5 和 RUP

分享这篇文章…… 提交到 Digg 发布到 del.icio.us Slashdot 一下！

IBM Rational 软件帮助组织自动化、集成，并治理通过 Rational 软件交付平台交付的软件和系统的核心业务过程。Rational 的解决方案跨越整个软件和系统交付生命周期，包括架构管理、变更和发布管理、项目组合管理，及质量管理。

Rational 软件开发生命周期产品解决方案是 RUP 方法的工具基础结构和自动化。RUP 是由四个主要阶段组成的灵活的过程框架：初始、精化、构建，和产品化。Ounce 源代码分析主要适用于精化、构建，及产品化阶段。图 1 说明了相对于 RUP ，在哪里进行 Ounce 5 源代码安全分析。

图 1：相对于 RUP，在哪里进行 Ounce 5 安全源代码分析

初始化

常常在软件项目的早期定义过程中，只是关注系统的特性和功能。这留下了重要的非功能问题，例如性能、可用性、平台支持、安全，及要在稍后的生命周期中解决的安全性，导致了项目中许多不必要的波动和延迟。甚至更糟的是，某个软件是在没有真正“完成”的情况下部署的，这为许多项目涉众带来不合规格的体验。RUP 促进在开发项目中，从初始阶段开始，不仅定义功能需求，还定义非功能需求。RUP 还提倡特别注意架构上重要的需求，在项目的更早迭代中确保这些是有效的。由于安全性需求影响了整个的设计和架构，所以应该在初始和精化阶段充分地审查和了解它们。如今，像 Peripheral Component Interconnect（PCI）、Open Web Application Security Project（OWASP）、Federal Information Security Management Act（FISMA），和 Health Insurance Portability and Accountability Act（HIPAA）的标准和法规推动着安全性需求。需要很好地理解这些标准，连同整体的商业目标和风险。

安全性考虑包括一系列问题，例如访问控制和授权、敏感数据的适当处理、数据和存储器访问的适当使用，以及加密方法。一些安全性需求不是非功能的需求，举例来说，所实施的加密的类型。另一方面，许多安全性需求是更面向用例的，并且需要定义主要场景（举例来说，用户通过输入用户名和密码登录系统），以及定义备选路径（举例来说，被批准的用户输入错误的密码）和异常路径（举例来说，黑客试图欺骗登录过程）。在没有将功能的和非功能的需求适当地定义及并入软件中的情况下，编码错误和设计缺陷会表现出关键的信息和操作处于危险。应该像任意其他的需求那样处理安全性需求，同样，用 IBM Rational RequisitePro ® 需求管理解决方案对安全性需求划分优先级、设定范围，并作为整体用例和功能需求的一部分进行管理。

Ounce 5 将安全测试自动化，并且标记与安全性需求相关的问题，包括基本的结论、政策违反，和设计缺陷。如图 2 所示，基本结论包括实现错误，例如缓冲区溢出、竞争条件，及输入/输出验证。政策违反和设计缺陷包括与加密技术、网络通信、访问控制、恶意代码、错误处理和登录等等相关的弱点。

图 2：基本结论、政策违反，和设计缺陷

总之，当项目推出初始阶段时，应该达到以下的安全性里程碑：

• 确定影响在开发软件的关键标准和法规，确保对支持的需求充分地开发并实现为迭代发展
• 相对于商业目标，对高层次安全性需求很好地了解、编制，并划分优先级
• 如果此时知道了所有架构上重要的安全性需求，那么可能导致风险的任意架构上重要的安全性需求都应该在精化阶段标记出优先级

精化

在精化阶段，应用程序的项目计划开始成型。在此，进一步设计需求，并且略述了构建阶段的时间估计。系统的架构得到很好地了解。在此阶段需要尽早关注所有那些在初始阶段被确定为潜在风险的需求，包括那些与安全性有关的。在精化阶段将开发一个运转的，处理主要的技术风险的端到端的系统框架，从而证明架构策略是实际可行的，不只是在理论上成立，因此减少了项目的全面的技术风险。

随着对设计的充分精化，以及对项目计划的展开，可能会识别出新的项目风险。项目计划的重要元素是一组项目迭代，每个迭代有一组目标和退出标准，通常是证明完成一组需求的形式。早期的迭代应该关注于消除在初始和精化阶段确定的风险因素。测试计划和安全性需求的确认必须纳入迭代目标。这些测试计划和相关的测试案例在 ClearQuest TestManager 中进行管理。

Ounce 5 源代码分析是安全性测试的重要元素之一，并且应该在测试计划中列出。Ounce 5 源代码分析在每个迭代中执行，从而证明确定的安全性里程碑，然而更有效的是，将其作为每夜的构建过程的一部分而定期地运行。这确保了定期找到并解决编码错误和设计缺陷，显著地减少了对系统的安全性风险。为了优化 Ounce 5 分析的使用，在精化阶段，可以定制 Ounce 5 引擎，从而突出针对组织或特殊应用程序的政策违反。

定制的一些实例包括：

• 特殊的加密算法的使用。Ounce 5 将测试是否缺少加密方法，以及所使用的任何弱的加密方法。
• 适当的验证常规的使用，也就是，用于确保数据以适当的格式和内容进入系统（且不是脏数据）的具体常规。
• 不恰当的 API 使用，确保不使用可能传播污染的 API。
• 消除硬编码的密码或内嵌的用户名。

在精化阶段，安全性需求的架构完成了。此外，应该计划这些需求的构建，并且应该将所有需求的验证加入将在构建阶段中发生的迭代的标准中。

总之，当项目退出精化阶段时，应该实现以下安全性目标：

• 安全性用例和需求的设计完成了
• 定义了项目计划和构建阶段的迭代
• Ounce 5 安全性测试计划包含于整个的测试策略中，既在迭代里程碑中，又在正在进行的基础之上
• 如果适当的话，Ounce 5 为具体的政策而定制
• 尽可能早地生产“可构建的”系统

构建

构建阶段是实际地构建大部分代码的阶段。构建阶段分为一系列迭代，每个迭代包含确定了的目标，例如特性用例的验证、重要的架构用例的验证，等等。这些里程碑是在精化阶段定义的。就像其他需求和用例一样，必须在经过构建阶段的过程中的迭代里程碑时验证安全性用例。这将确保系统是安全的。

除了验证用例之外，在构建阶段中，团队还希望确保不引入编码错误或“缺陷”。这是通过对源代码的不断测试，以及引入最佳编码实践来实现的。使用 Ounce 5，开发人员可以利用 Ounce 5 开发人员插件不断地验证他们正在开发的软件的安全性。在将代码提交之前，开发人员的代码是尽可能地安全的。构建阶段的目标之一是尽可能早地生成“可构建的”系统。越早构建系统，就越早消除集成风险，并且越早在日常的基础上以整体的方式测试系统。从安全的角度来说，这是至关重要的，因为与独立运行的分离的组件相反，不同组件的交互可能生成不同的安全性弱点。Ounce 5 源代码分析应该成为日常的或每夜的构建过程的一部分，在对源代码的连续变更过程中，不断验证安全性。对 Ounce 5 性能效率进行优化，以便不反面地影响构建次数。如果团队在一天中构建多次，那么 Ounce 分析可以作为该过程的一部分。

以下内容介绍了每夜的构建工作流，以及 Ounce 5 如何与 IBM Rational 解决方案集成：

1. 将源代码作为日常或每夜的构建的一部分进行扫描（参见图 3）：利用 IBM Rational Build Forge®，计划并监控跨开发团队的构建。Build Forge 让发布工程师定义并自动化具体的构建过程。Ounce 5 提供命令行界面，让 Ounce 5 源代码分析自动地作为构建过程的一部分分离出来。一旦分析完成，安全性分析人员就可以使用结果进行筛余。

图 3：将源代码作为日常构建过程的一部分进行扫描

2. 安全分析人员筛选结果并且向开发提交问题（参见图 4）：对于较大的组织来说，安全分析人员通常是主要关注于软件开发生命周期中的安全性问题的专门人才。在较小的开发团队中，团队成员经常有许多头衔，安全分析人员可能是较深入地了解源代码安全问题的高级开发人员。在任一情况下，安全分析人员使用 Ounce 5 Security Analyst 产品来筛选分析的结果。Ounce 5 提供帮助流水化筛余过程的重要功能。举例来说，Vulnerability 矩阵快速地确定证实的弱点，因此可以立即采取行动。安全分析人员使用 Ounce 5 ClearQuest 集成来向开发分派问题。为了效率可以将问题分批，并一次性地分派给 ClearQuest。个别的 ClearQuest 记录被自动生成。

图 4：用 Security Analyst 提交结果

3. 项目经理和团队成员决定优先级（参见图 5）：对于开发团队围绕安全性编码错误和设计缺陷采取适当的行动来说，必须像其他需求、缺陷，或增强的请求一样来优先化冰管理它们。Ounce 5 与 ClearQuest 的集成能让开发人员在他们了解的环境中处理安全性问题。Ounce 5 问题可以直接分派给开发人员立即处理，或者分派给项目经理，然后授权给开发团队的成员。
   
   Ounce 5 ClearQuest 集成将根据默认的字段映射用严重性和优先级等级自动地填充 ClearQuest 字段。举例来说，已证实的弱点和高严重性的 Ounce 5 结论将映射为 ClearQuest 中的高优先级和高严重性。如果这些默认的映射对团队工作流无效的话，组织还可以自定义到 ClearQuest 中具体字段的默认映射。

图 5：Ounce 5 ClearQuest 集成

为了追踪，在 Ounce 5 Security Analyst 中还获取了具体的 ClearQuest 记录数字。一旦在 ClearQuest 中将问题分配给开发人员，就将把该问题就将作为整体项目的一部分进行管理，并且把它当作软件整体健康和进展的量度。

4. 开发人员纠正安全性问题（参见图 6）：当使用结合了 Ounce 5 Developer Plug-in 的 IBM Rational Application Developer IDE 时，开发人员不需要让 IDE 来完成安全性弱点的纠正。开发人员可以通过 ClearQuest 的“To Do”列表充分地观察安全性问题的优先级。一旦开发人员选择了要解决的安全性弱点，他或她就打开 Ounce 5 视图，其中标出了脆弱的代码行。此外，还有描述了代码如何脆弱的纠正指南，以及带有好坏代码实例的最佳实践推荐。一旦开发人员修复了问题，开发人员就可以选择执行本地扫描，从而验证修正情况，并且查看其它可能已经引入的问题。当开发人员通过纠正过程之后，代码就提交到 ClearCase 中，准备每夜的构建，并准备进入再次开始的循环。

图 6：用 Ounce 5 纠正安全性问题
点击放大

将 Ounce 5 源代码分析集成到 Rational Application Developer 中，以及常规地扫描的好处是双重的。当然，第一是向产品中引入安全性破口的风险大大减少。第二是培训那些更不可能引入弱点的开发人员的较长期的好处，因为他们通过接触 Ounce 5 中的纠正指导，更好地学到了编码实践。团队将不可避免地在未来的软件开发项目中引入较少的缺陷。为了鼓励更安全的编码实践，Ounce 5 Developer Plug-In 提供对纠正的免费且无限制的使用。

总之，当项目退出构建阶段时，应该实现以下的安全性目标：

• 充分实现安全性设计和架构
• 在构建阶段的迭代中验证了所有的安全性需求
• 进行中的源代码分析自动确保没有引入由于糟糕的编码实践而产生的弱点
• 应该对开发人员更好地培训安全编码实践

产品化

在产品化阶段，软件系统被移交给用户。在准备这项工作中，执行 beta 测试，用户本身有机会验证系统是否按约定执行，以及功能是否完全。在完全部署之前，应该尽可能多地仿真产品环境，并且执行最终的验收测试。

当然，验收测试的关键维度是安全性测试。为了在产品环境中找到任意的安全性弱点，在此应该执行渗透测试（例如 IBM Watchfire® AppScan）。Ounce 5 源代码分析是对渗透测试的补充，因为 Ounce 5 可以将弱点精确到精确的代码行，然而渗透测试只是通过攻击表面来发现弱点。对于特殊的应用程序来说，安全性审计和验收测试的严格程度依赖于应用什么法规（举例来说，PCI）和标准。Ounce 5 提供 SmartAudit 报告（参见图 7）来支持法规遵循的工作。SmartAudit 报告提供应用程序的“成绩单”，并且覆盖全部的设计问题和编码缺陷。

图 7：Ounce 5 SmartAudit 支持对法规和标准的遵循

当然，一旦系统处于执行中，工作就结束不了了。用户请求新的功能，发现质量问题，必须执行基本的维护。在这些发布循环中，将安全性弱点作为每夜构建的一部分，且在主要的迭代里程碑处不断地测试是必不可少的。

许多企业在产品化阶段有许多应用程序。许多这些应用程序都是几年前，在应用程序和数据安全性威胁没这么巨大之前开发的。组织需要追溯回去，并且对这些应用程序进行风险的评估。因为应该很好地投入安全性资源，所以对于组织来说，用相关的量度度量风险从而优先化是重要的（在此纠正工作是最紧急的）。Ounce 5 提供丰富的项目组合管理功能（参见图 8）来一贯且经常地管理您的应用程序项目组合。

图 8：Ounce 5 项目组合管理

总之，在产品化阶段，应该完成以下的安全性里程碑：

• 在部署之前完成最终的验收测试
• 准备正在进行的增强和维护
• 将应用程序风险作为已部署应用程序的较大项目组合的一部分进行管理

结束语

随着由于攻击的增加和相应的法规，对软件安全性的不断关注，软件开发团队中的每个人都负担软件安全的某部分职责。当利用 Rational Software Delivery Platform 在 RUP 中实现 Ounce 5 源代码分析时，过程框架和自动化简化并阐明了每个团队成员在确保软件安全性中的角色。从初始阶段一直到产品化阶段，有需要满足的清楚的里程碑。最终结果是双重的 —— 根据定义的安全性标准交付的软件及由于避免了在执行中修复软件的巨大成本而减少的成本。

表 1 概述了 RUP 的每个阶段、关键的软件安全性里程碑，及该特定阶段中所需的自动化的主要工具。

注释

¹ B. Boehm 和 V. Basili，“Software Defect Reduction Top 10 List”。IEEE Computer，2001 年 1 月。

²“Implement Source Code Security Scanning Tools to Improve Application Security”，Amrit Williams、Gartner，2006 年 4 月 4 日。

参考资料

• 您可以参阅本文在 develperWorks 全球网站上的 英文原文。
  
  
• 您可以参阅 Rational Edge 电子月刊中文版 的其他文章。
  
  
• 参加 Webinar
  
  源代码的安全：在 IBM Rational 软件开发生命周期中实现源代码分析
  
  日期：2008 年 2 月 13 日
  时间：12:00pm - 1:00pm（GMT-05:00）东部标准时间（美国/纽约）
  主办方：全球 Rational 社区（Global Rational Community，GRC）
  
  自动的源代码分析被普遍接受为生命周期早期安全性测试的最有效的方法，因为它允许在不需要完全的应用程序的情况下，对任意代码段进行评估。
  
  了解 Ounce 5 源代码分析如何在 IBM Rational Software Delivery 平台的每个阶段实现，交付发现、纠正，和信息仪表板的封闭循环，最终的结果是为软件开发团队提供安全性治理。
  
  在这里注册 webinar。
  
  

• 参与论坛讨论。
  
  
• 现在开办了一个特别为 Rational Edge 的文章创办的 新论坛，现在您就可以分享您对本文或本期杂志或以前杂志中的其他文章的想法。阅读世界各地您的同行们所说的内容，生成您自己的讨论，或者加入正在进行的讨论。单击 这里 开始。
  
  
• 全球 Rational 用户组社区

关于作者

		Claudia Dent 是 MA Waltham 的一个安全解决方案公司，Ounce Labs，Inc. 的产品销售高级副总裁。她之前是 IBM Rational 部门，产品管理的副主管，她在高技术行业有二十多年的经验。在 Rational 的十年间，她担任过许多领导职位，包括副主管、Rational Suites Business Unit and Director，产品销售，Change Management Business Unit。1982 年 Claudia 在罗德岛大学获得电子工程学士学位。

对本文的评价

太差！ (1) 需提高 (2) 一般；尚可 (3) 好文章 (4) 真棒！(5) 将您的建议发给我们或者通过参加讨论与其他人分享您的想法.

回页首