实战丨安全研发体系建设实践

欢迎金融科技工作者积极投稿！

各抒己见！

投稿邮箱： 

[e-mail]

                                 ——金融电子化

文 / 中国银联科技事业部总经理 周继恩

      中国银联科技事业部安全攻防团队总监 蔡水捷

近年来，随着互联网信息安全事件的层出不穷，一方面外部环境快速变化，监管日趋严格、新型攻击手段五花八门，另一方面企业内部人员流动大，研发人员安全能力参差不齐，各类型的新系统不断涌现等等情况，急剧增加了应用安全防护的难度。现阶段的安全防御已经不能仅局限在开发末端的黑、白盒测试，更多是要求将安全控制左移，提前发现风险，实现纵深防御。

“上医治未病”，中国银联科技事业部借鉴业界软件安全开发生命周期方面的方法理论，探索并建设符合自身特点的银联安全研发体系（UnionPay Security Development Lifecycle，简称UPSDL），本文着重阐述组织在不同发展阶段不同的安全体系建设策略，以及最新的体系平台化落地方案，希望能给读者带来一些启迪与思考。

现状

安全研发常见的方法论包括：微软SDL、OWASP SAMM（软件保证成熟度模型）、美国国家标准与技术研究院的信息系统开发生命周期安全参考（NIST SP 800-64）。我们在实践运用中发现，这些方法流程过于复杂繁琐，且需要开发人员接受足够多的安全培训，具备较强的安全意识和安全技能，但是“术业有专攻”，我们无法要求所有人员都是半个安全专家。这也是这些安全研发方法“看起来很美”，但无法有效落地的重要因素之一。

建设实践

万事万物都有其发展规律，体系建设也是一样，是一个逐步建立完善的过程，我们以PDCA为指导，依托现有研发过程，先从小点、关键点做起，减少安全侵入性，而后逐步横向扩展，建立适应不同研发模式的安全研发体系（UPSDL），建设过程整体可分为以下3个阶段：

1. 起步阶段：抓出口，重应急

建立单点安全防御阵地，抓出口，消除易见的安全漏洞，建立应急响应机制。这个阶段尚未设置专职安全团队，主要是质量保障人员兼职完成部分安全工作，工作分两方面：

（1） 严格控制产品发布前的安全审核

我们在应用系统版本发布前进行安全管控，引入白盒、黑盒安全扫描工具，以OWASP TOP 10、扫描工具中Critical、High级别漏洞为安全基线，建立流程管控制度，明确扫描报告中哪类问题必须修复，哪类问题可以先发布后修复，所有版本发布生产前，应通过白盒、黑盒扫描，结果符合要求后方可发布。通过工具检测，将发现的问题反馈给开发人员，开发人员只需被动接收安全报告，及时修复安全漏洞。另外采购一些外部安全服务，开展人工的安全测试和代码安全审核，补充安全测试的不足。

（2）建立应急响应机制

外部的攻击不会因为你没有做好准备而放慢脚步，针对信息安全事件处置，我们建立信息系统软硬件缺陷快速协作及处置机制，明确了安全预警通报机制、不同类型漏洞处理时效、各方职责等，确保一旦接到通报，可以有序开展应急工作。

上述两部分内容，重点聚焦在系统发布前安全测试，及发生信息安全事件后如何堵漏，这些工作相对容易“可见”，成果也好衡量。在安全方面有了基础的保障，才会有后续UPSDL“闪转腾挪”的空间。

2. 成长阶段：建体系，做标准

建立UPSDL框架体系，完善各开发阶段输入输出标准。随着业务的发展，越来越多的应用系统暴露在互联网上，攻击面扩大，安全的重要性日益突出，而在起步阶段，安全的工作主要由兼职的质量保障人员完成，其安全意识及专业技能水平不高，已跟不上安全快速发展的趋势，故我们成立了专职的安全团队，除了增强安全测试、应急响应外，还逐步深入开发过程，如参加安全评审、设计安全架构、开发安全组件等，同时以金融合规为切入点，基于法律法规、行业监管等要求，将其转换为技术语言，确保开发人员读懂理解，最后建立需求、设计、编码、测试、应急的完整安全链，明确各阶段的输入输出、不同研发模式下的适配标准。

在本阶段，我们注重培养人员对UPSDL流程的执行意识，主要对重点项目开展全过程的安全管控，以流程执行、人工线下监督审核等方式推动的UPSDL，尚未具备大范围实施的条件。

3. 进化阶段：上平台，定指标

安全体系平台化，制定量化指标，持续优化。在成长阶段，内部形成了大量的安全规范、操作细则、检查清单，在安全技能、人员意识上都有了一定的积累，但在实际开发过程中，一是开发人员需要提交很多安全审核材料，如安全需求文档、安全设计文档、代码静态分析确认报告等，没有辅助的工具用以提高效率，影响开发进程，二是具体文档的编写时，不同人员的交付物质量差距较大，无法有效识别安全风险，形式大于实质。体系的实行效果，即安全能力提升的程度如何，很难从一份份孤立的报告表单中分析得出，安全经验沉淀更无从谈起。

通过调研分析，业界的SDL平台与我们实际需求有较大差距，不能较好的支撑体系运行，故经过近一年的建设，我们于2019年自研完成安全研发平台，将安全平台化、可量化、可视化、可扩展，通过实践使用，不断优化改进。平台设计思路如下：

（1）以应用系统为基本单位，业务需求为驱动。应用系统的安全是动态的，不同的业务功能可能产生不同的安全风险，所以我们在受理业务需求时，平台根据需求涉及的应用系统，自动通知需求、开发、安全人员，分配相应的任务，确保所有业务需求不被遗漏。

（2）通过业务场景互动模式，实现轻量化威胁建模。安全的技术与合规要求众多，且都是安全专业术语或原则性描述，研发人员很难理解，容易产生歧义，增加沟通成本。为解决此问题，我们设计从业务场景角度出发，将业务功能与安全要求、威胁、对策、安全测试案例建立对应关系，需求、开发人员只需结合实际需求情况，通过问卷形式的完成相关问题的反馈，平台会自动生成安全要求、可能的威胁及建议对策，及安全测试案例，极大地简化安全分析过程，由于威胁、安全方案、测试案例建立了对应关系，也保证了安全的连续性，可验证性，避免产生各顾各的安全孤岛。

（3）聚合自动化检测结果，集成研发流水线。我们将各单点的检测工具结果进行汇聚，包括白盒、灰盒、黑盒检测、第三方组件检测，以应用系统为维度，聚合安全检测数据，从多个维度反映系统的安全状况，形成安全检测结果全景图，便于安全缺陷前后关联追溯，有助于安全人员进一步的开展综合分析。此外，将不同阶段的检测结果与研发流水线结合，比如白盒、三方组件检测结果作为判定代码入库条件之一，灰盒、黑盒与版本发布集成等，提升了研发流程与安全管控的衔接力度。

（4）建立核心资源池，沉淀安全经验。安全经验是一个组织的宝贵财产，通过平台建立安全需求、安全设计、安全案例、威胁建模资源池，将这些资产固化。一方面，安全人员定期组织骨干专家，针对某些安全要求，讨论设计出可行的安全方案作为部门的公共方案，所有系统都可以参考使用，另一方面，开发人员在执行安全活动时，本系统的安全方案经过安全专家审核后会自动进入资源池，作为本系统的个性化经验资产，后来的开发人员处理同样的系统时，既有部门的公共方案，也有该系统以往的方案作为参考。针对各系统优秀方案，安全团队组织相关人员评审后，又“反哺”部门的资源池，供其他系统使用，形成良性循环，这便是安全的“传承”。即使新员工首次接手开发工作，也不会因能力经验欠缺而导致过大的安全偏差，逐步将各类人员安全能力意识拉平。

实践效果

平台运行至今，取得了一定效果，举例如下。

（1）安全研发效率得到提升。相较平台化前的线下工作，在分析安全需求、设计安全方案的耗时，平均由4-5个工作日，降低到1-2个工作日，同时大大减少了文档编写工作。前期需要人工执行的扫描工具，通过无缝集成自动触发扫描并完成分析，如第三方组件管理，前期是通过人工专项收集检测，耗时长且不实时，通过平台组件动态分析管理功能，在每次发版时，可在10分钟内完成组件成份分析及生成报告，并自动提醒开发人员在线确认，提前发现组件漏洞，形成资产基线，在组件漏洞应急响应时，可以在1分钟内定位受影响的应用系统，为后续处置争取时间。

（2）安全研发逐步标准化。目前已超过100个应用系统初步建立个性化的安全基线，包括符合本系统特点的安全要求、安全设计方案、安全测试案例，并正随着业务需求的迭代持续自我完善。平台上的优秀安全方案，被各类应用系统引用达200多次，缩小了不同资历研发人员的安全差距，整体提升了应用系统的安全防护能力，也给组织积累了宝贵的知识财富。

（3）引导安全“左移”。在加强现有末端安全测试基础上，通过平台控制，逐步将安全重心引导至需求、设计阶段，回归应用系统安全源头，末端的安全测试用以验证安全方案是否落地实施且有效，从而实现安全闭环。

小结

安全永远在路上，安全研发体系建设的探索与实践是一个不断打磨和演进的过程，其中包含了诸如技术工具融合、方法论运用、人才培养、跨团队协作、DevOps新研发模式等众多挑战，我们积极拥抱变化，相信只有坚定持续精进、敢于创新突破的决心，才能将安全研发体系建设步入新阶段，更好地助力业务发展。

往期精选：

（点击查看精彩内容）

关于仿冒我刊收费的声明

我刊自创刊以来，从未向投稿人收取过任何费用。任何以刊发文章为名向投稿人收取费用的行为，均属于对投稿人的欺诈行为。

我刊官网地址为 www.fcmag.com.cn。

我刊投稿邮箱为 [e-mail]。

对于仿冒我刊网站、网页的违法行为，我社将追究其侵权责任，以维护我社和投稿人的合法权益。仿冒网站、网页举报电话：[phone]

《金融电子化》新媒体部：主任 / 邝源  编辑 / 潘婧 傅甜甜