作者：开源网安 宋荆汉
百度、腾讯、小米、OPPO似乎今年谈起开发安全，不说自己从传统SDL转型到DevSecOps就不能称为创新。
的确，DevSecOps越来越受到周期短、迭代快的互联网业务的欢迎，也成为安全界的流行趋势。但在笔者看来，“正如喜茶好还是普洱好”一样，将DevSecOps和SDL二元化盲目对立起来也是不成熟的想法。软件开发过程的目标是多样性的，有些是质量、人员效率优先，有些是速度优先，也有些是安全优先，由此可见目标决定过程。因此，需要根据不同的目标来有机整合相关的实践以实现目标。
作为专业人员，我们必须从更高阶与成熟的软件工程管理角度考虑如何做好软件安全开发。国际标准最广泛采用的基于WSR软系统工程方法论告诉我们：要解决组织的问题需要基于战略方向，从人、流程、技术与工具、方法等多个维度系统化思考。工具很重要，但也不是解决问题的万能药，用什么工具，不是看是不是技术先进，而是在战略指导下，从成本效益角度综合考虑的结果。
SDL与DevSecOps对比又进入了历史误区
“DevSecOps”被评为年度网络安全行业热点词汇，然而历史似乎总在重演。正如当年在软件工程领域爆发“CMMI与敏捷开发”的争论一样，现在安全领域出现了类似的争议。
现在网络上很多文章，开始宣传DevSecOps优于SDL，甚至出现SDL已死的论调。其实SDL是一种安全开发模型，其对应的所谓实践，实际就是模型的要求，用什么方法满足这个要求，组织可以根据具体情况决定，SDL目前实际已经涵盖DevSecOps。而DevOps是软件敏捷开发方法的发展，DevSecOps是基于DevOps的软件安全开发方法。因此，如果作类比，SDL相当于CMMI，而DevSecOps相当于敏捷开发方法，总而言之：
- SDL是一种模型，DevSecOps是一种具体的方法，两者相辅相成，一起进步，而不是对立的；
- SDL本身也在演进中，并已经涵盖了DevSecOps方法；
- 解决安全运维一体化的并非只有DevSecOps一种选择，S-SDLC也行；
- DevSecOps与传统瀑布模式的S-SDLC方法相比，也没有优劣之说，只是解决问题场景不同，DevSecOps也不能替代瀑布式S-SDLC。
从软件工程学的角度看软件安全开发
软件安全开发的本质目标，是开发出安全的软件。“安全”即保密性、可用性、完整性。基于软件工程管理“过程控制、预防为主”的原则，应该在软件开发过程中内建，而不是“亡羊补牢”：先开发、再检验、最后修补。
根据《GB/T 11457-2006 软件工程术语》的定义，“软件开发过程（2.1491）”是把用户要求转化为软件产品的过程，此过程包括：把用户要求转换为软件需求，把软件需求转化为设计，用代码来实现设计，对代码进行测试，有时包括安装和验收。因此，软件开发生命周期（SDLC）通常定义为：需求、设计、实现、验证、发布、运维6个生命周期阶段。
软件开发的过程阶段可以遵循不同的“软件开发生命周期模型”，也被称为“软件开发过程模型”。每个过程模型都遵循其在软件开发生命周期所独有的一系列阶段，以确保软件开发成功。不同的软件开发生命周期类型，本质是为了应对不同问题域。目前行业最主流的SDLC是瀑布与敏捷，而选择哪一种SDLC开发软件，需要根据不同场景的特征。见下表。
为了实现软件的安全特性，需要在软件开发生命周期的各阶段融入安全实践过程，以保障开发过程能产出安全的软件，也就构成了安全软件开发生命周期S-SDLC。因此，在瀑布型SDLC或敏捷型SDLC融入相应的安全实践过程就可以衍生出安全的瀑布开发生命周期与安全的敏捷开发生命周期。因此，S-SDLC实际是泛指安全软件开发生命周期，可以是瀑布模式，也可以是敏捷模式。
SDL的诞生和演进
微软在21世纪初期的软件产品开发实践中，就意识到无法通过技术层面彻底解决软件面临的安全风险。因此，微软尝试从流程和管理的角度解决这个问题，并探索在各软件开发环节加入安全过程、把控安全风险，确保每个环节交付到下一环节的交付物都安全可控。于是，微软产生了“SDL软件安全开发周期（Security Development Lifecycle）”。
2004年，微软的SDL安全开发生命周期模型（见下图）作为软件开发的强制策略开始在公司实行。该模型帮助开发人员构建高安全性的软件，并取得了巨大成功。应该说早期的这个模型，确实没有将运维层面的实践纳入该模型。
早期的微软SDL
2019年，随着移动、云计算、大数据、物联网、人工智能和其他新技术的兴起，微软对SDL进行调整，使得无论使用经典的瀑布法或更新的敏捷方法（如DevSecOps），在开发的每个阶段提高软件应用程序的安全性。其中，适用于瀑布开发场景的SDL包括12个安全开发实践，适用于敏捷开发场景的SDL包括8个安全开发实践。
适用于瀑布开发场景的新版微软SDL
适用于敏捷开发场景的新版微软SDL
新版微软SDL具有以下特征：
- 不再强调在哪个软件开发阶段执行哪个实践，这使得模型能适用更广泛的SDLC模式；
- 重视软件开发过程中的自动化安全检测，包含：静态安全测试、动态安全测试、渗透测试；
- 不再关注软件的发布过程；
- 加强开发过程中对有关人员、工具和组件的管理。
互联网技术与应用创新推动敏捷开发向DevOps演进
随着互联网时代的到来，信息得以快速传递，并呈现出跨界融合、创新驱动、重塑结构、尊重人性、开放生态、连接一切等意识形态，对软件开发管理带来前所未有的冲击。互联网行业的软件公司面临更加复杂和快节奏的外部环境，之前在瀑布模型场景的假设被打破。创新业务场景多、客户需求变化快，使得现有经验积累很难借鉴。
需要在成本可控情况下，不断向市场交付、验证、反馈、调整以找到准确的方向，此时准度比精度更重要，做错方向的成本远高于迭代修正的成本，更快的迭代速度可以获得更快的反馈、更灵活调整，只有这样更利于赢得市场竞争，速度成为首要考虑的因素。因此，拥抱变化、固定成本下迭代增量交付的敏捷方法应运而生。但由于敏捷方法应对的是快速变化的外部环境与不确定的问题，则更加依赖团队的能力自组织、自适应外部变化，其存在的局限包括：
- 如果迭代成本极高，这个方法就无法实施；
- 对团队成员的综合素质和能力有较高门槛，很难适应大规模的软件开发场景，因为一旦团队规模变大，就必然需要层级管理模式；
- 由于拥抱变化，增加了短期的灵活性，这样操作降低过程风险，则失去了对最终成本的预见性和可控性。
敏捷方法本身也在演进，开始敏捷方法主要是产品开发领域。随着云计算应用的兴起，软件即服务也意味着为真正敏捷的交付软件价值给客户，必须将敏捷扩展至运维端，才能实现真正的端到端的价值流动和及时客户反馈、快速迭代，持续集成、部署的自动化是这一方法体系的核心能力！我们称之为DevOps。
持续开发、持续部署
下图是Exin DevOps认证提出的知识体系。大家会发现，但其SDLC本质并没有变化，采用敏捷方法进行管理，持续交付是其核心实践。
Exin DevOps知识体系图
DevOps催生DevSecOps
既然有了DevOps，那么DevOps场景下，如何实现安全开发呢？于是安全界提出DevSecOps的方法。
DevSecOps逻辑图
业内首次对该模型及配套解决方案进行详细的分析，核心理念为：安全是整个IT团队（包括开发、测试、运维及安全团队）所有成员的责任，需要贯穿整个业务生命周期的每一个环节。每个人都对安全负责，安全工作前置，柔和嵌入现有开发流程体系。
RSA2018大会上出现的一个热词“Golden Pipeline（黄金管道）”，特指一套通过稳定的、可预期的、安全的方式自动化地进行应用持续集成/部署的软件流水线。相比复杂的双环模型，Golden Pipeline无疑是一种便于理解和落地的实现方式：
CI/CD逻辑图
在整体方案中，绿色部分为安全相关的工作内容。与传统SDL不同的是，除了CD后期的安全检测，其它阶段的安全工作通常为开发团队负责或干脆实现了完全自动化。主要是将部分测试相关的安全实践通过工具化实现了自动化。
正确认识瀑布模式的S-SDLC与DevSecOps
1.敏捷模式是特种兵作战，瀑布模式是集团军作战
现在网上经常被人拿来与DevSecOps做对比的SDL，主要被认为SDL代表的是以瀑布模式的S-SDLC，而当时SDL主要基于微软的软件产品开发场景。我们知道微软此前产品主要是系统级软件或者工具软件，开发周期相对较长、需求范围相对明确，而且变化相对可控并不会太频繁。同时，系统复杂性和团队规模很大，每次软件系统进行迭代和返工的成本极高，必须保证每个阶段交付的正确性。据说，微软为此当时软件开发工程师与软件测试工程师的配比为1:1甚至1:2，而且这类软件，并不需要密集的部署和交付，在开发与运维之间是有明显阶段的。DevOps开发运维一体化，根本没有必要。这种场景下，是比较适合采用瀑布模式的。由于整个项目周期较长，软件质量是首要考虑的因素，实施安全实践对项目的效率和进度影响并不明显。因此，以SDL为指导模型的瀑布模式的S-SDLC方法可以很好的在这样的场景落地，并取得实际的成功。
如果说敏捷是特种兵作战模式强调灵活应变，那么瀑布模式就是集团军作战模式，要求周密的计划和控制。全球95%的500强企业采用的IPD产品开发体系，其生命周期模型也主要是采用的瀑布开发模式。
2.全量与增量的区别是人员和时间的投入产出比
从实际情况来看，无论是瀑布模式还是敏捷模式，在需求价值这个颗粒度上的生命周期其实是一致的，只是瀑布模式是全量而敏捷模式是迭代增量。但是对于安全实践的落实却造成了影响，见下图。
全量与增量的区别逻辑图
假定我们同时有10条需求，如果按瀑布全量交付方式，安全实践只需要一次集中处理10条，再转给下一个环节。这样对团队的人员效率是最优的。但在增量交付时，我们会发现，安全实践同样要处理10条需求，但必须要在不确定的时间点去完成。价值流动效率最优，但人员效率就不高了。如果在DevSecOps环境下，安全实践由安全人员来支撑，理论上需要的安全团队会更为庞大，这在许多公司显然是不可接受的。
另外，由于每次交付的周期变短了，速度成为关键制胜因素，任何对速度的影响都会对业务造成明显的阻碍。速度与安全都是业务的属性，都需要投入成本，速度与安全的“冲突”，本质是对各维度投入产出的综合考量。要实现鱼与熊掌兼得，除了在更高一级维度平衡外，唯有通过自动化工具才能缓解但并不能完全消除。
如果从开发安全软件的核心要素考量，其实本身并不在于全量交付还是增量交付，而在于在每个给客户的可交付增量的开发各阶段是否有融入合适的安全实践。举个例子，如果你没有对需求进行安全需求的识别和分解，后面设计与测试工具再快，同样无法实现预期的安全目标。同样，没有进行安全设计，后面测试做的再好、再快，也无法有效实现预期安全目标。
DevSecOps增量持续交付，具体微观到每个需求单件流，也是一个典型的瀑布，也可以应用SDL（瀑布模式），因为SDL提出的安全实践要求依然适用，只是实现这些要求的具体方法需要根据开发目标做调整。
3.DevSecOps不是唯一的选择
DevOps强调相对之前敏捷开发方法，重点解决了开发与运维的冲突。明智的解决方法不外乎三点：
- 相互理解各自的利益关注点；
- 在更高一级统一优先级；
- 通过自动化和文化理念解决二者的冲突。
DevOps解决冲突实际是采用的第3种方法，但第2中方法同样可以解决问题。
Netflix（奈飞）的专家在一次DevOps大会发言，值得我们思考和借鉴。Netflix的业务场景需要面临每天数千次的变化与上线压力，绝对非常适合采用DevOps，而Netflix的软件开发实践绝对是业界的标杆，但他们专家却在报告中多次强调“Netflix不关注DevOps，因为通过公司文化、过程、技术工具、信任，我们已经避免了开发和运维的冲突。没有冲突，也就不需要DevOps”。
开发乐于创新、变革，而运维则希望持续稳定。如果不在更高一级的公司领导层面确定优先级的话，必然导致僵局。奈飞选择了创新，他们不追求完美的7×24小时系统的可靠，愿意承受一些招致可靠性风险的问题也要鼓励产品的创新优化。这个共识渗透了开发团队和运维团队，二者的冲突根本就没有机会造成伤害。因此，也就不需要DevOps了，自然也就不需要DevSecOps了。
正在导入DevOps的组织应该借鉴Netflix的经验：从组织战略层面平衡好产品创新优化和产品稳定运维的矛盾；最大化实现测试自动化；全面形成责任感文化。而不是糊里糊涂推动DevOps以及DevSecOps运动。你可以把马带到河边，但不能逼着它们饮水。你可以去说服开发和运维合力同心，但组织文化不改，仅仅变化工具不会有实质的改进。
开发运维一体化的安全开发，除了DevSecOps，企业通过整合S-SDLC、战略文化、组织流程、工具方法，也同样可以找到更适合自己的方法，Netflix给我们提供一个很好的案例。
最后的一些建议
如果要粗略给企业建议是用瀑布式S-SDLC方法（下面简称“瀑布模式”）还是DevSecOps的话，行业较为普遍的做法可供借鉴：
- 需求范围明确的软件开发用瀑布模式更合适，即使是互联网软件也是如此。比如：大家可能觉得游戏开发往往采用敏捷模式，但大家参加一些行业分享大会时会发现，有很多大型游戏开发如果在需求明确的情况下，企业依然会采用瀑布模式；
- 迭代修复成本巨大的软件开发过程用瀑布式更合适。比如，与硬件结合的专用系统软件底层软件，一旦有哪个部分出现考虑不周问题，将导致系统推翻重来、前期成本投入浪费的情况；
- 对于IoT类智能终端软硬件结合产品，通常会混合采用瀑布模式与DevSecOps。相对确定的嵌入式系统部分软件采用SDL，相对用户端的云或者APP可以采用DevSecOps；
- 无法对系统拆分成可交付增量的，只能用瀑布模式；
- 需求范围经常变化，面临密集部署的场景用DevSecOps更合适；
- 需求不确定，但开发与部署有明显阶段区别，很难持续端到端价值流动的，采用通常的敏捷方法就好，也没必要采用DevSecOps。
所以，如果从实际应用场景来看，SDL主要用于指导企业研发管理体系的完善和融合，而具体瀑布模式S-SDLC和DevSecOps是解决问题域的方法，在企业策略指导下可以选择性采用。
SDL与DevSecOps有各自的适用场景，对软件安全开发的发展都有着重要的贡献。特别是进入产业互联时代，工业4.0、基础工业与系统软件、大量IoT终端设备等都会大量涌现，均会给SDL与DevSecOps带来更广阔的应用场景。