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

很久以前，就想写一篇关于SDL与DevSecOps的文章，但疏于实践一直未能动笔。想写的原因很简单，因为总是听到有人说SDL落后、DevSecOps相关技术更高超。一提到研发安全建设，不分研发模式都在赶时髦一样地说DevSecOps。从我的观察来看，不结合研发模式来做研发安全，都是不成功的。

在数字化浪潮的推动下，一些公司已经完全步入DevOps模式，有的则出现瀑布、敏捷或DevOps并存，且后者是居多的。所以如何在多种研发模式下进行有效的研发安全建设，成为一个必须解决的难题。经过近十年的实践，终于在探索解法上有一点点收获与经验，于是有了“深耕研发安全”这一系列文章。

本文是第五篇，DevSecOps实施的第二个关键准备（2/4）。主要介绍研发安全流程体系，从卡点的选取、安全提测主流程的设计到流程的缺陷补偿，全方位支撑研发安全工作在公司层面的全线开展。

01 研发安全卡点设计

——————————

关于研发安全落地，最强有效的方式是在研发流程中设置检查卡点，产品通过安全测试后才放行。卡点选取一般会在申请域名、申请公网访问权限等IT的流程中，故需要想办法和相关团队建立革命友谊，嵌入安全测试结果检查。

如上图所示的安全卡点，基本上能够管住面向互联网或内网的新系统发版。若是已上线系统的功能新增、改bug等迭代场景，在没有统一发布系统的情况下，很难对其安全质量把关。

此外对于软件/硬件交付客户侧的产品，由于不需要申请公司资源上线提供服务，所以上述流程也就被bypass了。但是按照上述思路，找到产品的管理流程（IPD），想办法把安全卡点设计到合适的节点，于是就有了IPD-Sec：

在IPD的技术评审（TR）流程中，将各项安全测试结果嵌入其中进行检查，最后安全工程师会到产品管理的页面进行检查结果填写，确保在流程中的产品均经过安全测试并达标。但对于未纳入流程管控的产品，收效甚微，有时仅凭产品线的自觉性与责任心。

02 安全流程缺陷补偿

——————————

先解决主要问题，是研发安全建设，乃至做所有事情的主要思想。但也不能对非主流程之外的置之不理，尤其是在安全相关的工作中。如果达不到100分、那至少要平衡资源尽可能做到80分，以降低问题带来的安全风险。

在没有统一发布系统的大前提下，信息系统与产品的增量（功能变更，新增、资源替换等场景）安全测试，基本上是依赖于产品线，这对研发安全工作埋下了极大的安全隐患。于是需要重新审视整个研发环境和流程，换个视角寻找方法，重点在于找“汇聚点”统一检测及治理。比如公司的代码是统管的、都使用内部gitlab，于是可将代码安全扫描作为补偿措施，常态化去做静态代码扫描及推动漏洞修复。

03 安全提测作业流程

——————————

这是研发安全的主流程，是研发团队与研发安全团队联系的纽带。研发安全团队通常会出于规范和流程化安全测试，制定出相应的流程，在公司内部发布并组织培训赋能。

在安全提测作业流程中，为了解决安全人手不够的问题、出于公司内部研发流程不统一、产品形态多种多样、产品安全是产线的主责等多方面考虑，分为产品线自主进行安全测试、提交安全提测工单和安全团队检查及测试三个部分：

产线自检：产品线使用安全团队提供的安全测试工具或能力（静态代码扫描、开源组件安全扫描、交互式安全测试或被动黑盒漏扫或客户端安全扫描），对即将发布的产品进行安全测试，按要求对不同级别漏洞进行确认并修复。自动化程度取决于团队的能力，比如大产线可以将代码层面的安全测试工具（SAST和SCA的安全检测能力接入到自己的流水线）；能力强的安全团队可以在公司层面统一实现自动化代码安全扫描（基于gitlab，在开发提交代码时进行触发，扫描结果推送给对应的开发），也可以自建研发安全平台，将所有的安全测试工具进行整合，提供一个统一的平台给各产线使用。
产线提单：产品线完成安全自测并将必修漏洞完成修复后，可提交安全测试工单。此时需要提供待测产品的仓库、测试环境、账号、变更说明、历史提测工单等基础信息，看似非常多的信息实则可以在研发安全平台上进行统管，积累起来后直接选择就行。提交完成后平台会进行校验，关注仓库地址是否合规、扫描结果是否合规等，若是均符合标准则会按照提测类型选择自动通过，或分配给安全测试工程师进行手工测试。
安全测试：针对全新或大版本迭代的产品，安全测试工程师会进行手工测试。在此之前需要关注各类自检报告，并进行抽检，内容包括自动校验环节结果是否正常、已修复漏洞是否真的修复、已修复漏洞是否引入新的安全风险等。如符合则进行安全测试，重点关注业务逻辑漏洞、数据安全方面的隐患及深入业务场景的漏洞。在测试过程中若发现漏洞或隐患，则提交漏洞工单给提测人并督促进行修复。

04 其他相关流程介绍

——————————

与主流程配套的，还有一些子流程，基本上都来自于：在主流程落地过程中，遇到的问题，从而提出的解法。最常见的有：

安全提测插队流程：对于新产品紧急发版、已上线产品大功能迭代紧急上线等情况，专门设计了安全提测插队流程，发起人需在提交安全测试工单后，提交加急提测申请，由部门负责人和产品安全负责人共同批准后，可立即分配安全测试工程师进行作业。在每个月的安全质量考核中，也会将插队次数（不好的评价指标）进行统计与展示，以督促产品线不能滥用这个特权流程；
安全提测带病上线流程：在日常的安全测试场景中，极少数情况会遇到产品修复漏洞不达标而要求上线发布。因此就诞生了该流程，要求产品线明确修复时间、漏洞危害缓解措施和未修复原因，上报产品管理委员会主任并征求其同意。此时，安全团队也要全力配合，在攻击检测、系统加固方面提供专业建议及采取必要的举措。该流程从设置至今，基本上没有产品线走过，这都归功于公司整体对安全的重视，由此也彰显出高层安全组织的作用。

研发安全流程，简单来说要谨记一条准则：安全不能自己造流程，必须结合公司的研发流程。无论它是否健全，都应该在此基础上设计出研发安全流程。能做自动化固然好，但这并非是安全所能一厢情愿的，因为这与实际的研发基础设施及管控情况息息相关。

长按识别二维码，和我交流