近期在宋老师在一家互联网软件安全公司负责一块业务的运营工作，其实安全也是软件的一种质量属性，属于软件质量管理范畴。但发现很多，软件质量管理同学，居然对安全开发过程和实践没什么概念，这样显然是要落伍的哦。所以，本文给大家做个介绍，希望对大家有帮助。
01
什么是SDL
软件业随着windows及web应用出现，Saas和云应用发展，针对软件的攻击开始变得复杂和频繁，工业界也通过多种手段来修复安全问题，推动了诸如，杀毒软件、防火墙、反间谍软件的出现。但应用多种防护手段后，依然发生大型数据泄露事件和安全漏洞利用事件，大家意识到问题的根源还是是软件代码本身存在漏洞。因此，要回到整个开发过程中去解决安全问题。
美国国土安全部2006年草案“软件生命周期中的安全”描述：
安全软件和不安全的软件最关键区别在于描述、设计和开发软件等过程与实践中的性质。。。采用安全增强的过程和实践，尽可能早地修复软件开发生命周期中潜在的安全漏洞，比普遍采用的频繁开发和发布运行中软件补丁的方法更加经济实用。
著名的安全公司Fortify曾发布数据表明，需求分析层面纠正安全缺陷的成本，比现场修复的成本低100倍。
业界认识到把安全从运维端左移到开发过程中，才是更优的选项。
基于安全要从源头抓起的思想，Microsoft 提出的SDL安全开发生命周期模型（见下图），得到广泛应用。该模型在软件研发过程中加入了安全实践，帮助开发人员构建高安全性的软件，减少开发成本，并解决安全合规需求。
在实际软件开发中，需要将安全性实践集成到选择的软件开发生命周期的每个阶段，从需求分析到运维，其实无需考虑软件开发生命周期是瀑布式、敏捷还是DevOps。
国内的Seczone开源网安公司也提出S-SDLC（安全的软件开发生命周期），其可以看成是SDL的一种具体落地的实现工具与实践集。
下图是S-SDLC全景图
02
什么是DevOps？
根据百度百科对DevOps定义：
DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。它是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运维工作必须紧密合作。
举几个例子：Facebook有数千名开发和运维人员，成千上万台服务器。平均来说一位运维人员负责500台服务器（还认为自动化是可选的吗？）他们每天部署两次（环式部署，Deployment ring的概念）。Flickr每天部署10次。Netflix明确针对失败进行各种设计！他们的软件按照设计从最底层即可容忍系统失败，他们会在生产环境中进行全面的测试：每天通过随机关闭虚拟机的方式在生产环境中执行65000次失败测试…… 并确保这种情况下一切依然可以正常工作。
而如果用传统手工的部署方式会遇到什么问题呢？
这些统计告诉我们：只需手工运行5条命令的情况下，成功部署的概率就已跌至86%。如需手工运行55条命令，成功部署的概率将跌至22%。如需手工运行100条命令，成功部署的概率将趋近于0（仅2%）！
为真正敏捷的交付软件价值给客户，必须将敏捷扩展至运维端，才能实现真正的端到端的价值流动和及时客户反馈、快速迭代，持续集成、部署的自动化是这一方法体系的核心能力！
DevOps的知识体系如下图所示：
其实不难发现，DevOps依然归属于敏捷方法体系。
如果说敏捷开发，解决了产品-测试-开发一体化，提高软件对需求响应的灵活性，改善组织适应环境的能力。到DevOps ，解决开发-测试-运维一体化的问题，使得组织的响应业务、持续反馈的能力更进一步加强，从而进一步提升环境适应能力，增强了组织竞争力。
业界很多专家认可，DevOps是敏捷方法体系的延伸，并不是与敏捷并列的一种新的方法体系。因此，无论是敏捷还是DevOps，其核心都是增量迭代模型。
自动化需要工具链的支撑，其中常用的框架可能如下图所示：
03
从DevOps到DevSecOps
DevOps促进了软件效能的大幅提升，但从历史上看，单纯使用敏捷方法开发软件时，几乎不包含安全性。这是由于敏捷方法专注于快速满足客户直接需求的功能，而安全性作为
潜在需求并未得到应有的重视。
据相关数据显示，2020年，预计全球互联网将连接300亿个物联网设备。除了设备数量之外，DevOps在企业生态系统中的采用率已经达到了较高的水平，一些技术领先的公司每天还进行数以万次的项目构建。因而它也成为了对网络攻击者很有吸引力的目标。特斯拉基于云的DevOps 平台被劫持是一个例子，它表明了为什么这些环境必须融合到企业的总体安全策略中，从而全面覆盖不断增长的攻击面。
随着连接的数量和广度在世界范围内呈指数级增长，将安全性集成到DevOps系统中比以往任何时候都更加重要，安全专家们也一直在探索。
DevSecOps通过在DevOps其生命周期阶段融入相关的安全实践，以帮助企业达成DevSec+SecOps的目标，使得近期DevSecOps成为业界关注的新的焦点。
DevSecOps（Development Security Operations的缩写），最早由Gartner咨询公司研究员David Cearley在2012年首次提出，它是一种糅合了开发、安全及运营理念的全新安全管理模式。2016年9月，Gartner发布报告《DevSecOps:How to Seamlessly Integrate Security into DevOps》，提出了DevSecOps模型
业内首次对该模型及配套解决方案进行详细的分析，核心理念为：“安全是整个IT团队（包括开发、测试、运维及安全团队）所有成员的责任，需要贯穿整个业务生命周期的每一个环节。“每个人都对安全负责"，安全工作前置，柔和嵌入现有开发流程体系。
DevSecOps不再是一个单纯的安全开发模型，也不仅仅是关注开发阶段，它所强调的是人人为安全负责，人人参与安全，安全嵌入到开发到运维的每个阶段。安全团队不再置身于业务之外，安全作为软件属性是由开发、安全、运维、QA一起协作达成的过程。
但实际上DevSecOps目前还在不断的演进中，业界并没有标准化得体系结构，Gartner给出的实践参考
下面是另一组织的具体参考实现工具链架构：
在RSA2018会上“The road to faster，better and stronger software（通往更快、更好、更强大的软件之路）”，这句话似乎寄托了业界精英们对于IT运营“工业革命”道路的强烈希冀。参展商对于CI/CD实现方式的趋同、机器学习等新技术的大量引入以及厂商之间接口标准的融合，我们几乎可以预见到DevSecOps完美落地的那一刻。
RSA大会上出现的一个热词“Golden Pipeline（黄金管道）”，尤其在DevSecOps Day当天，无论是关于“凤凰项目”还是房利美的运营实践中都使用了Golden Pipeline作为主要线索进行讲解。那么Golden Pipeline到底指的是什么呢？
Golden Pipeline字面译为“金色管道”，特指一套通过稳定的、可预期的、安全的方式自动化地进行应用持续集成/部署的软件流水线（toolchain）。相比复杂的双环模型，Golden Pipeline无疑是一种便于理解和落地的实现方式：
在整体方案中，绿色部分为安全相关的工作内容。与传统SDL不同的是，除了CD后期的安全检测，其它阶段的安全工作通常为开发团队负责或干脆实现了完全自动化。
安全相关的几个关键工具,
1、RASP:
RASP(Runtime Application self-protection)是一种在运行时检测攻击并且进行自我保护的一种技术。其实从从代码设计开始，企业就应当引入运行时应用自我保护（RASP）或者类似的安全设计。与传统WAF不同的是，由于了解应用程序上下文，RASP可以完全掌握应用程序的输入输出，因此它可以根据具体的数据流定制合适的保护机制，从而可以达到非常精确的实时攻击识别和拦截。从国际角度而言，绝大多数AST（Application Security Testing：应用安全测试）厂商都能提供类似的产品，而国内通常将RASP+WAF的方式称为自适应安全，目前只有少数几家厂商提供。
2、AST
AST包括SAST（静态应用安全测试）、DAST（动态应用安全测试）以及IAST（交互式应用安全测试）。通常在完成安全代码复查后，开发人员可以通过git形成版本树。而对于预发布的版本，将会通过CI集成平台自动进行静态代码安全扫描流程（SAST）。目前国际上通用的做法是将SAST与SCA的OSS扫描集成在一起进行，代表厂商为Checkmarx和Blackducks。
3、SCA（第三方代码库扫描）
当CI阶段结束，QA将进行常规的冒烟测试和单元测试，当然有些单元测试会放在CI前完成。由于开源代码库已关联完成，平台可以在这个阶段通过任务调度自动引入第三方代码库扫描（SCA），并自动与权威漏洞库进行关联。
目前这些工具，除国际厂商，少数几家国内厂商也开始有能力提供整体的方案，其中开源网安不仅是工具，而且可以支持从安全需求开始的与敏捷管理工具Jira的集成，使得敏捷开发过程的管理与工程，真正集成在一起，这样更利于安全柔和的集成到现有敏捷团队运作过程中，利于实施落地。而且内置的，安全需求建模、威胁建模，可以替代很多原来只有安全专家才能做的完成的分析任务，符合安全赋能的理念。
04
SDL到DevSecOps落地要注意的主要问题
SDL模型设计之初是用于保护大型产品（例如 Windows和 Microsoft Office）的安全，两个产品都有很长的开发周期。将安全要求集成到敏捷开发方法中，必须将添加到敏捷流程中的 SDL 安全实践进行精简。瀑布模型是全量交付模式，敏捷方法则是一种增量交付模式，因此敏捷方法下仅能对新增或升级的功能执行足够的 SDL 安全实践。其次，需要将 SDL 安全实践拆分成可快速执行的轻量任务。
在落地容易遭遇的问题：
安全性任务不受重视
敏捷方法中，产品中的需求是放在产品待办事项（Product Backlog）列表中，每个迭代Sprint会从PB中根据优先级选择放入本轮迭代需要的需求。
SDL的实践任务可以视为非功能性需求，需要纳入到产品和Sprint 待办事项列表中，并排优先级。在实践中，我们会发现
1、安全测试相对于功能测试来说，漏洞数不定，修复技术方案可大可小，严重的甚至需要进行应用系统重构；
2、安全技术人员的角度看，能够把握安全漏洞的严重程度和可利用性。但是，在业务方面，对于实际可能造成的财产损失以及客户要求无法提出强有力的观点，缺少业务上的反馈形成良性循环。
这2个因素，会导致安全漏洞经常无法及时处理修复。因为，对于敏捷开发来说，是典型的价值驱动，每期交付最高价值的需求。常见的产品版本排期人员是产品经理，需要产品经理的意见，而产品经理主要出发点是业务价值回报，产品经理普遍也缺乏安全知识，排序时难免会排到低优先级。
对现有过程效率的影响
在敏捷方法或者DevOps环境下，对发布流水线的周期是要求尽量短，安全实践及工具的嵌入，增加了流程执行的卡点数量，难免会降低发布周期，为真正柔性嵌入，必须在考量安全性同时，兼顾效率，合理部署安全工具及配置执行方法。例如，通过扫描源代码及二进制文件以发现可能的安全漏洞，但通常SAST花费的时间较长，而增量扫描适合测试更改过的代码，扫描时间快，更加适合持续交付管道。
安全专家的资源不足
虽然，在DevSecOps中强调安全团队与其他角色成员一起对安全负责，但在实际场景中，开发、QA、安全 人员的比例可能是 100:10:1，而在敏捷开发中，需求-设计-开发-测试-部署，几乎是单件流并行的，针对每个user story 安全专家几乎需要在团队现场协同工作。而在其他人员都缺失安全知识和安全经验的情况下，至少每个团队都需要配置一个安全专家，这对于很多公司可能是很难做到的。
因此，安全专家，可能没法专职在一个团队工作，而需要更多考量组织安全意识与文化的培训、赋能团队其他角色成员在工作中内建安全性、让开发和QA团队自己来保证安全。安全过程实际难点主要在前期：安全需求和安全设计阶段，一旦这个阶段安全专家早期参与后，形成可执行的设计规格和安全策略，那么实际研发和QA人员，依赖原有的软件工程方法就可以很好完成。部分的需要较高安全经验和知识的，再由安全专家来支撑完成。
传统安全团队的工作模式与要求不匹配
过去安全团队往往把自己放在审核者的角色上，指出业务系统存在这样那样的问题，应该做这样那样的修改，整改完毕之前不能够部署上线，出问题追责处罚，等等……不论是对于Dev还是Ops而言，Sec都不算是一个友善的角色。这样的定位和心态显然是无法在应用快速迭代的当下保持持续安全的。安全角色，也应该工作前移到需求阶段，与团队其他成员一起，识别安全风险、促进业务与安全目标协调一致、协助安全需求的分解及优先级的协商确定，针对问题给出有效的建议，等等。
实际在RCA2018这次大会中很多厂商提的理念对于DevSecOps的团队是非常适用的，比如CYBERARK提出的“Because Security is a Team Game（因为安全是团队游戏）”和Mcafee提出的“Together is Power（团结就是力量）”。安全团队应该摒弃监控、检测、审核者的心态，而以“请给我讲讲这个系统的业务架构是怎样的”、“当前的运维流程中我们可以怎样合作”“让我来帮助你一起实现这个目标吧”这样的方式来与开发团队和运维团队相处并合作，大家树立共同的目标并为之而努力。
05
结束
安全作为作为软件的一种特性，其本质也是软件质量的范畴。因此，对安全属性的重视，对软件质量管理体系也提出了发展性要求。传统的质量理论，关注，符合客户要求和客户满意度层面，忽略了软件的安全特性。因为这类特性往往客户无法感知也难以明确提出，更多是行业合规性及设计层面的要求。那么随着万物互联的时代的来临，软件也和水、电一样成为基层建筑，那么对安全特性的保障也就变得尤为重要。这时代的大的趋势，希望质量人能抓住这波职业发展红利，因为具备这种能力的专业人员，具有稀缺性和可预期的强需求性。
