为什么要做SDLC
从业安全很久了，入职一年后，就经常听到SDL，一直在甲方做安全，见过太多关于SDL的“假大空”方面的内容，我最擅长的就是拿出微软的那张图，对照着图，把每个阶段该做什么事，原封不动的读一遍，偶尔发散一下…
先确定一下用词规范吧，SDL很早之前只是：软件开发生命周期(Software Development Life，后来大家慢慢开始重视安全了，强调安全左移了，微软推出了SDL，至此SDL又有了新的含义：软件安全开发周期(Security Development Lifecycle)，毕竟很多公司都还没有开始，我们每次说SDL都会产生歧义，好像后面慢慢使用SDLC来表示带有安全工作的表述：软件开发生命周期(Software Development Life Cycle，SDLC)，本文就不纠结了，统一使用SDLC。
为什么要做SDLC？这是一个灵魂的问题
第一，我们首先要考虑的，双sp也强调，安全战略是要跟着业务战略走的，业务战略是否要求我们要进行SDLC呢？
第二，我们是否具备这样的能力，或者说我们要想做好SDLC，真真正正的把每个过程做好，需要什么样的手段呢？
我眼中的SDLC
SDLC是个“很麻烦的东西”！
首先，需要管理层的支持，自上而下进行，为什么这么说？因为想要做好SDLC，安全是要融入到这个开发生命周期当中的，不仅仅是产品开发完了，我们做一做白盒、黑盒、灰盒，用工具扫一下，看看漏洞就可以交作业了。我们做安全的是需要和各个部门密切沟通，尤其是产品和研发，这就要求我们不仅能听得懂产品、研发、测试、基础架构的同事在说什么，我们说的话也要让产品、研发、测试、基础架构的同事能听懂。
然后，需要有很强的沟通能力，说的比唱的好听，沟通能力怎么提高？说简单也简单，可以站在对方的角度看待问题。那怎么站在对方的角度看待问题呢？和产品沟通，那么我们对于业务的熟悉程度要和产品平分秋色；和研发沟通，我们要能看懂代码，能写代码，懂框架；和测试沟通，要大概知道测试常用的用例、测试轮次；和基础架构沟通，要熟悉数通，linux/windows操作系统和python。
最后，做个总结吧，说沟通能力，说着说着还不就是网络安全的那些基本功：windows/linux操作系统、数通、开发语言（php+python）、数据库、web开发。如果业务战略要求我们要做好SDLC，那么这些将是我们要解决的问题，而不是壁垒。
SDLC落地
准备工作
当决定要开始做SDLC的时候，作为安全，是需要有所准备的。
1.管理层的授权、重视（已经强调很多次了）
2.从安全角度出发，去梳理业务的流程，画业务流程图，这个业务流程图的目的很简单，就是让安全人员去熟悉业务，用这张业务流程图去和产品，和研发沟通
3.从安全角度出发，去梳理网络的拓扑，一般来说，基础架构的网络拓扑图安全不会很适用，大多是针对整个公司的业务画的，上面画一些交换机、路由器，防火墙，能说明整体网络流向就够了，但是对于安全来说，是要分业务进行的，我们要知道，从哪个IP进来的，经过了哪些安全设备，到了哪些台服务器（IP），最后到了哪台数据库（IP）
所以准备工作的交付物就是安全和产品能看懂的业务流程图以及安全和基础架构都能看懂的网络拓扑图。
瀑布模式
先说一说瀑布模式吧，因为SDLC的流程确实是对接瀑布模式的，至于敏捷模式，后面再说。
启动会
兵贵神速，既然要求安全左移，我们就笨鸟先飞，直接到最左的地方。对于瀑布模式，自然就有启动会，可能各个企业的说法不一样，总之就是已经明确目标和计划了，开始分配任务了这样一个会议。
我们在此阶段需要做的就是在启动会之前，先和业务人员（产品经理/项目经理）开个通气会，需要业务人员去识别此次的需求是否需要安全介入，当然业务人员如果无法识别，那就需要安全人员在这个通气会上识别了，这时候，就会体现出业务流程图和网络拓扑图的重要性。
通过业务逻辑的变动：如果只是新增一个页面/菜单的话，就大概了解初步评估；如果是业务变动较大，就需要识别合规、以及用户有没有安全方面的需求。
需求阶段
主要的工作项有三部分。
1.识别客户在安全方面的需求
客户的需求是首位的，有时候可能客户将安全需求传达给业务人员，不是很了解安全技术的业务人员转过头就会忘了，所以在通气会上也可以问问业务人员有没有这方面的需求，比如：需要什么样的认证手段，是用户名密码认证就够了？用户名密码需要什么长度？双因素/多因素等
2.合规方面需求
这个项目本次或以后是否需要合规，比如等保、ISO等，这个可以和领导问一问，如果将来有，是不是我们就要提前准备准备了
3.判断是否要提出安全需求
前面也说了，在通气会后，根据业务变动判别是否有安全需求
如果仅仅是横向复制粘贴了几个的菜单功能，页面这种，并且没有新增对外交互的，那还有什么必要去提出安全需求呢
如果引入了一条新的链路，那就需要整体进行评估与识别了，比如：APP or Web？接入WAF、IDPS、有没有新的边界（公网出入口）、新的数据流调用、日志或审计等
设计阶段
说白了就是安全设计，在上面需求阶段的中，安全需求是由安全方面提出的，当然也由安全出设计了，但是安全需求又不能写的像产品需求说明书那样，产品需求说明书为了让产品和研发看懂，为了开发功能，而安全需求主要是能让安全看懂，从而对安全需求进行安全设计。那么既然安全写安全需求，安全又根据安全需求写安全设计，为什么不把这两步合并起来呢？所以在需求阶段，安全的核心目标还是识别出来安全需求，如果真的安全需求比较多，也不要在这个阶段写那么冗长的文档，大概记录一下，写个临时文档能说明问题就行了，不要花那么多精力，写那么多文档，到最后都没有用。
1.安全设计去分析需求阶段的3点安全工作，我一般会把安全设计分为3个部分：
应用层（如果安全需求是通过代码实现的，比如用户名密码是多少位的、密码怎么加密传输|怎么存储|用什么算法|秘钥怎么管理、验证码、权限、数据库等，就在这里描述）；
基础架构层（如果安全需求是通过网络和操作系统实现的，比如IP白名单、操作系统的配置等，就在这里描述）；
安全层（如果安全需求是通过安全设备或者其他安全手段实现的，比如上waf、抗DDoS、TLS、堡垒机、安全框架等，就在这里描述）
2.对于威胁建模/分析，我又爱又恨
爱，是因为如果做的好的话，比如在这个阶段就已经能分析出99%的攻击面/威胁面，提前做好威胁消减措施，那么威胁建模将成为SDLC中最靓的仔，而且还做了特别漂亮的威胁树作为交付
恨，是因为我确实没这个本事干威胁建模/分析，不管是用工具还是自己根据业务图去想，也不管是主动还是被动去分析，我无法保证产品还没出来威胁都能想出来了
但是威胁建模/分析给了我们一个很重要的思路，就是也要站在攻击者的角度去考虑SDLC的落地，我们要熟悉各种攻击手段，那么防守会事半功倍
所以对于威胁建模/分析，如果有多余的预算可以请行业顾问，听听他们的意见，如果没有，就把重心放在能让这一部分及格的安全设计上吧
开发阶段
对于开发阶段、测试阶段、实施/运营阶段的工作内容，可以灵活分配，没有人规定白盒一定要在开发阶段做，也没有人规定黑盒一定要在测试阶段做，所以要根据业务和企业的真实情况合理安排，我们在实践的时候，更多的是要思考，有什么样的业务痛点来鞭策我们推进SDLC（确定要做吗？），每一个环节究竟要解决的是什么问题（做哪些？），怎么才能落地SDLC（怎么做？）。不要把一堆压根完成不了的东西放在SDLC里，也不要测出一个问题了，自己先慌了，压迫产品、研发赶紧去整改先，看看利用的概率和危害，有没有什么缓解措施，一遇见漏洞立马就是升级，结果导致产品、研发、基础架构有很多难处，立马升级后，业务上又有问题…
1.白盒测试，这个不用多说，我个人接触比较多的还是偏工具扫描，毕竟我也确实没有能力对研发代码一行行进行人工分析，不过白盒工具的规则优化迭代是需要做的
2.危险函数审核：
目标：研发在开发过程不使用危险函数或者是硬编码（密码/秘钥）
做法1：理想情况，将危险函数检测工具集成到idea中，插件会识别危险函数，研发在开发过程中使用了危险函数，idea会像报找不到类或者函数已过时进行一个波浪线error提醒
做法2：研发在提交代码的时候有专门的工具可以检测
做法3：用python写个脚本，扫描源代码关键字
3.中间件管理
提前梳理研发使用到的所有中间件及版本按项目或业务划分进行记录，监测几个像是360漏洞云等网站，如果有漏洞的需要及时更新，该纳入安全需求的就进行规划（这种是个比较好的例子，就是一个安全需求，也不需要设计，需要的就是我们对这个漏洞的了解程度，用waf或者改一改配置进行缓解，后面再升级根除修复）
那么如果验证呢？阿里云上有个这样的规则，因为中间件都是部署在ECS上的，阿里云会定期扫描包名，看包名的版本是否为危险版本或者解压jar包看看里面的包的版本，这也是一种思路吧
4.打包的反编译
这一项工作主要是针对APP加固，或者一些私有化的部署，软件包发出去是要保证一些在线工具也好，开源工具也罢，这些工具是无法反编译我们已经加固好的包
反编译工具好像也是可以集成到idea里的
测试阶段
双sp中提到的安全评估与测试，安全评估是为了验证/测试安全设计或者说安全控制的有效性，所以不要忘了测试阶段再看看自己的设计实现了没。
也要根据企业实际情况，跟测试负责人沟通好，什么时候进行，因为我们要考虑测出漏洞有没有时间修复，还有如果测出漏洞了，最好能去主动了解要修改部分的业务和逻辑，并且和研发一起评估修复方案。
1.黑盒测试不用多说了，看家本领，用几款扫描工具扫一扫，awvs、appscan、xray；服务器漏洞扫一扫；人工再测一测
2.灰盒测试，首推洞态的IAST，被动插桩是门艺术
3.验证安全需求/安全设计的实施情况（或在实施阶段执行该项），比如密码的加密啊，TLS的版本等等，wireshark抓个包看看嘛，像是数据库加密，去库里看一下
实施/运营阶段
1.双sp中提到的安全编排自动化与响应(Security Orchestration Automation and Response, SOAR)是需要我们提前建立的，但不要死板，我们要做的就是明确playbook和runbook（可以没有runbook，但是最好能有playbook），生产环境的运维或安全运维人员可根据playbook进行应急响应（同样需要业务流程图和网络拓扑图，所以安全的网络拓扑图中还是需要细化的可以精确到IP服务器的用于识别攻击），注意playbook的基线更新与优化：执行什么命令，返回什么结果才是正常现象，或者说安全设备哪些告警是误报
2.舆情监控，定期搜索公司/产品的负面消息，结合企业的实际情况
3.人工/自动化查看防病毒的安装情况，防病毒使用开源免费的也好，商业的也罢，我们自己要清楚现有的资产是否都安装了，该做验证做验证，不能一句话要安装防病毒，就把这近乎于最后的一道防线忽略了
4.数据库审计，结合企业的实际情况
培训
为什么把培训放在最后，是因为培训可以看做一个随时需要随时待命的过程，出了什么问题需要培训了再去做也行，一上来先培训也行，完全看业务需要了。
1.安全意识
这个是面向全员的不必多说，结合企业的实际情况推进
2.编码规范
这一部分要和研发经理去取取经，结合现有的开发编码规范去进行补充，研发负责人点头了，我们再去完善，切勿自己写一堆看似很全，结果没有人看的文档，那不如不要这一项
3.SDLC的推广
这个也不用说了，有了业务战略，自然要给各部门说一说我们要做的工作，收集各个部门的反馈，看看各个负责人能否配合，或者说沟通出更好的方式，迭代出一版各部门觉得能落地的SDLC
4.数据定级，word、文档等防泄漏
比较偏数据安全、办公安全，结合企业的实际情况推进
敏捷
其实做敏捷了，就不会说SDLC，毕竟敏捷大多是需求变动很快，安全还没反应过来，功能就已经上线了，如果是这类情况的话也不会有人愿意在敏捷去推SDLC的。但是敏捷也要管啊，这就是一个很极端的例子，我们的侧重点要变一变，削弱安全需求和安全设计的比重（除非本次迭代是安全方专门提出的需求了），或者直接裁剪，会发现不就成了DevSecOps了吗，所以如果到了敏捷上面，可能更多的就是熟悉业务外加测试，测试也会偏向于灰盒，做完业务测试，基本就ok的那种。
总结与思考
从敏捷里看到了一点，就是虽然都在强调安全左移，但是好像把后面的安全评估与测试做好，也能得个及格分。毕竟实践是检验真理的唯一标准，考验产品安全不安全，极大部分都是看能不能黑进来，既然如此，SDLC存在的价值是什么？当看完本文后，我们不妨回到本文的第一句话，为什么要做SDLC？
1.不管是对外沟通还是对上沟通，身为一个产品安全人员，如果能做到很熟悉业务，沟通会高效很多，也会更有底气
2.融入业务后，会慢慢知道业务的重点是哪些，慢慢识别风险的优先级，哪些业务适合SDLC，哪些业务适合DevSecOps。或许刚开始的几轮都不太需要安全去介入需求阶段或设计阶段，但是一旦有了较大的业务变动，这个时候，安全最起码是有所准备的
3.上面也说了，按照敏捷的思路，我们把DevSecOps做好，就能拿到及格分，不过细品是不一样的。每个阶段该做什么不是百分百固定的，是要根据企业的实际情况而定的，安全需求可以不做，安全设计也可以不做，安全需求提的再全面，安全设计写的再无懈可击，落不了地，最多就是个几兆的空白文档；既然说无用功我们不要去做，何为有用功？本次版本的安全需求要不要做，安全设计要不要做，最起码应该是安全识别出来的吧，换句话说，就算不做，最起码也应该是安全去评估过得出的结论说不需要做
4.当我们在进行应急响应的时候，熟悉业务的会反应出是哪块业务被攻击，大致影响的范围，而不熟悉业务大多是对这一个点，某台服务器…还有业务故障时，没有明确是攻击的时候，安全需要知道是哪块的业务故障，去排查哪一部分的安全设备，去排查哪一台服务器等等
5.当我们将SDLC闭环了一段时间后，会发现，首先安全团队的能力会有所提高，不论是业务的理解还是安全技能；然后就是整个团队的提高，当安全不断站在产品、开发、测试、基础架构的角度去考虑问题，那么潜移默化的，产品、开发、测试、基础架构也会在有问题时，考虑考虑安全方面，整个团队的安全意识会逐渐的提升