敏捷开发模式下的SDL实践

Posted 2021-04-25 安全阁

DevOps理念旨在将Ops（运维）融入到敏捷开发模式之中，经过多年的探索与磨合，形成了一些企业特色的融合模式，但未形成通用方案。随着2017年DevSecOps理念相继出现，促使Sec（安全）也要融入到敏捷开发模式。当前安全融入传统开发模式的典型理论是安全开发生命周期管控（Security Development Lifecycle,下文简称：SDL）。那么SDL如何在敏捷模式下生根发芽呢？

我们先来回顾下SDL在国内传统开发模式下的实践情况，下面我们列举四个企业SDL的建设案例，说明这些企业建设的重点和存在的问题：

企业甲：偏重“安全需求”管控，梳理关键应用典型业务场景，通过威胁建模及威胁资源库相结合方式，构建安全需求库、安全设计库等一系列资源库。在使用过程中，通过快速索引安全需求，导出安全需求及安全设计方案。But,安全管控流程终止在安全编码阶段，安全测试由不同角色负责，无法与安全设计形成统一的测试用例，并且缺乏测试经验的积累，采用传统的渗透测试或众测进行“双盲”测试。流程不完整，技术措施覆盖度不够，无有效的考量指标；

企业乙：偏重“安全设计”管控，依据行业标准、国际标准以及内部标准，导出安全需求，针对全量安全需求进行详细安全设计。如：业务流程安全设计、系统技术架构安全设计、承载环境安全架构设计及网络安全架构设计。But,无整体管控流程控制，安全需求一次性导出，技术措施不具备灵活性，人员技能不足无法较好地使用安全设计；

企业丙：偏重“安全编码”管控，针对具体威胁场景程撰写安全设计规范、安全编码规范，并根据规范定制安全组件（JAR包，SDK,代码参考等），减少安全人员与开发人员的沟通成本，直接调用安全组件相应接口满足安全规范设计要求。But,无整体管控流程控制，威胁场景及安全组件缺少评价机制和闭环优化机制，导致安全设计“管得了一时管不了一世”；

企业丁：偏重“安全测试”管控，采用业务流程安全分析方法尽量识别出可能存在的威胁，针对识别出的威胁构建安全测试用例，严格把控测试过程并形成大量测试指南及测试工具集。But,无全局管控流程，无安全需求及安全设计技术措施，安全测试发现问题反复出现，消耗大量安全测试成本，治标不治本。

造成以上企业“偏科”的现状可以总结为如下主要原因：

1、应用开发整体安全管控流程复杂，缺少流程自动化平台支撑且与现有流程的不兼容导致很难有效管控；

2、企业缺少安全管控所需的知识库，如：安全威胁库，安全需求库、安全设计库、安全组件库、安全用例库及安全加固知识库等必要的积累，效率和落地性成为阻力；

3、企业缺少专业的安全开发管控专业人才，无法与业务人员、开发人员、运维人员及管理层进行有效沟通，内部协作模式无法形成；

4、企业缺少对安全活动评价及审计能力，导致针对开展的安全活动无法确定实施效果及进行有效改进，最终演变成走形式；

我们还没搞定传统开发模式下的SDL，DevOps理念已经融入到敏捷开发模式中，持续交付与集成部署给SDL实践带来了新的挑战。

那么如何将SDL与敏捷开发模式有效结合呢？

从传统的瀑布开发模式到敏捷开发模式，其实是预设性到适应性的转变，瀑布式开发的特点是：文档驱动，线性开发，开发前期准备时间长，那么安全团队有充分的时间将安全活动提前介入，进行有效管控。而在敏捷式开发中一切都“快”了起来，多角色在持续集成的环境下，基于可靠的工具链，快速的迭代着。那么，SDL只能快起来才能融入敏捷开发模式。开篇提及的四个失败原因其实就是成功的关键要素：

1、流程自动化平台支撑且与现有流程具有良好的兼容性；

2、借助瀑布开发模式下的SDL各阶段成果，作为安全管控过程中的技术措施，如：安全威胁库，安全需求库、安全设计库、安全组件库、安全用例库及安全加固知识库。在需求阶段利用安全威胁库及安全需求库进行场景化的安全需求推导，在设计阶段利用每一类功能场景的安全设计解决方案进行安全需求实施，在开发阶段利用安全组件库推进安全编码规范的落地，在测试阶段利用安全用例库进行安全策略的验证和安全威胁控制点的检查。

3、具备安全开发管控专业人才，与敏捷开发模式中的其他角色进行有效沟通；

4、具有安全活动评价及审计能力，确保开展的安全活动效果及进行有效改进。

除了这些通用的关键要素保证SDL基本运转，更需要针对不同的企业现状，因地制宜的进行特有要素的识别和设计，才是真正落地的关键。

场景1：敏捷模式下快速交付

实践：敏捷开发的价值在于及时响应需求变化，高效地组织进行软件开发，快速交付可以工作的软件。那么也就是说一个产品必须在一次两周左右的迭代中完成需求到可视化产品的过程，在这个过程中通常由PO(Product Owner)制定Product Backlog，将Product Backlog拆分成N个Sprint Backlog，那么Product Backlog的导出就是安全需求导出的最佳时机，（这里建议不要先对整体Product Backlog进行安全需求分析，因为在多次迭代之后ProductBacklog会有变动，对当前迭代的Sprint Backlog进行安全需求分析即可），之后在每个迭代Sprint backlog和User story导出时利用SDL平台快速推导出本次迭代所需的安全需求及需求对应的安全设计、安全组件和安全测试用例即可。下面的RASIC图是业务需求到安全整体需求导出的角色责任矩阵示例图：

场景2：敏捷模式下不同的开发管控平台

实践：如果企业具有SDL平台，可以快速导出安全设计及安全组件，但大部分企业开发团队都具有自己开发管控平台，如Jira, Redmine, Bugzilla 等工具，本次实践是基于Confluence平台进行安全开发流程管控，平台知识库积累程度较高，以标签化的漏洞基线为核心支持快速安全需求与设计方案的索引，将导出的安全需求与Confluence平台上User story进行融合，做到无缝衔接。

场景3：敏捷模式下持续集成

实践：敏捷模式下都是自动部署和自动测试，安全如何与之契合，此实践中的敏捷开发环境下的持续集成引擎是Jenkins，可以做到通过SVN代码的版本更新情况进行源代码的自动编译、扫描、部署、发布。如果安全活动依旧是人工去实施，那么安全只会游离在开发流程之外。借助DevSecOps工具链，实现安全自动化，减少安全人员参与，避免影响敏捷开发的灵活性。在开发编码阶段利用Jenkins+FortifySCA+JIRA功能联动进行FortifySCA自动化源代码安全扫描及JIRA缺陷问题自动化跟踪，在运行测试阶段利用Jenkins+Jmeter+测试脚本进行API接口的自动化安全测试，利用Jenkins+APPscan进行定时计划的web安全扫描等，通过以上工具链的实践，减少人为参与的工作量，进一步将安全开发与敏捷开发进行融合。

场景4：敏捷模式下安全考量如何开展

实践：非敏捷模式下的安全考量都不是一个简单的话题，本实践的思路是不单独设置考量环节，通过后置的安全活动进行间接考量。例如：安全需求提出的全面性和合理性考量，会在安全需求评审会中进行考量。需要引入经验丰富的内部或外部安全专家和开发专家，能不断以变化和最新的威胁角度审视安全需求是成功的关键。

无论是安全开发管控能力建设还是其他安全能力建设，具有一定的能力成熟度是前提，但最难的还是能否在企业进行有效落地，相信在我们成功项目案例经验面前都可以迎刃而解。

分享是创新的第一步！