OWASP的s-sdlc项目优秀分享

参考链接：OWASP Secure Software Development Lifecycle Project - OWASP

s-SDLC大量借鉴了一般项目管理生命周期方法和软件开发流程中的元素，从所涉及的步骤和阶段的相似性中可以明显看出这一点。参考OWASP中提到的s-SDLC项目,总结如下几点s-SDLC项目推行参考实践：

实践1：自上而下推行软件开发安全落地，且有组织结构支撑

企业在软件开发安全落地的时候，仅依赖传统的信息安全部门或者网络安全部门的规划是远远不够的，必须要自上而下的推动。其中一个非常重要的原因，是软件开发安全需要和开发各个环节深度地结合，需要得到研发部门所有人全力的支持，还需要在各个开发环节给出相应的开发规范、相应的开发安全技能和工具。因此，企业需要自上而下的推动，来引导开发安全的落地。

实践2：软件开发安全要与企业的质量管理体系相结合

大部分企业都设有质量管理部门，并有相应的质量管理人员。但是，质量管理部门通常不关心产品的安全问题，却忽略了安全在本质上也是产品的一项质量指标。在质量管理领域里好的质量应该是设计出来的，同样软件安全也应该是在前期就应该做好的。业界已有成熟的方法和流程，如：ISO9001、CMM等级，这些都用来保障产品的质量的方法。在软件开发安全落地的过程中，需要将一些具体的软件安全指标作为质量管理的标准，比如说普通缺陷和高危漏洞的数量、漏洞修复情况等，质量管理部门可以根据这些指标来决定产品是否可以上线或交付。

实践3：用度量体系将软件开发安全实施效果可视化

一套成型的度量体系，能够将软件开发安全实施的效果形象化地呈现出来。为何要做效果可视化，原因可见于第1点实践建议，软件开发安全需要通过自上而下的推动。若要普及安全意识，就必须让其他公司员工亲眼“看见”安全的重要性。只有将安全的效果可视化，才能更容易地获得管理层和团队其他人的持续性支持。在做这个度量体系之前，我们还需要达成一个共识，就是“世界上没有百分之百的安全，因为安全本身就是动态变化的。”我们不能保证实施了开发安全就不会有漏洞存在，但可以给出一个相对合理的预期，通过软件开发安全实施后，我们尽可能减少了缺陷的存在，把风险控制在一个可控范围以内，在这种情况下建立一套度量体系，通过度量方法把软件开发安全成果呈现出来。一般而言，成果呈现有两种方式。一种是通过软件开发安全能力成熟度来体现，能力成熟度的提升可以证明团队的软件开发安全能力得到了提高，能够开发出更加安全可信的软件产品。另一种，是通过一些结果性的数据来判断我们开发安全是有效的。比如说我们能够在软件上线前做了相应的测试和修复工作，来表明软件上线时是不带有严重高危漏洞，这种情况下也是一个非常好的这么一种结果的一种展示。在开发安全业界中，比较成熟的度量体系有两种，一个是 OWASP SAMM 模型，另一个是 BSIMM 模型，这两个模型在行业里面有很高的知名度，也是很多团队在做软件开发安全能力评估的时候常用的方法。

实践4：建立合适的软件开发安全人员培训体系

软件开发安全不仅仅是偏重于方法和实践， “人”也是其中非常重要的一个因素。想让开发人员了解并且关注软件开发安全，就需要建立起一套合适的安全人员培训体系。与信息安全培训不同，安全人员培训更聚焦在软件开发安全的意识理念和技术能力方面，其中的意识培训板块包括了软件开发安全的基本知识，开发流程与典型的实践，还有一些国家法律法规以及行业标准层面的信息。除了软件安全意识培训外，还有相应的技术能力培训，其中包括安全编码的能力、代码审计能力、威胁建模能力等。在整个培训体系下，我们需要把培训分成不同等级，再去面向不同类型的开发人员和安全人员来提供培训内容。

实践5：威胁模型可以使产品避免大的设计风险

在软件开发过程中，增加一些威胁建模的设计工作。它能建立起产品的威胁模型，通过模型化的方法来管理软件的安全威胁，能有效侦察风险与推进缓解措施的实施。STRIDE 威胁建模方法可以将大颗粒度的威胁结构化，避免威胁模型遗漏大颗粒度的威胁，保证威胁的完整性；一套威胁模型的最核心价值，就在于能发现软件的设计漏洞，即发现某个具体的威胁没有相应的缓解措施或缓解措施不足。

实践6：安全特性组件化可尽量避免编码漏洞

安全功能的组件化，能帮助我们有效规避编码漏洞。固然，安全扫描工具能够识别一些已经存在的编码漏洞，却无法从防治编码漏洞的产生。安全功能的组件化的意义，就在于从根源上遏制漏洞的产生。虽然之前提到了通过培训提高安全编码能力，但我们还是不能保证所有开发人员编写的代码都不含漏洞。而如果我们能把一些安全功能组件化，尽可能简化开发人员自主编写的流程，就能降低代码出错的风险、提高代码编写的规范性。因为这些组件在成为开发团队的公共组件时，本身就获得了安全团队的重点保障。

实践7：管理第三方组件和第三方软件的风险

管理好开发过程中应用的第三方组件的风险。这里的“第三方组件”不仅仅包括开源组件，还包括商业性的组件，这些组件不仅多见于信创行业，在其他行业所应用的占比也是非常大的。尤其是现在对软件供应链安全的高度重视，大家对组件自带安全漏洞而造成的破坏力也是有目共睹。所以，我们有必要做好第三方组件和软件的资产管理，通过相应的资产清单，来确定团队研发的软件哪些使用了第三方，一旦软件发生漏洞事件，可以根据清单迅速排查处理。

实践8：使用自动化软件安全测试工具链

无论是瀑布式开发场景下的 s-SDLC 还是敏捷开发场景下的 DevSecOps，软件开发安全的落地始终离不开流程体系和高度自动化的工具链的融合，常见的应用检测工具包括 SAST、DAST、IAST、SCA 、FUZZ 等，都是有助于软件开发安全落地工作的自动化工具，我们可以通过使用这些工具来提升真正软件安全测试的效率和软件开发安全的工作效率。