首发！“ 研发安全运营 ” 架构研究与实践
2024-11-18 06:6:0 Author: mp.weixin.qq.com(查看原文) 阅读量:0 收藏

摘要 随着网络安全建设快速发展的进程，软件自身安全性也倍受关注，安全融入软件研发过程并持续左移或右移，已成为行业中的普遍做法。无论是微软提出的软件安全开发生命周期（Security Development Lifecycle，SDL)，还是DevSecOps的推行应用，企业已经或多或少地将安全活动融入软件研发生命周期各阶段。然而研发安全效果并不是很理想，通常会遇到：经过安全测试上线的产品，仍被外部发现0day漏洞等问题。

通过长期实践并剖析研发安全体系存在的问题，本文在业内首次提出“研发安全运营”专业术语，指在成熟的研发体系基础上，一切围绕软件安全质量提升的工作。与该术语最接近的已有技术方案是：信通院的《研发运营安全白皮书（2020年）》，其按照研发阶段来介绍如何做好研发安全，强调安全左移搭建安全体系降低安全问题解决成本。但本文与软件研发模式、阶段无关，是在完成研发安全建设后，通过运营的方式提升安全效果的一种方法，类似于企业安全运营的概念，也属于安全运营的一个子范畴。

关键词 SDL；DevSecOps；软件研发安全；研发安全运营；漏洞复盘
1 研发安全体系存在的问题    
      ——————————   
依托于业界研发安全方法论或模型开展的正向建设，如：产品在发布前都经过安全测试（研发流程中设置卡点）、安全测试过程中使用的工具都具备丰富的漏洞检测规则、在安全测试工具的基础上进行人工渗透测试、各类安全测试发现的漏洞都修复等，看似非常严密和严格的安全检测体系，实际从结果来看仍旧有遗漏。
这可能是研发安全体系与流程存在问题，也可能是安全测试工具能力不足，还可能是执行安全活动不到位，总之，诸多因素有待进一步发掘和探索。

1.1 未说明重点建设活动  

Microsoft SDL主要由7个部分组成，如图1所示，包括5个核心阶段（需求、设计、实现、验证和发布）和2个支持性安全活动（培训和响应）。  

图1 安全开发活动流程图

然而在企业软件建设过程中，由于安全预算有限、安全人员人数限制等因素，不可能完全按照微软倡导的软件安全开发活动进行实施。在响应阶段，主张对安全事件进行应急响应，缺少“安全运营”的概念及实施方法，最终的软件安全质量也会大打折扣。  

1.2漏洞收敛上限很明显 

SDL是一个体系化工程，能够全线提升软件的安全质量。但在真实场景中，缺少实战对抗的攻防视角，因此难以招架外部白帽子奇巧的挖洞思路和真实攻击队的攻击手法。

1.3建设完成后不知方向 

建设好研发安全组织、流程和规范后，按照正常逻辑应该进行常态化运维，但运维的目标、方法、策略等内容都是缺失的。DevSecOps提出了“持续运营，向左反馈”的理念，但尚未看到相关落地实践或案例，究其原因，还是缺少相关方面的理论架构支撑。
2 研发安全运营概念与架构   
      ——————————   
一切围绕软件安全质量提升的工作，都属于研发安全运营，内容涵盖组织、规范、流程、工具及服务的优化与提升。研发安全运营概念可用图2来说明：    
图2 研发安全运营概念图

2.2正式步入运营的标志 

研发安全建设发展如图3所示。研发安全建设在经历“应急救火、搭建体系”后，建设重点逐步转向运营。正式步入运营的标志可以参照以下特征：
1）专职人员。独立的安全测试技术团队，有研发安全体系建设人员。
2）成熟流程。成熟的软件安全测试流程，完备的漏洞应急响应流程。
3）完备工具。完善的安全测试工具集，安全工具嵌入流程自动扫描。
4）输出能力。对业务线常态化安全测试，对业务持续输出安全能力。
图3 研发安全建设发展图

2.3研发安全运营架构  

研发安全运营架构如图4所示。在此架构中，研发安全运营围绕SDL的安全活动来展开，既要关注研发安全体系和整体流程，又要深入常态化运营的每个安全活动。
以SRC运营、安全众测、红蓝对抗、监管通报等外部发现的产品高危漏洞为触发器，引入复盘模式逐一对软件生命周期（需求-设计-研发-测试）开展的安全活动进行分析，再下沉一层到安全组织、安全规范、安全流程、安全工具及提供的安全服务，找出漏洞没在研发安全体系中发现的原因，制定举措改善并跟进落地。    
图4 研发安全运营架构图
          
3 研发安全运营关键要素    
      ——————————   
研发安全运营人员主要以安全内部团队为主，涉及的成员角色主要分为4类：安全测试工程师、安全工具负责人、安全专项负责人和SRC技术运营负责人。其职责如图5所示：   
图5 研发安全运营人员组织图
          

3.2必要的固定检查动作 

经过多次复盘之后，参与复盘的人员会出现懈怠。没有经过动手操作和思考，复盘会议变得形式化，失去了原有目的（即深入研发安全体系找不足），故需要固化动作以保障高质量：
1）动手测试一遍。不要仅凭经验或偷懒做出判断，要上工具测试一遍，拿结果看事实。
2）分析检测结果。查看结果是否符合预期，分析扫描/检测不出的原因及差距。
将固化动作思路具体到每个安全测试工具，表现为：

1）SAST。回溯最近一次安全提测工单，检查关于代码的安全检测是否扫描成功、扫描结果是否经过分析、检测规则是否覆盖漏洞。

2）SCA。回溯最近一次安全提测工单，检查关于开源组件的检测是否有问题、是否有完整扫描链接、扫描成功与否、是否随意将扫描结果标记为误报。

3）IAST。回溯最近一次安全提测工单，检查是否使用IAST插桩扫描、扫描是否成功、扫描出的漏洞是否被修复。    

4）DAST。回溯最近一次安全提测工单，检查是否使用DAST以及是否合规；Web层面进行登录扫描，判断结果是否能够发现漏洞。

5）人工测试。由于很多是增量测试，漏洞点可能并不在近期的安全提测中，故尽可能往前去追溯；其次是关联到最近的重大专项，该项预期的复盘输出，围绕安全人员测试责任心、技术能力及总结测试经验。

3.3漏洞根因复盘模板 

针对每个高危及以上风险级别的漏洞，用固定复盘模板快速定位问题点，分析漏洞漏出原因及制定补强措施，保证质量的同时提升效率。模板的设计至少需要包括漏洞描述、漏洞回溯、漏洞修复及横向排查，如表1所示：
表1 漏洞根因复盘模板
表格由SRC技术运营人员创建，在完成漏洞相关基础信息填写后（如产品名称、安全专员、漏洞链接、漏洞类型），组织安全专员填写测试环境、代码仓库、漏洞代码路径、修复方案、同类问题排查和跨产品排查结果，各安全测试工具负责人和相关安全测试人员根据漏洞分析未检出原因和提升建议。
4 研发安全运营实践应用   
      ——————————   
在运营过程中，逐渐固化复盘会议的节奏。原则上每个高危漏洞都必须按照既定的格式进行分析，每个高危漏洞完成分析的时间周期在两周之内。复盘前，所有相关人员完成标准表格填写；复盘时，所有人员汇报相应环节的分析情况，并明确问题的解决方案、负责人和时间点；复盘后，发起人输出会议纪要，项目经理负责跟进待办事项形成闭环。    
以对某产品的一次高危漏洞复盘为例，该漏洞为登录后的命令注入，可以执行系统命令。SRC技术负责人创建复盘模板并完成漏洞相关信息的初始化，组织该产品线安全专员、团队内部各安全检测工具负责人、最近一次安全提测工单的安全测试工程师进行分析并填写。
复盘会上，利用模板对该漏洞进行分析后，主要发现了安全检测工具的能力不足：
1）IAST不能检测存在安全函数过滤的场景。在该漏洞中，ping参数存在命令注入，其代码图如图6所示，但由于已经有过滤，导致IAST检测不出来。

图6 ping参数存在命令注入代码图

2）SAST不能检测数据流中断的场景。在该漏洞中，source到sink的数据流中断，导致不能被SAST检测出来。
由此可知，最为常见的Web漏洞在一些特定的实现方式下，不能被工具检出，这也说明了人工代码审计的必要性及关注点。随即，输出一条待办事项：对该产品进行人工审计。

4.2经验总结 

经过长期大量的研发安全运营复盘，发现了很多研发安全体系建设时未能碰到的问题。通过对SDL体系进一步分析，找出共性问题点并解决。以下是总结出的常见问题，供同行从业人员借鉴：
1）产线人员缺少责任心，并不是很关注安全。
产线自检环节可操作空间很大。提供不全的代码仓库进行扫描、对扫描结果故意进行误报标记等，均可能导致漏洞被遗漏到外部。该类情况需要明确职责，若是产线对安全活动执行不到位，对外悬赏所产生的费用就由产线来出，以此加强推进安全活动的落地。（有必要在公司进行明示和广而告之，安全保留索要费用的权力）  
2）研发人员缺乏安全技能，难以准确判断漏洞。
研发人员的思考逻辑和安全技能很不一样，不能看出全部安全问题，这种情况很普遍和典型，故需要针对性的研发安全培训，以提升安全意识和思路。
3）安全工具存在bug，导致看不到漏洞出现遗漏。
最常见的如在SAST检测过程中，当出现多个参数进行拼接时，SAST工具可能只显示其中一个参数源，不能判断其他参数是否存在风险，导致出现漏判等典型场景。
4）安全工具不能覆盖的场景，需其他补偿措施。
在SAST的能力范围内，发现其不能检测读取脚本文件。可以按照产品场景进行分类，开展人工审计，并在平时注重审计思路的积累，不断完善代码审计checklist。值得注意的是，大多数有经验的代码审计人员觉得原理简单，忽略了经验积累。面对不同业务场景，不同实现方法就变得异常隐蔽，也会导致有经验的工程师审计不出漏洞。
5 结束语    
      ——————————   
研发安全体系建设完成后，仍会出现许多产品安全质量问题，急需通过持续不断的运营复盘来改善，即开展反向建设工作，对研发安全体系之外发现的高价值漏洞进行复盘分析，针对暴露出来的个别问题，深入挖掘整个体系中存在的不足与短板，以点带面再到体，实现全方位的研发安全效果提升。
长按识别二维码，和我交流
More...
-- 深耕研发安全 --
-- SDL 100问 --
-- 软件供应链对抗探索 --
--------- 实战演习 ---------
--------- 安全运营 ---------
--------- 软件安全 --------- 
--------- 企业安全 ---------
--------- 渗透测试 ---------
--------- 安全开发 ---------
--------- 个人体验 ---------
          
          
              

文章来源: https://mp.weixin.qq.com/s?__biz=MzI3Njk2OTIzOQ==&mid=2247486331&idx=1&sn=58162601043e4bc4cda09fa7ae31ed64&chksm=eb6c2903dc1ba0155ed9ee7a42f9895d6e302bfb9919c138a47557880f609636d22992fba9de&scene=58&subscene=0#rd
如有侵权请联系:admin#unsafe.sh