不管SDLC还是Devops，请把好安全质量门

       微软自2004年就采用SDL（Security Development Lifecycle），即安全开发生命周期。后面很多安全企业提出S-SDLC（Secure Software Development Lifecycle）。这个概念也是被安全行业的公益组织OWASP所支持。安全中的SDLC就是指将原来集中在软件开发生命周期后期进行的工作，放到软件开发生命周期各个阶段去，在每个阶段做安全该做能做的事，我想这就是软件内生安全的一部分。所以，我还是借用软件测试行业那句传统话：软件质量是开发出来的，而不是测试出来的。软件测试工作本身就是软件开发过程工作的一部分，而不是决然分开的一个过程。

       下面我们看一下SDL安全开发生命周期图：

       在第二阶段需求这一列中，强调了确定安全需求。需要有专职安全团队成员参与系统安全分析和需求梳理出；开发团队和安全团队识别软件中关键的安全风险，包括软件必须遵循的标准，例如组织和法律、法规等；确保开发团队和安全团队之间的沟通通畅；消除团队之间的差异，取得共识。

       质量门的建立即坚持最低级别的安全可接受指标。例如，可以要求具有中等级别以上的安全漏洞的软件不能投入生产或进入下一个研发阶段。标记中、高风险漏洞的任何代码都应返回给开发团队进行修复。一旦建立了质量门，也就是建立了一个质量制度或代码质量标准，无论应用系统发布的进程如何紧急，永远不允许含有中高风险漏洞的软件投入生产。您可以有理由说服你的上级和老板，确保通过质量门限后，才能进入下一个阶段。

       只有质量门建立后，下一步才能分析开发软件系统的攻击面。进出软件的所有命令和数据以及软件中需要保护的有价值数据。当然您可以采用微软的迈克尔霍华德设计的相对攻击面商数方法或采用卡内基梅隆的攻击面度量方法进行攻击面分析，确定代码中最关键和最易受攻击的区域，确保在开发和测试期间关注这些攻击面。

       在攻击面分析完成后，进行威胁建模，威胁建模可以帮助开发人员了解应用程序需要哪些安全控制，从开始就构建安全性。通过建模过程，掌握需要保护哪些资产和资源，获得这些资产和资源的入口和接入点，建立威胁优先级矩阵并为每一个威胁制定缓解措施。

      不管是进行攻击面分析还是威胁建模，都是以建立的质量门，当然也可以称之为安全门为基础。建立Devops或DevSecOps也必然有这个环节。建立安全门，是需要安全人员具有建立安全编码规范的能力，代码安全漏洞识别能力以及缺陷识别能力，而传统的安全人员大多侧重于应用安全级别上的能力，建立质量门需要安全人员、测试人员、开发人员等的合作，才能建立起切实可行的质量门。但是现在有一种更简单、更高效的方法，基于SAST技术的代码安全检测工具，都内置了大量的安全检测器，包括了安全编码规范、运行时缺陷和安全漏洞的规则检查器，企业可以在工具本身提供的全量检测器的基础上，定制出自己的检测器集合，这个检测器集合就可以确定为安全门或质量门。当然有些企业有一些特定的安全检测要求，可以在工具中增加定制这些规则，就真正打造出适合企业自己的质量门。而通过自动化的检测工具，不但高效，而且客观、公正的保证质量门的落地性，对任何一个团队或开发人员都是公平的，你的代码跨越不了质量门，你就不能提交到SVN或Git，无法与团队的代码进行集成。

       虽然国内外有很多此类工具，但是国内真正自主、可控的检测工具相对较少，例如北大软件的CoBOT，可以说是国内最成熟、自主、可控，具有专利技术的代码安全检测工具，是企业正值做国产化替换的首选工具。

-------------------------------------------------------------

关注安全   关注作者