最近与朋友聊起SDL和DevSecOps的建设和落地，觉得可以将我理解的SDL体系建设来整理下，分享给大家，一家之言，欢迎大家与我讨论！
上次写了《蓝军建设的一些不成熟的思考》，当时除了带领蓝军建设外，还有一个重要的工作是应用安全建设，对于应用安全建设，当时按工作分为了三大部分-主动发现、被动防御、安全运营。
对于这三部分也写了《应用安全体系建设之路》，对三部分进行了简单的建设。里面简单介绍了SDL和DevSecOps的异同。最近重心放在了SDL上面，对SDL又有了新的理解，在这里和大家分享下我所理解的SDL建设，也就是研发安全的建设，相比之前有了更深入的理解。
研发安全，顾名思义就是怎样让研发的产品更加安全，这个理念最早由微软提出，过程涉及到了需求-设计-编码-测试-发布等阶段，每个阶段制定了不同的安全活动。
二、研发安全开展必要性
研发安全现在越来越被公司所采纳，一方面研发安全可以降低安全问题的修复成本：在传统的安全防护中，很多依赖防火墙、入侵检测来实现，都是在软件交付后安全防护，都是属于被动式防御手段，这种手段优势是可以快速部署，但同时缺点是安全介入较晚，产品已经成型了，后续发现问题后修复成本比较大，据美国国家标准与技术研究所统计，发布后的修复成本是产品设计阶段修复成本的30倍。
另一方面是“磨刀不误砍柴工”，这个咋理解呢？很多研发都将产品功能实现放在第一位而忽略了安全的内容，但是一旦上线或者过程中被管理机构指出存在风险，产品可能就存在延期上线或者下线的风险，现在国家、国际社会对于安全的重视程度越来越高，现在产品被召回或者下架的案例也是频繁出现的。研发安全是将安全贯穿到产品研发的每个阶段，在每个阶段都考虑到安全，后续产品也会少很多麻烦。
三、研发安全开展的特殊性
微软SDL流程如下，这个也是大多数企业采用的流程框架：
对于每个阶段都包含强制性的检查和审批，以确保所有安全和隐私要求以及最佳做法得到妥善解决。这两个支持安全活动（培训和响应）分别在核心阶段之前和之后进行，以确保它们得到正确实现，并且软件在部署后保持安全。
但是在推动开展期间，每个公司都有他独特的研发特点，若是按照微软的SDL活动和方式开展是推动不下去的，很多时候需要针对研发特点对微软的SDL进行改造和适配。可以认为微软提供的是一套框架，一套方法论，具体如何落地实施，是需要进行改造和优化的，例如，互联网公司的敏捷开发模式，若是单纯按照微软SDL进行实施，也许一个产品走完SDL之后，市场已经被瓜分完了。再比如，在传统企业里面，SDL会侵入到研发流程中，会引起研发人员反感，若是一味根据自己的方式推动SDL，可能就会适得其反。如何改造SDL，如何推动SDL的落地，这个很多时候不是站在安全角度考虑，而是应该站在研发团队的角度、站在老板的角度来看。
对于研发安全来说，如上，微软给出了实施框架，如包括培训、要求、设计、实现、验证、发布、响应几个阶段：
-
培训：要求员工参加安全培训，并且分为不同的角色、级别进行。
-
要求：对于每个产品、服务、功能都有明确的安全和隐私的要求，要求的来源是行业要求、法规、最佳做法等
-
设计：对要求进行实现，创建威胁建模、识别风险和潜在威胁，并且提出缓解或者杜绝风险出现的设计方案
-
实现：通过代码开发实现安全要求及设计方案
-
验证：对实现的功能验证是否满足安全要求及设计的内容，对产品进行安全检查
-
发布：提交产品上线，过程中需要必要的安全测试和评审工作
-
响应：作为安全运营部分，通过技术和数据运营检查SDL的效果
这几个步骤很好的说明了研发安全几个阶段的工作内容，但是对于企业来说，这些仅仅是在研发安全成熟或者有了初步规模后才可以完整的推进的。
对于很多企业来说，刚开始应用安全就按照微软的这套流程走是完全不现实的，很多企业刚开始都是先从安全测试做起，严卡产品上线。
大多数公司对于研发安全的模式推动应该几乎都是如此：
严卡产品上线，研发和安全的矛盾就会凸显出来，安全和项目出现争议，然后到沟通协作，考虑如何进行安全左移、在研发阶段就能考虑安全性，解决风险，制定制度、流程、管理，工具建设、责任划分等等，明确之后，推动落地实施。
在微软基础上，增加了制度、流程、工具及组织建设四个方面，构建了研发安全框架如下，个人意见，仅供参考：
前公司的结构是由安全总监、研发总监共同成立领导小组，总经理任组长开展工作。遇到不可调节的时候会进行裁决，遇到安全事件之后也会进行责任划分。
对于工作小组，个人认为可以参照如下组织形式：
安全团队内部成立SDL组，负责SDL整体的规划和管理，负责上层规范、制度、流程制定，指导组织SDL在研发团队的落地实施，形成第一道防线，防止产品存在漏洞上线；蓝军负责检验SDL的效果，并且组成第二道防线，对上线后产品进行例行检查和风险发现，并且采用黑客视角来审视产品；运营分为内部和外部运营：内部运营对WAF、入侵检测的数据进行分析，发现未被SDL和蓝军发现的未知风险，及时进行封锁和风险发现，属于第三道防线；外部运营则利用外界白帽子和外部安全力量对产品进一步发现安全问题，例如现在的SRC和Hackerone等等，也算做第四道防线。
安全团队四道防线，从研发阶段到最终运营阶段。而对于研发团队同样如此：
研发团队内部成立研发安全虚拟小组，承接安全团队SDL组需求及落实规范制度，指导研发团队开展研发安全工作。小组成员包括安全SE/安全BP、团队安全接口人等等。
系统负责人是第一道防线，负责对安全需求、安全设计制定，谁的系统谁是第一负责人；研发人员是第二道防线，落实研发安全需求和安全设计，对代码安全性进行把关；研发安全虚拟小组评审、卡点、抽查等是第三道防线；背后安全团队是第四道防线。
-
海报、易拉宝、宣传标语等宣传手段，经过耳濡目染，潜移默化的使大家意识到安全与自己的关系。 -
安全培训：最常见的提升安全意识的方式，不过在执行安全培训的过程中有几点可以给大家作为参考，培训内容需要针对不同的人，不同的级别来进行的，若是均使用同一个课程，不仅达不到预期的效果，可能还会反噬，认为安全和我无关。安全培训可以按照面向的对象大方向可以分为：通用安全培训（新员工、技术、非技术），主要讲解安全导致的问题及造成的危害、外部管理机构的要求、国家的处罚等等，使大家了解安全的重要性；专项安全测试（研发人员、设计人员、产品经理等等），根据特定的研发场景讲解安全设计、安全编码等内容，以提升技术能力为主；针对管理层，重点讲解安全的重要性，对企业成本的收益、违反后的惩罚法规等。通过分层的培训内容，使所有人统一认识到研发安全工作的意识和分工。 -
数据化运营：这部分主要是通过数据化的方式来展示出研发安全的效果，通过数据化分析的方式，对研发团队各个阶段进行数据情况展示给领导层的虚拟管理组织，通过对领导层展示来说明问题，而无需公开，分析各团队在各个阶段的问题，是优是坏，一目了然。 -
安全活动：可以通过举行内部CTF、研发安全文化活动等等开展，对于内部CTF，在开展期间，对于大家的研发安全意识的提升效果很好，使大家从被动接受转变成主动学习、主动接受。
-
很多企业有自己的知识库或者wiki，可以开辟研发安全专栏，将研发安全遇到的问题通过QA方式展示出来，减轻沟通成本； -
将研发风险统一解决方案进行总结讲解，提供给研发人员进行学习； -
将研发安全统一解决方案组件化，提供给研发人员，提升安全研发效率。
原文始发于微信公众号（YY的黑板报）：我所理解的研发安全
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论