TOP 1
企业必须自上而下推行S-SDLC实施，且有相应的组织结构支撑
企业要实施S-SDLC，单靠传统的信息安全部门或几个网络安全人员是不行的，必须由公司领导层自上而下去推行。之所以必须是自上而下推行，一个重要的原因就是S-SDLC的实施并不是只有信息安全部门投入就可以了。S-SDLC会与研发部门的各个环境深度结合，需要研发部门的积极支持和全体参与。另外，安全对于大部分企业而言，能直接看到的是成本投入增加，而产出收益却是隐性的，并不会因为做了S-SDLC就能看到产品的直接销售收益。
因此，不管是对于研发部门还是其他部门，都很难有主动实施S-SDLC的动力。微软在推行时，是由比尔.盖茨亲自发邮件要求员工停下手上所有的工作后才开始实施；而华为则是由CEO担任全球网络安全委员会主任来推行实施。也就是说，如果没有高层领导自上而下的要求，安全部门推行S-SDLC只会是一厢情愿。相信很多安全部门在推行S-SDLC时，都会遇到研发团队不配合而导致无法推行或推行效果不理想的情况。
有了自上而下的要求，企业还要有相应的组织结构支撑，而合理的组织结构是保障S-SDLC实施效果的基础。因为S-SDLC在实施过程中会产生大量新的工作内容和新的工作流程，而这部分工作内容和工作职责混乱不清，将直接影响S-SDLC的执行效率和实施效果。
TOP 2
S-SDLC要与企业的质量管理体系相结合
不少企业实施S-SDLC时，将S-SDLC作为一个独立的流程来操作。这使得企业需要投入大量额外资源来支撑S-SDLC整个流程的运转，且实施的质量得不到保障。因此，S-SDLC的实施效果往往达不到预期。
安全本质上是产品的一种质量属性。在质量管理领域，业界已有成熟的方法和流程，比如：ISO9001、CMM等级，这些都用来保障产品的质量。大部分企业都设置有质量部门，并设置有质量管理人员角色。但安全往往因为专业性强，缺乏成熟的管理方法和流程，再加上安全部门的存在，因此产品质量部门通常不关心产品的安全问题。
在S-SDLC落地的过程中，将安全工程活动标准化，并纳入产品的质量体系，是保障S-SDLC实施效果的基础。举个例子来说：
当产品的某项安全指标没有达到要求时，质量部门有权否决产品的上市发布或上线运营？
TOP 3
建立合适的人员培训体系
在S-SDLC实施的过程中，安全不仅仅是软件安全专家的事，而是实施企业所有人的事。仅靠几个安全专家很难保证企业所有产品的安全质量，而信息安全部门或网络安全部门面对软件开发往往也力不从心。
S-SDLC虽然整体涉及软件产品的安全开发生命周期，偏重于方法和流程，但人的因素同样至关重要。对于同样的方法、同样的流程和同样的工具，如果实施人员的安全开发思想意识和技术能力不同，其产生的实施效果差异也会非常大。比如：某公司的安全部门要求所有口令都在hash后再存储，而开发人员就将口令设计成hash之后的结果，让人看了哭笑不得。
问：如何让所有研发人员都了解并关注软件安全开发？
答：建立一套合适的培训体系是较好的业界实践。这里的培训强调的是体系化的软件安全开发培训，而不是安全部门内部组织的信息安全知识培训或攻防渗透技术培训，因为对于不同的部门、不同的岗位、不同的人员，其安全的认知意识和技术能力也是不一样的。
简单来说，建议将安全培训分成不同的等级，且不同等级面向不同类型的人员群体。比如：软件安全开发意识培训可以面向所有人、软件安全编码培训可只面向开发和测试人员，而网络攻击技术培训可只面向安全专业人员。另外，需要让所有研发人员宏观的理解S-SDLC方法与流程，有助于让每个研发人员认知其与S-SDLC流程中上、下游角色的互动关系，也有助于让每个研发人员理解每一个S-SDLC的工作环节对整体产品安全的重要性。
目前，中国信息安全测评中心认证的“注册软件安全开发人员（CWASP CSSD）”人员资质，能为企业初步解决有关研发人员对S-SDLC意识认知和技能掌握的问题。
TOP 4
用度量体系将S-SDLC实施效果可视化
对于企业的研发高层领导来说，最关注的还是S-SDLC实施效果。如何让S-SDLC实施效果可视化，是S-SDLC实施过程中需要注意的重要问题。如果研发高层领导看不到S-SDLC的实施效果，那就意味着可能失去研发高层领导对S-SDLC实施的持续支持和资源投入，从而导致S-SDLC实施失败。
S-SDLC实施的效果本身就是隐性的。微软在这个问题上也没法给出立竿见影的效果，但今天Windows操作系统的安全性要比在S-SDLC实施前的Windows XP好多了，尽管今天的Windows操作系统还是有很多安全漏洞，但安全性的增强并不是简单地从漏洞数量上进行对比，而是漏洞发现的难度、漏洞利用的难度和漏洞被利用的影响都比之前有了明显的改善。
因此，作为S-SDLC实施人员，需要在实施S-SDLC前给研发部门高层领导一个相对合理的预期：世界上没有100%的安全，不能保证S-SDLC实施后就不会再有漏洞了；也不是实施了S-SDLC后安全就可以高枕无忧了。但这也并不意味着就完全看不到效果。
如何让S-SDLC实施的效果可视化，比较好的做法是建立一套度量体系，通过度量的方法让S-SDLC实施的效果可视化出来。度量体系本身也是一套复杂的工程，比如说业界的OWASPSAMM和BSIMM就是复杂的评估度量体系。实施人员可以选取一些比较直观且容易实施的工程活动，体现工程能力的成熟度提升，这个和软件成熟度CMM类似。另外，也要有结果性的数据，比如：可以对测试发现的安全问题进行分级，建立一个S-SDLC实施前的基线，再看S-SDLC实施后每一年的问题发展趋势。
TOP 5
产品的安全目标决定S-SDLC的过程
完整的S-SDLC包含众多的活动，而同样的活动在不同企业的投入弹性空间也非常大，以威胁建模为例，有的产品可能只花半天时间，而有的产品可能需要花一个月甚至更长时间。
笔者在S-SDLC实施的过程中同样遇到过很多类似问题：
这个活动需不需要做？
这个活动需要做到什么程度？
这个活动需求投入多少人？
对于这些问题，并没有统一的答案。因为不同的产品所处的环境不一样，面临的风险也不一样。但我们可以给出基本的判断原则。
这些原则的基本出发点就是产品的安全目标是什么？安全目标说起来容易，但要说清楚，就不是一件容易的事了。很多专业的安全人员往往更多的考虑安全技术，而忽略了安全目标。技术应该是用来支撑目标的达成，所以当目标不清楚的情况下，很难判断一项技术的使用是否合理？这些技术是否足够？这就导致了很多企业当前的一个现象：安全的投入好像是一个无底洞，不知道什么时候才能做完。这显然不是企业领导者所要的结果。
因此，在实施S-SDLC的过程中，定义一个清晰的安全目标，才能使S-SDLC的实施过程更加科学合理。
TOP 6
威胁模型可以使产品避免大的设计风险
如果问S-SDLC实施过程中有什么过程是特别难的，笔者相信很多真正实施过的企业或专家都会将这一票投给威胁建模。因为威胁建模做得太浅则感觉没什么效果；而做的太深则导致实施难度和投入成本的增加。如何取得深浅之度的平衡是威胁建模的难点所在。
要解决这个问题，还得从威胁建模的本质说起。威胁建模的本质是建立产品的威胁模型。而需要通过威胁建模达到什么样的目的，不少安全人员的理解也不太一样。
根据笔者所在团队的实践经验，一方面希望专业的安全人员通过威胁建模发现更多、更深入的产品设计漏洞，以呈现威胁建模的效果；另一方面又希望这一过程能工具化，使普通的研发人员也能发现同样的问题。但通常实际的效果是：经验丰富的安全人员不通过威胁建模的方法就能发现该问题；而普通的研发人员即使用了威胁建模的方法，也发现不了该问题。
对于这一现象，并不是威胁建模本身出了问题，而是企业对威胁建模的使用以及目标预期出了问题，威胁模型的核心作用是通过模型化的方式来管理威胁、风险和对应的缓解措施。威胁、风险、缓解措施这三者相辅相成，S-SDLC中STRIDE威胁建模方法可以将大颗粒度的威胁结构化，从而避免了产品威胁模型遗漏了大颗粒度的威胁，保证了威胁的完整性；有了威胁就会有风险，有风险就需要根据风险来设计相应的缓解措施；这就是威胁建模的核心价值。而发现设计漏洞，实际上就是发现某个威胁没有相应的缓解措施或是缓解措施的设计BUG可以被绕过。
这里还有一点值得注意，就是所有的缓解措施都不能100%的缓解风险，缓解措施的目的是通过合适的成本将风险降低到一个可接受的范围内。
TOP 7
安全特性组件化可尽量避免编码漏洞
代码漏洞对于软件来说几乎是不可避免的，据数据统计，代码量与漏洞成正比。即便最早提出和实施方法论的微软，也不能保证代码百分之百没有漏洞。
漏洞问题对产品来说是最直观的（可直接利用），也是最头痛的（消灭不了）；代码漏洞也是S-SDLC需要重点解决的问题。目前多数也认识到这一问题，并选择使用代码扫描工具，例如SAST和DAST等，但这类工具存在致命的缺陷：误报和漏报。误报过多造成大量研发资源的浪费，而漏报过多又会使得工具的应用效果大打折扣。代码扫描工具的漏报和误报是必然存在的，S-SDLC中也有如何降低漏洞和误报的实践，但这更多需要依赖于新型的安全检测工具去解决。
从S-SDLC的整体视角上看，扫描工具只能发现部分已存在的代码漏洞，并不能减少代码漏洞的产生，属于“后端被动式”的解决思路。S-SDLC更关注如何减少代码漏洞的产生，也就是如何从“前端”主动解决问题。一个比较好的实践就是将产品中的安全特性组件化，比如：密码算法模块、认证授权模块，这些模块都是重要的缓解措施实现，一旦出问题就导致缓解措施被绕过的漏洞。因此，将这些模块组件化，让不同的产品在这些领域都使用公共组件，而不用自己开发，自然也就不会引入漏洞；而这些公共的组件则由安全专业团队重点保障。在微软，为了避免参数校验问题导致和缓冲区溢出问题，由专业的安全团队重写了经常导致漏洞的函数（如：memcpy、strcpy）,并由一系列自身带有安全校验的函数来代替。这一措施使得产品在很大程度上解决了缓冲区溢出的问题（虽不能全部解决，但效果显而易而，且投入成本不高）。
TOP 8
管理第三方软件的风险
不论是传统的软件企业还是新型的互联网企业，在软件开发的过程中都免不了要使用第三方组件。第三方组件既包含开源软件，也包含商业软件。而且随着软件越复杂，第三方软件的使用数量也越来越多。从安全的角度看，第三方软件也是一个重要的风险源（比如，前两年OpenSSL的漏洞集中暴发）。第三方软件不仅是产品集成的组件，开发环境中所用到的工具也要作为第三方软件来对待（XcodeGhost事件大家应该都还记得）。
第三方软件与自主研发的软件不一样。S-SDLC的方法和流程没法覆盖开源社区和第三方厂商。那么如何管理第三方软件的风险，也是S-SDLC实施过程中面临的一个主要的问题。具体来说，笔者有以下几条好的实践可以供大家参考：
- 企业要有清单列表记录哪些产品使用了哪些第三方软件。一旦某个第三方软件出现漏洞，可以通过清单列表迅速排查。
- 企业要有清单列表记录禁用的第三方软件。对于那些安全问题比较多、风险较大的第三软件，应加入到这个禁用清单列表中禁止使用。
- 对于使用较多且开源的第三方组件，建议进行代码扫描，对于发现的漏洞，提交开源社区，并促使开源社区修复。
- 对于第三方软件的使用要有安全性指导（主要是规避一些因配置不当引入的安全问题）。
- 慎用对安全问题处理态度消极的厂商所开发的第三方软件。
TOP 9
安全服务化和自动化是实施DevSecOps的基础
近年来，DevOps的开发模式已被广泛应用。DevOps的核心思想是将开发和运维一体化，开发能快速推出产品进行AB测试，通过数个版本的迭代，使产品变得成熟稳定，同时也使产品功能变得丰富。
在DevOps开发模式下，传统的S-SDLC流程在DevOps模式下显得过于厚重，那么就需要有适用于DevOps流程的S-SDLC，这就是DevSecOps的由来。由于运维流程也一体化了，因此在传统S-SDLC的安全成本模型也就发生了变化。举个例子来说，在传统S-SDLC的测试过程中，我们要尽可能的发现所有的安全漏洞，因为产品一旦发布，漏洞的修复成本会很高；但在互联网企业自己开发、自己测试、自己运维的DevOps模式下，产品发布后，漏洞修复的成本并不一定有增加很多。因为运维一体化后，漏洞一旦发现，响应的时间可控制在一个很短的时间内。
但这并不是说DevOps之后开发过程中的安全活动就不需要做了，只是做的方式会有差异。这个差异主要来自于安全功能的服务化、自动化工具。安全功能服务化本身符合SOA架构和微服务架构的演进方向。安全功能服务化后，就能将产品的一些安全风险转移到安全服务上。
以IAM服务为例，采用成熟的IAM服务能在很大程度上降低产品在认证和授权方面的问题。AWS提供的移动应用账号服务可以让移动应用直接集成，而不用担心账号的安全问题；或是采用OAuth认证方式，采用安全性很强的Google、QQ、微信等知名厂商的安全认证对接。这样自然就减少了产品研发过程中的安全投入，使S-SDLC可以变得快起来。另一方面，采用工具实现自动化，也在很大程度上能减少S-SDLC过程的投入。比如，SecZone VulHunter灰盒安全测试工具，能够适用于软件产品开发和测试阶段，并在开发工程师和测试工程师在执行功能测试的同时无感知自动完成安全测试，符合DevOps和敏捷开发模式下软件产品快接迭代、快速交付的要求。
TOP 10
S-SDLC工具链
无论在普通开发、敏捷开发还是DevSecOps模式下，S-SDLC落地的关键都离不开流程体系和高度自动化工具链的融合。根据笔者所在团队的实践积累，若有一个一体化的平台能准确、完整地记录、管理和追踪软件产品在S-SDLC实施过程中的实际情况，实现软件产品开发信息在S-SDLC流程中跨活动、跨角色流动，才能真正确保软件产品的安全需求和安全威胁在开发、测试和部署运维过程中落地。而无论是需求阶段的需求库、开发与测试的安全测试工具，还是其他安全工具，都将成为S-SDLC工具链中的一环。
转载自 OWASP Secure Software Development Lifecycle Project和软件安全开发生命周期（S-SDLC）企业实践TOP 10
