关于SDL落地的一点思考

将SDL流程从0-1落地是非常艰难的一件事，重点还是在于除安全人员之外，公司其它人员不够重视SDL，甚至不知道SDL。所以在开始SDL建设的时候，第一步应该编写好SDL标准，标准不涉及具体的技术细节，只是要让公司业务侧人员知道软件开发的各个阶段都应该进行安全活动，而并非总是完成开发后找到安全工程师进行安全测试。而要业务侧人员都参与到SDL活动中来，这离不开积极的宣贯、高层的支持。

sdl阻力与克服

说实话，从我个人经历来讲，sdl最大的阻力还是在于高层不够重视，所以在进行宣贯的时候业务侧有些人不积极配合，或者随意应付，并没有把这个事情放在心上。

sdl流程的落地应该让高层重视起来，在中小型互联网企业至少应该得到CTO这一层的大力支持。如果CTO无法支持，那么开展SDL会非常的困难，毕竟安全团队和业务团队没有利益绑定，相反业务团队参与SDL可能会影响到自身的利益，最常见的就是业务侧参与安全活动导致业务无法在预定的时间上线。

如何克服SDL落地的阻力？

1. 治标：积极主动的去和业务团队沟通，和业务团队老大打好关系（软技能），偶尔请人家团队吃个饭，有事没事找人家唠唠嗑无意中灌输安全非常重要的思想。
2. 治本：得到技术负责人（CTO）的大力支持，建立信息安全委员会，制定相对应的奖惩制度；如何得到技术负责人的大力支持，这又是一个棘手的问题。有些技术负责人是懂安全的，或者经历过比较严重的安全事件的，如果遇到这样的技术负责人那会简单很多。但是如果技术负责人不懂安全，没有经历过严重的安全事件，要得到他的支持也有一些难度。技术负责人比我们安全人员考虑的要多，需要从人力成本、时间成本、投入资金等方面综合性的考量，不是说支持就支持的。这种情况下，安全负责人就应该把《网络安全法》、《数据安全法》、其它企业遭受到攻击产生的损失的案例、安全问题滞后发现所增加的修复成本等搬出来震慑一下，这样CTO多多少少会给予一些支持。如果CTO油盐不进，那我就奇怪了，他招聘安全工程师来是想干嘛？

SDL前置工作

上面说了SDL落地的阻力和克服方法，但如果只是写一个标准化文档来宣贯还是无法讲SDL流程run起来的。在将SDL标准进行宣贯之前就应该开始做一些前置事情。在宣贯之后，能让SDL流程跑通。

1. 编写各个阶段需要的指南和规范：安全需求清单、软件设计安全规范、业务系统定级指南、安全编码规范、安全自测工具使用说明、应急响应指南等
2. 开发或采购SDLC平台，平台应该具备以下功能：新建项目/系统，对系统进行定级，安全提测和排期，展示SDLC流程中安全检测工具发现的漏洞并可以对漏洞状态进行修改（漏洞管理）
3. 建立起安全检测能力：sast、iast、sca、cast、dast

安全工程师介入SDL流程

并不是软件开发过程所有阶段都需要SDL工程师介入，SDL工程师的工作职责是尽可能的将安全前置（左移），如果说在业务上线后出现安全事件，则应该由应急响应工程师出手解决

1. 对需求进行风险评估，根据《网络安全法》、《数据安全法》、《个人隐私保护》等方面提出安全需求；
2. 对软件设计进行威胁建模，对软件架构师进行访谈，发现软件设计中存在的安全缺陷，并给出安全建议；
3. 静态代码扫描（sast）、软件供应链分析扫描（sca），容器安全检测（cast）。其实这个事情应该是开发人员进行自测，安全人员只需要指导开发人员怎么进行自测就行，培养起开发人员自测的习惯。
4. 安全测试，如果研发人员已经做过sast、sca了，那安全工程师只需要进行黑盒测试。这是项目正式上线前最后一道安全检测关卡，一是验证1和2中提出的安全需求和建议有没有得到有效实施，二是挖掘3中工具无法检测出的安全问题，比如条件竞争漏洞、登陆逻辑缺陷、权限控制不当等特定场景的逻辑漏洞。
5. 系统正式上线后，要验证一下是否配置WAF，业务系统的服务器是否安装了hdis
6. 如果发现业务系统中断、或者hids监测到服务器被入侵，安全工程师需要马上进行安全事件应急响应。（这个其实应该是安全运营人员要做的，但在1、2阶段的初创企业，SDL工程师也应该具备简单的应急响应能力）