SDL只是方法论，忌为SDL而SDL

一、sdl是什么 

我的看法:“sdl是安全研发生命周期 ,一个方法论, 理念是安全左移, 通过各种方法、工具、流程,设计和交付更安全的软件,以期望降低安全成本,最终还是为了保护企业和用户的资产”

一图胜千言,简化版sdl (偷个懒,太多了,概念性的东西不多说了,我就默认看的都是做过至少了解过sdl的;)

简化版sdl

二、为什么要sdl

成本,应急成本、修复成本、法律成本......

越来越多的安全事件、漏洞、法规要求, 这些成本也愈加明显,安全左移的需求也愈发迫切;

从传统应用安全(注重线上漏洞应急、安全测试)到SDL(全链路)其实也代表社会及软件行业对安全的需求和了解越发深入,从一个“必须解决的问题之一”发展到“应满足的最低要求之一”,

在欧美这个历程大概花了10-12年,在我国,可能还需要3-5年左右时间,(也许更快,从这个角度看(应用)安全应该还是在黄金时代初期);

这里放一张sdl的发展历程,from 微软官网https://www.microsoft.com/en-us/securityengineering/sdl/about这张图里的信息量还是比较大的,感兴趣的可以去了解下,包括TwC(microsoft-trustworthy-computing)、微软、思科和Adobe在sdl方面的共同协作倡导等;

SDL TimeLine

无论怎么看,SDL的最终目的还是“设计和交付更安全的软件,以期望降低安全成本,最终还是为了保护企业和用户的资产“,为了解决应用安全的问题,这一点不能忘记,也就是说,如果你在做SDL的时候,做的事情不能为这个目的服务,那是没有意义的 

三、实际建设中sdl的误区及痛

这里说一下SDL建设中常见的几种误解、误区,以及带来的痛;

1、领导对sdl的“误解”,如:

“灵丹妙药”:觉得sdl一上,应用安全能一下子缓解,不再是老大难

投入少:觉得sdl很容易就能实现,招一两个安全工程师就能落地,最多再搞搞自动化(一个人的sdl,甚至一个人的安全部)

实现快:从哪里听到看到SDL的这一套流程、工具和效果,就想照搬过来,直接复用,快速实现

......

总的来说就是“期望过高+资源很少”

2、其它部门对SDL的感受或“误解”,比如

找事的,因为需要相关同学给到配合,信息同步、做出相应action,举几个例子:

需求对应产品,要同步需求信息、评审会议信息、填写checlist或问答表、根据安全建议修改需求业务逻辑(或流程图)、上线要满足安全要求才能上线

开发对应研发:要同步代码提交信息给代码审计、要按照安全标准进行开发、要更新升级存在漏洞的三方包、要修复安全测试出的漏洞

集成发布对应研发及应用运维:要添加三方包检测(Nday及版权)、对接白盒扫描、对接自动化测试(IAST、DAST、SAST)

测试对应QA:同步测试进度、同步测试用例评审会信息、测试数据环境账号等等

pmo:每个环节都要管,都要参与,你们是不是pmo啊

......

3、安全人员对sdl的实施误区

                                                                                                                                        SDL 过程图示 

完全照搬:比如上面的sdl过程图示,各种规范、自动化上来就整一堆,推给各部门团队

心急:没摸清公司安全状况,没理清背景、需求就上马

拿来主义,生搬硬套,而不是因地制宜:举个例子,在上家公司经过两年摸索、建设,结合devops做成了一些安全自动化的东西,到新公司想在半年内就把原来的这套搭建起来,但这家公司没有相应的devops、IT能力支持,业务场景、产品类型也不同,结果费了大力做出来却效果不理想;更甚者,直接网上找来一些就去推广,自然被产品、研发怼的鼻青脸肿,后续工作也不好开展;

没有自己的节奏:尤其是遇到上面描述的领导时,容易被牵着走,结果也很不好

软性能力不足,受环境影响过大:在好的环境下有好的同事配合可以干好,而遇到自己不喜欢的环境、同事,就干不好

这些感受或“误解”、“误区”,加上工作或环境中的问题, 会带来SDL推行、落地时的各种困难,比如:

领导的要求不现实

被领导牵着鼻子走,乱了步子

同步信息不及时、忘了甚至不愿同步

问卷填写随意填,不一定真实正确

漏洞没修复就要上线,带伤上阵

修复时间一拖再拖,要跟在后面催

只要安全没卡点,就可以不用care

一段时间后没成果,领导或他人甚至自己都觉得没价值

......

这样下来,搞得自己和大家都很累,也没成果,最终黯然离场或混吃等死... 

四、应该怎么做

SDL只是方法论，忌为SDL而SDL

为什么会有上面那些误解、误区,

投入与预期   “既要马儿跑得快,还不给马儿吃草”

理解偏差,且太强调SDL,一定成度上将其“神话”了不同的人知识储备、能力、“屁股”都不相同,有理解偏差很正常,但要避免“神话”、“过分超出预期”;

工作开展方式问题,这个不能说是谁的问题,只能说结果不好,我们要去改进;

另外还有就是我们的软能力(如沟通、协调协作、管理、价值观等等)不足,需要加强,安全从业者多数是技术出身,这个问题也是技术同学的通病,但企业安全建设,尤其是sdl需要跨部门、沟通协作的地方格外多,那么出问题时不足也凸显了;

应该怎么做

1、也是前提,定好安全的战略目标(长期目标):要做成什么样的安全,实现什么样的效果,可以不用那么明确,大致期望即可,也是要跟领导传达安全需要时间,需要资源,是个长期投入、长期建设的事情;

2、同样也是前提,定出中短期的安全工作,根据风险评估(安全现状)来制定,同时最好能估算出之前、现在的安全成本,这样在SDL一段时间后,可以对比体现价值;

3、摸索出适合这家企业的打法节奏,要根据业务、团队、IT能力、同事等等因素来定,需要有个摸索过程,不同阶段、相应的项目or工具或平台;摸索的过程靠自己,共通之处可以借鉴(后面有机会展开~)

4、应用安全的合理性,开展的背景要明确(问boss、问leader、问自己),有答案了再做后面的事情,且要通晒同步对齐;

5、有些弯路是必须要走的:摸索的过程,找出合适的方法,同时也是给相关部门、团队、人一个了解接受的时间,这个过程绕不过去也有必要;

6、跟直属领导常沟通、常同步,方式很多:开会、主动讨论、周报(如周报 描述重点项目、解决什么问题、遇到什么问题和困难,需要什么协助;不用太细)

7、定期安全情况报告,可以分环节分对象来,比如漏洞管理情况、比如某业务的迭代需求及测试用例评审、安全测试结果;体现价值,涮存在感,获得认同;

8、提升软能力,建议根据冰山模型+学习提升管理能力

另外在公司安全建设战略甚至战术层面,不要过分强调“要做SDL”,个人认为沿用“应用安全”这个词会好很多,包括减少不必的沟通成本和超预期的情况,尤其是在资源不足,“一个人SDL”、甚至“一个人安全部”的情况下,好好把基础的东西做起来, 用能争取到资源,解决主要的风险,就一个字“稳”;

 徐徐图之, 其他的留给时间(拿多少钱办多少事,话糙理不糙);如果时间不能解决,那....该干嘛干嘛吧  (基操勿6)

各方面也都是再向成熟趋势走的,包括技术、整体IT能力、公司管理,对安全的投入等等, 安全治理 工作是要基于这些因素来开展的;

理清楚做SDL的目的,找到背景,顺理成章开展;不忘来路,始知归处; 

五、总结&后续:

SDL只是一个方法论,只是一种手段，而不是目的，安全左移理念,目的是设计与交付更安全的软件,来保护公司及用户资产,同时降低安全的成本;

如果盲目为了SDL而SDL,完全follow SDL ,结果必然是悲惨的,就算你能完全实现,那最直接的就是没业务了,公司就搞安全了... 因地制宜,适合自己的才是最好的,我们做SDL其实真正花时间去思考解决的就是找到合适的方法将SDL方法论落地来达到目标,这个顺序我们要明确,通俗一点说:有些弯路是必须要走的; 

方法论是一种以解决问题为目标的理论体系或系统，通常涉及对问题阶段、任务、工具、方法技巧的论述。方法论会对一系列具体的方法进行分析研究、系统总结并最终提出较为一般性的原则。

当然有许多工具、经验是就在那里,也值得我们去借鉴的,涉及对问题阶段、任务、工具、方法技巧,都能够提炼到一些共通的东西,这些后面具体展开,这里先说一下大致的思路;

sdl建设思路

首先确定我们的产品是有安全问题的，以前有过(比如外部白帽测试)，现在也有，以后也会有，这个跟bug是一个道理.

那么怎么就能更安全，目前就是在做测试,我们在测试SDL这个方法是否可行，类似我们要采购某个产品工具，我们要先测，测功能，测性能，测效果;分步骤在进行.

试点，是一个很常用的手段,(在流程、工具、效果、不同业务线适用度都需要做试点),在一家企业要做sdl时,第一个试点就是测试sdl流程能否在这家企业跑通，能否工作运转起来；同时也会测效果，能否提升安全，但这块后续还会有试点项目来进行验证；第一个试点建议找比较稳定的项目，来测流程是比较合适的。试点过程中会发现很多问题,不仅是流程或安全知识技能、工具,还有公司环境、人等方面的,这些不同企业所特有的问题是更需要思考去解决的; 总结出问题、尝试解决方法、(比如沟通成本高,能否有方便沟通双方的方法,工具?比如覆盖率低,比如不配合等等,详见上面的困难)

那如果测试结果发现SDL不管用，不能跑通，或者不能使我们更安全，(当然不太可能，毕竟这个是业界比认可的，但不同场景公司是有自己的特殊性，就不适用通用别人公司的方法)，或者遇到各种问题, 效果没我们想象中的好，那我们就换一种方法，或者参考/添加一些方法、元素，比如SAMM，比如以前的测试修复模式，比如BSIMM,比如事件驱动，比如威胁建模等等，或者取这些方法的优点，来做一个适合自己的东西出来，当然 我们也可以继续把这个东西叫做SDL，只要结果是对的就好，是能提升我们产品安全性即可。 

当然 这些话没必要对老板去讲，老板只要结果。

我们在过程中去做去改进即可去拿到结果。实在要说，就一句话：我们在不断改进，得到更适合我们自己的方法来进行。 

那么目前看来，阔以提取到的通用元素的是什么(设计交付更安全的软件的要素),比如：

流程(阔以借鉴PMP，项目管理方面知识)

工具化自动化

人员及能力

威胁建模(安全分析设计能力)

......

接下来就是如何将这些元素在自己的公司里/场景下实现、串联、运转到落地应用;

这些元素在不同企业里落地时的共通点,以及涉及的软能力提升,凸显价值等等

后续一个一个展开,先挖坑,待填(但愿不会太监)

SDL-建设的两种模式   

SDL--与devsecops   

SDL--人员及能力之冰山模型与SDL建设

......

*本文作者：若水行，转载请注明来自FreeBuf.COM