DevSecOps实施关键：研发安全团队
很久以前，就想写一篇关于SDL与DevSecOps的文章，但疏于实践一直未能动笔。想写的原因很简单，因为总是听到有人说SDL落后、DevSecOps相关技术更高超。一提到研发安全建设，不分研发模式都在赶时髦一样地说DevSecOps。从我的观察来看，不结合研发模式来做研发安全，都是不成功的。
在数字化浪潮的推动下，一些公司已经完全步入DevOps模式，有的则出现瀑布、敏捷或DevOps并存，且后者是居多的。所以如何在多种研发模式下进行有效的研发安全建设，成为一个必须解决的难题。经过近十年的实践，终于在探索解法上有一点点收获与经验，于是有了“深耕研发安全”这一系列文章。
本文是第四篇，正式步入DevSecOps实施前的准备阶段。首先是组织架构，既要包括高层的组织，从公司战略层面进行安全工作规划；又得有实际落地安全工作的团队。文中首次提出“研发安全团队”及架构，既是理想中的完备团队，又是做好研发安全工作必备的最小能力集。
（研发安全视角下的组织架构全景图）
01 安全团队全貌
———————
在我们的实践中，主要有四个重要的安全组织，从上到下依次为：
-
**网络安全委员会：**直属董事会管理，是公司网络安全的最高领导与决策机构，对重大的网络安全措施、安全事件处理等进行决策。成员主要是公司高管（包括管理安全的高管，如CEO、CTO等角色）；
-
产品安全团队：其实是网络安全部的下一级团队（因本文内容为研发安全相关，故不单独介绍网络安全部），主要负责公司的产品安全，工作内容包括上线前的SDL与上线后的PSIRT（Product Security Incident Response Team）。在产品安全部下设置了安全体系组、安全测试组、安全工具组和安全运营组，以保障SDL和PSIRT工作的顺利开展；
-
产品安全专员团队：非实体组织，不完全属于产品安全部管理。该组织的出现是为了解决安全人手有限的问题，让每个产品线出专人承接产品线安全工作的职责，负责与产品安全部进行积极对接，在产品线内部开展安全活动，保障产品的安全质量。产品安全部需要对该虚拟组织进行管理、赋能及争取一定的考核权；
-
产品安全事件应急响应小组：非实体、公司级组织，产品安全发起组建（在产品安全团队已设置专岗人员），旨在联和公司法务、公关、产品线、交付等产品售后相关部门，一起处置已发版产品的安全事件，也就是上述提到的PSIRT。
在建组织的过程中，一般是从所在岗位开始，比如最开始有安全运维岗或安全测试岗，随着公司的不断发展可能独立成为安全部门。这时候就需要继续往上发展，建立安全管理委员会之类的高层组织，无论是从拿政策、拉资源，还是工作呈现、汇报，对于网络安全工作的开展都大有裨益。
02 研发安全团队
———————
再回到SDL团队（研发安全团队 = 产品安全 - 产品安全事件应急响应小组 = 安全体系组 + 安全测试组 + 安全工具组 + 安全运营组），这是在资源充足的前提下的完美状态，从做好SDL来说也确实需要这四种角色。经过五年的历程，我们基本实现了这种状态，具体分工和职责如下：
-
安全体系组：负责产品安全体系、流程、规范等建设及运营，同时还承担了开发安全认证、开发安全平台产品、产品安全团队考核与汇报指标之类的工作。这类同学周围都是做技术的，很容易失去信心。记得有次谈话间，该组组长说他也想要学习代码审计（因为那段时间我在抓整个团队的审计能力提升，过于强调了挖洞能力，表扬比较多的也是技术同学），所以我立马做出了调整。从术业有专攻，每个方向上都应该成为专家的角度进行引导。实际上这个组非常重要，甚至比代码审计还被组织所需要，他们做的事是面、甚至体上的事儿，而代码审计仅是点或面；
-
安全测试组：负责安全提测工单的处理，包括提测工单的合规性检查、各项安全自检结果的核查、黑盒安全测试及漏洞修复指导等工作。由于业务形态的关系，涉及到web及各种客户端，所以包括了做web安全和二进制安全的同学，作为产品安全的第二道防线（第一道防线是产品线自检），把控着产品上线前的安全质量。重点会关注工具覆盖不到的漏洞测试，比如数据安全相关漏洞、业务逻辑相关漏洞等；
-
安全工具组：负责安全测试工具的开发、应用推广、规则调优等工作，目前已经有主机漏扫、web漏扫、SCA、SAST、IAST和CAST工具，基本上每1-2个工具由1个同学负责，能力强的同学在第一个工具达到运营状态后会加入新的工具研发，以此持续找到工作中的挑战（因为这些同学一般能力都比较强）。在该组中，有一个重点是规则的调优（降噪和提升检测能力），这关乎着整个团队的一些绩效指标；
-
安全运营组：全名应称之为研发安全运营组，这更是实践之后的感悟与创新。在完成SDL建设后，覆盖率与检测率之类的指标都比较高了，参与建设的同学普遍感觉也比较好，但实际情况却比想象中的差。比如经过安全测试的产品，在SRC多次收到高危漏洞、内部红蓝演习总能通过经过安全测试的互联网系统突破边界防线…故此时应该从非自主发现的漏洞（SRC收到、监管通报等）中汲取教训与经验，对这些漏洞进行复盘、分析，以提升研发安全体系中存在的各类不足。
上述四个团队映射的能力和权责，其实就是做好研发安全的必备要素。不管是单独设置岗位，或是人员复用承担多个职责，都极具参考价值。
长按识别二维码，和我交流
More...
-- 深耕研发安全 --
-- SDL 100问 --
-- 软件供应链对抗探索 --
--------- 实战演习 ---------
--------- 安全运营 ---------
--------- 软件安全 ---------
--------- 企业安全 ---------
-
基于堡垒机的自动化功能实践1****
--------- 渗透测试 ---------
--------- 安全开发 ---------
--------- 个人体验 ---------
