所以在我的理解中DevSecOps并不是将安全团队合并到交付团队当中，而是赋能交付团队安全的能力，将安全活动前置。这样不仅仅可以大大的降低修复安全风险的成本，也可以让安全团队的工作变得更加容易。
在很多组织里面，安全风险和安全漏洞被视为软件质量的一个衡量标准，所以在软件交付验证阶段会有安全质量验证这一个环节。根据这个理论为基础，也就出现了将安全测试和漏洞扫描嵌入到自动发布流程中，甚至作为终止部署的一个重要衡量指标。
随着各个国家对安全的重视，越来越多个人隐私法律的出台，很多客户也开始慢慢关注软件供应商的安全能力和安全资质，以其作为决定性的考量指标。由于领域的不同，安全在软件开发中的重视程度也不同。
这也导致了安全的实施在不同领域的差异。在银行，财务，医疗和国有机构等领域，如果没有可控安全机制，软件开发甚至无法进行。各个领域对于合规性的要求不一样，风险的管控方式也有所区分。
所以业界出了很多标准和框架来帮助各个组织来实现安全管控，例如: NIST CSF, ISO/IEC 27001, FISMA, HIPPA, PCI DSS等。合规于这些标准就成为了衡量一个组织安全能力的其中一个因素。很多软件企业，供应商也为此投入了大量的精力来证明自己的合规性，提高其在市场中的竞争力。其中NIST是目前业界应用最广，最权威的安全机构，由美国联邦政府发起，为推动计算机网络安全最佳实践和发展为目的成立的。因此本文将会参照NIST的标准进行分享。
在软件开发中，无论应用的是敏捷还是瀑布模式，都存在需求分析，设计，开发，测试，部署和运维这几个阶段。交付周期的长短并不影响安全在开发周期中的活动的内容。此文章专注讨论软件开发周期中的安全活动，对于各个活动如何在不同开发模式中应用会在不同的章节进行详细讨论。以下表格中列举了各个阶段安全活动对应关系。
软件生产阶段
NIST安全软件开发框架
安全活动
需求分析
安全需求，隐私需求，风险视为其一部分
安全需求评估和履行
设计
检查软件设计，验证安全需求和风险与其合规性
威胁建模(Threat Modeling)
开发
验证第三方软件服从安全需求，检查/分析源代码来定位漏洞
静态代码扫描(SAST)，第三方模块检测 (SCA)
测试
测试可执行代码来定位漏洞，验证与安全需求的合规性
动态检测(DAST/IAST)，渗透测试(Penetration Testing)
部署
配置编译和构建流程来改善可执行代码的安全
配置验证，安全门
运维
漏洞报告的响应（持续的定位和确立漏洞，评估并将补救所有漏洞进行优先级排序，分析漏洞并且定位其根本原因）
安全响应程序，安全监控，运行环境安全防护（防火墙）
安全需求评估和履行：简单的说就是将安全团队制定好的，标准化的软件安全能力作为软件开发需求的一部分，有很多组织把安全需求作为非功能性需求或者技术债来履行，在此不想评判其方法的好坏。客观的角度分析，安全需求往往是从ISO/IEC等标准或者风险信息演化出的技术解决方案或安全控制手段。作为软件功能的完整组成部分，应该适当的被定位和排序。根据在周期内要实现的软件功能范围，安全的需求的范围也会随之变化。威胁建模：这是个在设计阶段常常容易被忽略的一个重要环节，它并不是针对某一个领域的安全实践。因为安全需求覆盖的范围比较广泛，而且会根据领域的不同而变化。而威胁建模则是针对软件设计方案中的威胁的定位，风险的分析。这种有针对性的分析会大大降低后期因安全问题重构的风险，也会帮助该软件建立自己的风险体系。勾画渗透测试的范围。静态代码扫描(SAST)：这是协助开发人员实现安全编码规范的重要组成部分，例如很多不规范的编码会影响程序的质量，不安全的编码规范会导致程序漏洞百出。不经意的为黑客留下程序的后门。第三方模块检测 (SCA)：我们很多的代码都是应用现有的框架来实现的，并且为了实现快速开发，引入了很多功能包/库。很多开发者并没有意识到，这些框架，包/库都存在一些风险。由于严重的依赖关系，这些甚至会成为我们没法轻易解决的致命漏洞。另外很多框架和库中也存在一些引用许可的问题，提前的检测并解决这些问题变得至关重要。动态检测(DAST/IAST)：在这里我将DAST和IAST放在一块儿，因为检测其目的相似。都会对正在执行的程序进行负面问题分析，模拟攻击。以便于定位在静态检测无法定位的问题。渗透测试(Penetration Testing)：这个是一个行业，很多安全专家，安全调查人员的必备技能。很多人会问，我们既然有了SAST, DAST/IAST为什么还要有渗透测试？其实DAST/IAST的工具的发展已经非常贴近渗透测试所具备的能力了，但是还是没有能完全达到由测试者的手动发掘的能力。所以大部分企业会在发展自己内部渗透测试者能力的同时，通常会雇佣外界比较专业的渗透测试公司来履行这个环节。因为他们的专业能力会真正的帮组验证软件应对外界攻击者威胁的能力。配置验证，安全门：在这里我们指的是有自动化部署能力的情况下，根据安全部门设定的规章制度，对软件部署过程中质量把控的办法。可以是通过某些条件制定的终止部署约束。也特别是在基础设施即代码(IaC)中的基础设施部署和变更时，安全的强化和规范。在这里提出一个新的概念：安全规范即代码。后期会在这个系列的章节中详细介绍。安全响应程序：这个程序指的是流程上，如何响应安全事件。这与客户支持的事件响应类似。但不同但是安全方面的响应，在解决问题的同时需要加入法律/合规部门，严重的情况需要公司高层对客户的回应。特别是涉及到公司信誉问题的时候。安全监控，运行环境安全防护（防火墙）：这对开发人员来讲可能并不是很熟悉。但却又是安全领域非常重要的一部分。现在越来越多的开发人员开始接触和配置应用防火墙(WAF)对网络应用程序进行保护。这说明随着安全的左移，开发人员需要关注的运维层面的安全问题也会越来越多。另外，安全监控是很大的一个话题。这个话题，我会根据大家对其的兴趣程度决定是否出一个专题来讨论。在此大家需要了解的是，无论是在云环境还是在传统环境下，安全监控是一个很专业的生态体系，不仅用于协助定位问题，而且在安全事件中组阻隔影响起着重要的作用。参考文献英文原文：https://csrc.nist.gov/publications/detail/white-paper/2019/06/11/mitigating-risk-of-software-vulnerabilities-with-ssdf/draft
V：CH050791
来源：DevSecOps SIG作者：Nick Yu
