混沌模式下的研发安全解决之道

老规矩，先点开音乐（这是Iris展演的时候，趁机蹭看的一个舞蹈表演，当时听着感觉回到了童年，很有意思），再看看文章的大纲，若感兴趣再继续往下看吧~

这可能是《深耕研发安全》系列的最后一篇文章了，主要原因是AI能力的发展及应用，若仍执着于该方向继续写下去，难免与当下技术发展趋势有所脱节。不过好在经过了近一年的学习、研究和实践，在AI时代下的SDL也有了一些进展，后续将持续在软件安全领域输出AI SDL系列文章。在此之前，还是快速地回顾一下本系列：

数字化转型下的研发安全痛点

从安全视角，看研发安全

基于研发过程的漏洞治理及经验

DevSecOps实施关键：研发安全团队

DevSecOps实施关键：研发安全流程

DevSecOps实施关键：研发安全规范

DevSecOps实施关键：研发安全工具

01 回顾混沌模式

————————

前序内容提到研发混沌模式，即：在同一家公司中，因业务形态或成熟度的差异，可能共存多种研发模式，比如当前被60%-80%的软件开发团队作为首选的敏捷模式，以及传统的瀑布模式，还有DevOps、当下的AI Native开发，同时也存在支撑这些模式运行的不同研发基础设施，如GitLab、SVN、Jenkins、AF等。

面对这种复杂的情况，安全团队通常应该采取“抓大放小”的策略，针对主流开发模式及基础设施进行研发安全自动化检测设计、实施、运营。但如果这些研发模式在产品线上分布相对均衡，又该怎么办？

所以需要探索出一种新的建设方案，引入“自助式”的理念，安全团队专注提供各类安全检测能力和制定全链路闭环流程，让各产品线自主接入安全检测能力或使用同一个系统来开展安全研发相关活动。这个方法，其实也符合常规的安全建设或治理思路，理由如下：

• 自动化：提供统一的代码扫描触发机制（前提是公司所有代码仓库都统一管理），对接公司内部的GitLab进行自动化扫描及扫描结果通知、推送，再也无需开发人员登录SAST、SCA、IAST等工具手工创建项目进行扫描；正如多数互联网企业实践的那样，私有化部署的GitLab平台具备完善的CI/CD能力，能够很好地支撑这类DevOps流程的对接工作，大幅提升研发效率
• 自主化：针对不能无缝融入研发流程的安全检测方法，如DAST、CAST（客户端安全测试）、MAST（移动客户端安全测试）等，为产品线提供安全检测工具；亦可提供安全检测工具的API供产品线调用，以嵌入其独立的研发流程触发检测，产品线无需再为安全提测而等待；
• 平台化：待研发安全建设成熟，即各类AST工具与流程均已建立后，就可以考虑开展效能提升工作（同时让安全与产品线受益），此时就需要有一个集中式的平台以支持所有安全检测、漏洞修复和管理工作，这也是研发安全团队进入下一阶段的重要工作和业绩。

由此，便诞生了：自助式研发安全平台，类似于ASPM一样的系统。

02 自助式的诞生

————————

所谓“自助”，即产线可根据自身研发流程，自主集成、调用或直接登录平台使用这些安全检测工具，旨在复杂的企业研发环境中顺利推行统一的研发安全标准。

为了实现更好的“自助”效果，让各产品线在安全提测时更加便捷，平台除了安全能力供给外，还需要提前打通一些系统，比如：

• 项目管理：对接项目管理系统，将所有的研发项目信息都同步到平台上，在产品线安全提测时，可以快速关联到项目，避免提交人因不了解项目信息、填错项目而导致后续统计出错。另外平台还需要有添加新项目的能力，以应对不在项目管理系统上的场景，比如有的是内部技术预研、测试项目等；
• 代码仓库：对接公司的代码管理系统如gitlab，能够在开发提交代码的同时候感知，从而触发SAST、SCA等代码层面的安全检查活动，卡住代码这道口并持续对扫描结果进行运营，亦能够在一定程度上解决已经上线的产品再次迭代时绕过安全流程、不进行安全提测的情况；
• 安全工具：通过接口串联代码卫士、开源卫士、Nessus 等主流安全扫描工具，实现对项目进行测试和复测，产品线亦可在没有提测项目时使用这些工具进行自测，不过需要对用户权限、使用频率、扫描目标等进行检验或限制，避免被滥用；
• 其他研发基础设施：如Jenkins、Artifactory、发布系统、PSIRT平台及开源软件成分平台等研发业务流程工具，可以实现安全能力与 DevOps 流程的无缝融合，为产品全生命周期安全提供了统一的管控、自动化与运营支撑底座。

（自助式研发安全平台架构图）

自助式研发安全平台是贯穿软件全生命周期的一体化安全管控中枢，它以项目与代码资产为基础，通过自动化与自助式的 SAST/SCA/IAST/DAST/CAST 及合规检测工具矩阵，实现对代码、依赖、运行态及应用合规的多维度安全测试覆盖；同时串联提测任务、特批工单、流程审核等标准化管理流程，联动漏洞预警与 SRC 响应机制，形成从发现到闭环的漏洞管理体系，并通过数据分析、风险排名与指标大屏实现研发安全运营的可视化与量化管理。

03 安全工具集成

————————

3.1.插拔式的设计

安全工具是研发安全平台的核心设计模块之一，下文将重点介绍其对接设计理念。从对接研发安全平台的成熟度来说，主要分为三类：

• 未联动：针对不能或不太方便直接接入流水线、自动触发扫描的安全检测工具，在平台上做得比较“粗”，提供跳转链接到安全工具的页面，有的可能还需要下载一个信息收集的程序到测试环境运行，然后手工上传检测结果进行识别和分析。这类纯手工的场景，是最不愿意看到但又有点不可避免的；
• 已联动：登录到平台上进行自助式的扫描，这时候就不需要跳到其他工具了，产品线直接填写基础的扫描信息如测试环境的地址/域名/二进制包，然后在平台上就能够到工具上抓取结果并展示，产品线不需要跳转到安全工具上做操作，但需要手工触发；
• 自动化：产品线不需要去关心是否已经扫描、不需要登录其他安全工具，正常去做开发和安全提测，其他交由安全团队和devops团队实现。这类主要是针对代码层面的安全扫描，通过githook等方式触发创建安全扫描任务，在正式的安全提测前就通过邮件、IM等方式提醒及推动对应开发修复漏洞，在安全提测时做最终的检查，这是最符合敏捷和devops的方式。

3.2.工具阈值设计

当所有的安全工具都被引入后，最重要的问题就是对于检测结果的要求，即涉及每一个安全工具检测结果的阈值设计 - - 安全测试通过的条件。这关乎着整体的研发安全效果，比较适宜的做法是对每个工具做深入分析，结合业务需求实战对抗、合规等维度，设置不同的门禁，并且持续动态地调整。以下是一些经验分享：

对于通过单项检测的要求，太紧了行不通，因为漏洞多危害不一定有、误报可能也会有很多，如果一开始就直接把低危、中危全纳入修复范围，产品线肯定都改不完，还会怨声载道；管得太松也不行，漏洞漏出去的就会变多，就会影响整个研发安全体系的效果。

所以对每个工具都需要深入做分析，比如SAST工具的检测结果，前期只需要关注一些高危漏洞（检测规则也是通过优化的）；对于开源组件的话，可能会关注一些超危或者高危的漏洞类型。不过这只是从漏洞带来的危害角度出发，如果客户对扫描器检测结果有明确且严格的要求，那可能连DAST扫出的低危漏洞都需要处理，对应的通过要求也要随之改变。

04 安全提测工单

————————

在研发安全平台上，我认为第二重要的是业务流程，比如贯穿整个研发安全工作的安全提测流程。

4.1.安全提测流程

首先由“发起安全提测”启动整个流程，接着产品线需要完成 DAST/CAST（动态/静态应用安全测试）自检并提交检测链接；随后研发安全平台会获取 SAST/SCA（静态/软件成分分析）的检测结果，并提交安全测试工单对测试结果进行自动校验；校验完成后，平台会发出校验结果通知；若检测未通过，则进入渗透测试、漏洞修复及漏洞创建环节，处理完成后由判断节点检查是否结果达标，若达标则流程结束完成安全提测，若未达标则需返回继续渗透测试和漏洞修复，直至达标为止。

4.2.提测生命周期

具象化后，可以看一个安全提测工单的生命周期来阐述。通常安全测试工单会有6个状态，从‘未提交’到‘已完成’，中间会经历不同的阶段、融入了安全团队和产品线各角色的所有交互过程。

• 未提交（新建）：产品线在研发安全平台新建安全提测工单，填写项目信息、测试范围等基本信息，并关联提交 DAST/CAST 自检链接，研发安全平台同步获取该项目的 SAST/SCA 检测结果，此时工单处于编辑待提交状态；
• 校验中（提交）：产品线正式提交工单后，研发安全平台自动对 DAST/CAST/SAST/SCA 等安全检测结果的有无、与仓库地址对应的数量关系、每项达标性等进行检查，并将结果通过IM和邮件告知产品线的提测人，如果存在不符合项则可以根据提示进行修改，若达标则自动流转至下一环节；
• 待分配（达标后）：校验通过后，系统判断是否为增量测试需求。若不是增量测试，工单进入待分配状态，等待安全测试人员接单；若是增量测试，可直接跳过人工测试环节、直接检查是否有遗留漏洞，若没有就进入已完成状态；
• 测试中（分配后）：安全测试人员接收工单后，对项目进行渗透测试，对发现的漏洞进行验证、定级并创建漏洞记录，工单处于测试执行状态；
• 修复中（遗留漏洞判断）：人工测试结束后，判断是否存在遗留漏洞。若存在遗留漏洞，工单流转至修复中，产品线需对漏洞进行修复，修复完成后重新进入测试环节验证；若不存在遗留漏洞，则直接流转至已完成状态；
• 已完成：所有安全检测项达标、渗透测试通过且无遗留漏洞，工单状态变更为已完成，标志着本次安全提测流程正式结束。

其间还会涉及一些其他的“意外”，比如产品线着急做安全提测上线（全量测试需要人工），平台提供了由产品线BU总确认的插队流程；产品线做完安全测试后着急上线（带着要求修复的漏洞上线），平台提供了由产品线总裁确认的绿色通道流程……与此类似的流程还会有不少，不过随着安全提测工作的开展也都逐一沉淀到平台上来。

05 安全赋能培训

————————

当平台做好之后，就可以联动其他部门做推广、应用了。出于部门绩效和在公司内部产生效果考虑，当时研发安全团队与研发学院联动，在公司内部组织了12场、连续6周的专题分享活动。

培训内容大致分为三类：第一类是平台及相关工具的操作使用；第二种是一些方案的实现，比如联合JAVA专家组一起做的开源组件安全管控方案及实现；第三种从攻击视角来做分享，旨在普及针对产品的攻防知识、提升产品线对安全的兴趣。本次培训主要由团队成员担任主讲人，从选题、制作PPT到最终上台宣讲，对平时只做技术的同学来讲也是不小的挑战，顺带达到了练兵（锻炼大家独当一面的能力）的效果。

06 研发安全运营

————————

研发安全体系搭建完成后，研发安全运营工作就显得尤为重要。在建设前期，我们会以正向指标为导向开展工作，比如安全测试工具的覆盖率、漏洞检出率，通过持续制定目标、对齐目标，能够有效提升研发安全水准。

但是当指标都是95+%，这些指标对我们的帮助就不大了。应当换个角度思考，关注因漏洞引发的安全事件，重视每一个安全事件，然后对安全事件做复盘分析，去优化体系、流程和工具。

更多体系化内容，可以查看：首发！“研发安全运营”架构研究与实践

除了日常运营之外，近年来我还有一个深切感触：CI/CD等研发基础设施，已悄然成为攻击队重点盯防的目标。过去我们常说，域控、K8s 这类基础设施是攻击者的“心头好”，但实际上，GitLab、Factory 等研发侧基础设施同样身处攻击队的瞄准镜之下 - - 它们承载着代码资产与构建链路，一旦失守，影响面远超想象。因此，在日常安全建设中，需将这类研发基础设施纳入重点关注范畴。