今天PYQ看到一篇文章《SDL已死，应用安全路在何方？》，也就想着来扯谈一下SDL。不做科普，不捧不踩，纯粹扯谈。
很“重”的SDL
实际上，SDL已经挺重的了，这是我个人的感觉。这个重有几个方面：
1、流程重。
SDL要做卡点，要做持续集成，就需要将设计、开发、测试、上线、运行拆得很细，做精细化管理，明确到什么阶段要做什么检查，要遵循什么规范，要提交什么材料。这个过程中涉及的流程、工具、规范的量不小。除了要专业懂技术的人来做，还得有专业懂做事的人来推动。而往往，这两类人不是同一个人。
2、人员重。
SDL要做好覆盖，需要安全、开发、测试、运维、产品等各类人员参与和投入。而且，越是重视开发的公司，或是开发人员基数越大的公司，SDL涉及到的和需要协调的人就越多，层级越复杂。这其中单是做好协作，约定好相互间的边界，还得让大家都按章办事，就是一个巨大的命题，不是你说的有道理就能做好的。
3、工具重。
在持续集成过程中，SDL需要大量的工具支撑，有开发工具、有测试工具，也有安全工具。这其中有商业的，有开源的（说不定还有破解的）。要打通这些工具，把工具一个个安排得明明白白，还要确保这些工具能完全支撑覆盖SDL全流程、全要求，很重。
4、责任重。
貌似有了SDL，开发上的安全问题就公认的变成了SDL团队的责任了。然而，令人尴尬的事实是，SDL团队很多时候只是一个背锅侠，且没有太多容错的余地。爆发的安全问题千奇百怪，SDL也人力有穷尽。况且，大部分公司中，SDL背负的这种责任重担，并没有与之相配的权利，或者相对应的决策层实际支持，也没有那么多人去干完那么多事。“屁股决定脑袋”，这句话是人性。
综上所述，SDL之所以很重，是因为SDL是在和人性做对抗。人性向往自由，人性是自私的，人性趋利避害，人性不讲逻辑只讲感觉，人性只认是否不认是非。而SDL从诞生那一刻开始，就是作为集体意志去约束人性，避免个人的“放荡不羁爱自由”导致集体为个人的人性和行为买单。
所以，我觉得，现今大部分公司SDL的出发点，并不是解决软件安全漏洞，而是解决造成软件安全漏洞的人。当然，感觉外面那些挖洞的是搞不定的，所以只能是搞定内部造洞的。
那首先就来扯谈一下：
SDL能从解决造成漏洞的人变为解决漏洞么？
关于这个问题，先提一个问题，软件安全漏洞在什么情况下才会被利用？我觉得答案是：这个软件已经上线或是可以被访问。只有这样，外部挖洞的，或者内部违规利用的，才有一个基础去利用这个漏洞。
因此，如果从这个角度出发，如果SDL的目标变成解决漏洞，那关注点应该集中在上线或测试部署前的这些关键节点。至于更之前的开发环节，纯粹是为了信息收集的需要。
那做SDL的人，就需要做到在这些关键节点能尽可能全面的发现各类漏洞。基于这个出发点，安全测试实际和开发测试的功能没有太大的区别，考验的不外乎：对需求的熟悉度，对功能实现方式的熟悉度，对代码的熟悉度，测试环境的功能性、独立性，测试用例的全面性，以及必要的测试工具和测试效率问题。理论上，测试用例足够全面，测试环境模拟仿真度足够，测试流程上卡点覆盖全面，是可以保证安全测试的正向有效性的。
但是，这只是理论。真实情况是怎样的呢？
首先，个人以为，测试工作实际是一个信息收集工作，通过各种工具、流程、文档等等，让测试人员去收集和分析足够支撑其对测试结果做出判断的信息，并通过一定的机制和工具，来保证其不会出现认知偏差。
然而，现今大部分公司的SDL，将安全测试和开发测试切割得很厉害，并不具备与测试的信息收集能力和信息解读能力，或者更应该说，没有对应的信息收集的意识，也没有对应的方法论支撑。因此，很多安全测试的测试用例都是抄来抄去的大路货，测试的时候也从来不看测试文档和设计文档，只是用工具机械扫描，或者全凭个人经验、心情和效率发挥的手工测试。同时，大部分SDL都会独立于开发、测试之外，再建一个安全测试流程，并设置相应的卡点。这种做法，看似与开发、测试流程保持一致，实际是游离在已有的体系之外。说白了，就不是开发、测试的自己人。这种游离感，会导致几个问题出现：
1、团队间的信息共享壁垒会影响到安全测试的信息收集，安全测试费九牛二虎之力也可能拿不到或拿不全自己应该知道的信息。最典型的就是开发经常会想法设法绕过SDL团队监管，保持对安全测试团队的信息不透明。
2、安全测试变相成为整个开发体系中兜底安全漏洞问题的最后一道防线，本该分摊给所有环节的责任，会因人性使然，逐步压向安全测试，安全测试也就越管越宽。典型的就有，一些因功能设计、代码实现不好导致的性能瓶颈、架构安全问题，会变为需求就是如此，要求安全给予例外或者兜底。
3、SDL的体系流程变成了既有流程外的冗余流程，需要设计、开发、测试更多的时间、精力去沟通、协调、走流程。对于各个被业务天天逼债的研发经理来说，安全既然不是自己的责任，那SDL就是个负担，除了增加了成本，拉长了周期，拖慢了进度外，最主要的是：不可控！自然抵触很大。
所以，是不是可以做些改变？
比如，重新审视SDL，将SDL的安全管控集中在安全测试和上线阶段。同时，将SDL的安全测试人员划归测试团队（安全招人，测试用），将安全测试的对应责任和权利归入测试体系，安全测试环境、工具、测试用例、文档等，以及相应的流程、进度把控，都由测试团队负责，与测试工作统筹考虑分配。这一过程中，主导的是研发团队自身，安全测试也是研发的一分子。
此外，安全部门不为漏洞兜底，由研发自行负责兜底。安全部门不再介入正向流程，仅担当监管者、培训者的角色。一是对测试人员做培训，帮助其提升安全测试技能水平；二是对测试人员提要求，总结过往事件，明确可能导致漏洞的安全红线；三是以蓝军形式开展类似实战的攻防演练，发现被漏过的漏洞，并以此反向考核研发团队的安全绩效（注意，不是考核研发团队的安全测试，二是考核整个团队和研发负责人）。四是建立SRC，收集外部漏洞情报信息和安全技术信息，既做培训，也做考核，还做漏洞事件的第一响应。
这些改变，有几点好处：
1）SDL流程完全内嵌到研发内部，由研发自主控制，但接受安全的外部监督。
2）安全测试人员融于整个研发体系，可以通过既有较成熟的研发内部协同体系去获取需要的信息，做该做的事，减少不必要的沟通。
3）当责任归于研发自身时，如何给安全测试足够的信息、足够的时间和足够的工具，去让其做好对漏洞的测试，就属于研发内部事务了。有了责任，自然也会更尽心，板子也能落到应该落的地方。
4）安全部门责任更加清晰，也为人本就不多、预算时常被压缩的安全部门轻装减负。摆脱较重的SDL正向过程事务后，安全部门才能更集中精力做好漏洞相关的培训、监管和响应工作。
当然，也有一些需要考虑的地方，比如：
1）在既有安全兜底漏洞的情况下，把责任和安全测试人员放回研发体系中，研发团队接不接受。（所以，需要高层的支持。）
2）安全测试人员的流动性，以及现有SDL团队人员是否接受变为研发的一份子。（可能会打破某些无形的优越感。）
3）受制于研发内部体系的成熟度，不成熟的研发体系下，这样做不一定达到预期效果。
最后，要说明的是，这样做并不能保证解决了漏洞，而是尝试去解决漏洞的源头、责任归属和SDL落地难的问题，而实际可操作性则要视各家情况而定。
至于如何在解决造洞的人这个命题，留待之后再继续扯谈。