3.7.2　SDL落地率低的原因

1. DevOps的交付模式

互联网频繁的迭代和发布，不同于传统的软件开发过程。如果一个软件要一年交付，那么在前期抽出2～4周做安全设计也可以接受，但在互联网交付节奏下，可能一周到一个月就要发布版本，你可能没有足够的时间去思考安全这件事。对于SDL会拖慢整个发布节奏这个问题上，安全团队去推动也会直面公司管理层和研发线的挑战。不过当你有经验丰富的安全人员和自动化工具支持时，SDL在时间上是可以大大缩短的。

2. 历史问题

99%的甲方安全团队的工作都是以救火方式开始，SDL从来都不是安全建设第一个会想到的事情，而且业内心照不宣的一个原因是，“事前用不上力，偏事后风格的安全建设”贯穿于大多数安全团队的主线。之所以如此，原因是第一有火必救，有的团队救火上瘾，有的则能抽身转向系统性建设；第二想在事前用力，需要自己足够强大，能摆平研发，不够强大就会变成庸人自扰，自讨没趣，还不如回避。

3. 业务模式

大多数平台级互联网公司的开发以Web为主，超大型互联网公司才会进入底层架构造*的阶段，而对于以Web产品为主的安全建设，第一是事后修补的成本比较低，屡试不爽；第二是部分产品的生命周期不长，这两点一定程度上会让很多后加入安全行业的新同学认为“救火”=“安全建设”。但是在甲方待久了的人一定会发现，哪怕是Web，只要系统比较大，层层嵌套和不同子系统间的接口调用，会使得某些安全问题的修补成为疑难病症，可能就是设计之初没有考虑安全，致使问题不能得到根治。时间一久，技术债越积越多，大家最后一致默认这个问题没法解决。

4. SDL的门槛

其实SDL是有门槛的，而且还不低。最重要有两点：第一点是安全专家少，很多安全工作者懂攻防但未必懂开发，懂漏洞但未必懂设计，所以现实往往是很多安全团队能指导研发部门修复漏洞，但可能没意识到其实缺少指导安全设计的积累，因为安全设计是一件比漏洞修复门槛更高的事。看业内很多技术不错的安全研究者，写的文章，往往前半篇漏洞分析很给力，但到了安全建议环节好像就觉得少了点什么。第二点是工具支持少，静态代码扫描、动态Fuzz等，工欲善其事必先利其器，Facebook宣称其最好的程序员是投入到工具开发的，而对于国内很多安全团队而言，最好的人都不会用在工具开发上，而是奋斗在攻防第一线做救火队长。稍微好一点的情况是这帮人投入在做安全机制建设上，而业务部门也不会来帮助安全团队开发安全工具。这还跟公司整体上是否重视自动化测试有关，如果公司在测试领域的实践没有做到很前沿，那么安全的黑白盒测试也不会注重工具化建设，代码覆盖率和路径深度等更加不会有人去关注了。实际上不一定要在这个场景下自己去造*，用商业工具是不错的选择。