[论文解读] Secure Scrum: Development of Secure Software with Scrum

Christoph Pohl, Hans‐Joachim Hof|arXiv (Cornell University)|Jul 10, 2015

Software Engineering Techniques and Practices参考文献 17被引用 29

一句话总结

本文提出 Secure Scrum，作为 Scrum 框架的扩展，将安全实践贯穿整个敏捷开发生命周期，同时不改变 Scrum 的核心结构。通过引入 S-Marks 标记安全相关的需求条目，并指导团队进行安全任务的分解与验证，Secure Scrum 使非安全专家能够识别、实施并验证安全控制措施。实地测试显示，漏洞数量显著减少——使用 Secure Scrum 的团队 3 所产生的缺陷远少于使用标准 Scrum 的团队，证明了在几乎无额外负担的情况下，安全结果得到显著改善。

ABSTRACT

Nowadays, the use of agile software development methods like Scrum is common in industry and academia. Considering the current attacking landscape, it is clear that developing secure software should be a main concern in all software development projects. In traditional software projects, security issues require detailed planning in an initial planning phase, typically resulting in a detailed security analysis (e.g., threat and risk analysis), a security architecture, and instructions for security implementation (e.g., specification of key sizes and cryptographic algorithms to use). Agile software development methods like Scrum are known for reducing the initial planning phases (e.g., sprint 0 in Scrum) and for focusing more on producing running code. Scrum is also known for allowing fast adaption of the emerging software to changes of customer wishes. For security, this means that it is likely that there are no detailed security architecture or security implementation instructions from the start of the project. It also means that a lot of design decisions will be made during the runtime of the project. Hence, to address security in Scrum, it is necessary to consider security issues throughout the whole software development process. Secure Scrum is a variation of the Scrum framework with special focus on the development of secure software throughout the whole software development process. It puts emphasis on implementation of security related issues without the need of changing the underlying Scrum process or influencing team dynamics. Secure Scrum allows even non- security experts to spot security issues, to implement security features, and to verify implementations. A field test of Secure Scrum shows that the security level of software developed using Secure Scrum is higher then the security level of software developed using standard Scrum.

研究动机与目标

• 解决标准 Scrum 中缺乏系统性安全集成的问题，即安全常被视为事后补救措施。
• 使非安全专家能够在敏捷迭代中识别、实施并验证安全控制措施。
• 在确保安全贯穿整个开发生命周期的同时，保持 Scrum 的敏捷性与团队自主权。
• 定义并实现“适当的安全水平”——即攻击成本超过潜在收益，避免过度工程化。
• 评估 Secure Scrum 在真实敏捷团队环境中的实用性、可用性与有效性。

提出的方法

• 引入 S-Marks（安全注释）以标记产品待办事项清单和冲刺待办事项清单中的用户故事与任务，突出安全相关关切。
• 指导团队将安全相关用户故事分解为具体、可操作的任务，并附带 S-Marks，确保安全在实现过程中得到落实。
• 采用基于威胁的风险优先级排序模型，根据可利用性与潜在收益评估安全风险，与“适当安全水平”原则保持一致。
• 使用轻量级、与 Scrum 兼容的工具（如彩色卡片表示 S-Marks），以最小化培训与管理开销。
• 采用漏洞计数机制：$sp = \sum cpf(cf)$，其中 $cpf(cf)$ 统计导致漏洞的功能（如 SQL 注入、XSS、CSRF）。
• 通过在受控实地实验中比较使用 Secure Scrum 与标准 Scrum 的团队在漏洞数量与文档质量方面的表现，评估其有效性。

实验结果

研究问题

• RQ1 Secure Scrum 是否能有效将安全实践集成到 Scrum 框架中，同时不破坏团队自主权或敏捷性？
• RQ2 非安全专家在使用 S-Marks 与结构化任务分解时，能在多大程度上识别并实施安全控制措施？
• RQ3 与标准 Scrum 相比，使用 Secure Scrum 是否能显著减少软件漏洞？
• RQ4 Secure Scrum 对团队生产力以及需求与任务跟踪的文档质量有何影响？
• RQ5 在敏捷环境中，能否通过基于威胁的风险评估，实际应用“适当安全水平”原则？

主要发现

• 使用 Secure Scrum 的团队 3 所产生的漏洞显著少于使用标准 Scrum 的团队（团队 1 有 18 个，团队 2 有 12 个）。
• 两个使用标准 Scrum 的团队均存在可利用的缺陷，包括 SQL 注入、XSS、CSRF 及不安全的会话管理。
• S-Marks 的使用使团队 3 成功为全部 14 个用户故事与 8 个任务组标记了安全关切，充分体现了安全问题的高可见性与采纳率。
• 团队 3 通过将相关用户故事与任务分组，减少了碎片化，提升了可追溯性，同时保持了高水平的安全覆盖。
• 评估结果确认，Secure Scrum 易于理解与使用，培训与管理开销极低，且能无缝集成到现有 Scrum 工具链中。
• 尽管在跟踪额外非功能性需求（如安全、性能）时存在轻微的生产力权衡，但安全收益远超成本。