摘要: 作者：开源网安 宋荆汉 百度、腾讯、小米、OPPO似乎今年谈起开发安全，不说自己从传统SDL转型到DevSecOps就不能称为创新。 的确，DevSecOps越来越受到周期短、迭代快的互联网业务的欢迎，也成为安全界的流行趋势。但在笔者看来，“正如喜茶好还是普...
百度、腾讯、小米、OPPO似乎今年谈起开发安全，不说自己从传统SDL转型到DevSecOps就不能称为创新。
的确，DevSecOps越来越受到周期短、迭代快的互联网业务的欢迎，也成为安全界的流行趋势。但在笔者看来，“正如喜茶好还是普洱好”一样，将DevSecOps和SDL二元化盲目对立起来也是不成熟的想法。软件开发过程的目标是多样性的，有些是质量、人员效率优先，有些是速度优先，也有些是安全优先，由此可见目标决定过程。因此，需要根据不同的目标来有机整合相关的实践以实现目标。
作为专业人员，我们必须从更高阶与成熟的软件工程管理角度考虑如何做好软件安全开发。国际标准最广泛采用的基于WSR软系统工程方法论告诉我们：要解决组织的问题需要基于战略方向，从人、流程、技术与工具、方法等多个维度系统化思考。工具很重要，但也不是解决问题的万能药，用什么工具，不是看是不是技术先进，而是在战略指导下，从成本效益角度综合考虑的结果。
现在网络上很多文章，开始宣传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开发软件，需要根据不同场景的特征。见下表。
2004年，微软的SDL安全开发生命周期模型（见下图）作为软件开发的强制策略开始在公司实行。该模型帮助开发人员构建高安全性的软件，并取得了巨大成功。应该说早期的这个模型，确实没有将运维层面的实践纳入该模型。
- 不再强调在哪个软件开发阶段执行哪个实践，这使得模型能适用更广泛的SDLC模式；
- 重视软件开发过程中的自动化安全检测，包含：静态安全测试、动态安全测试、渗透测试；
- 不再关注软件的发布过程；
- 加强开发过程中对有关人员、工具和组件的管理。
需要在成本可控情况下，不断向市场交付、验证、反馈、调整以找到准确的方向，此时准度比精度更重要，做错方向的成本远高于迭代修正的成本，更快的迭代速度可以获得更快的反馈、更灵活调整，只有这样更利于赢得市场竞争，速度成为首要考虑的因素。因此，拥抱变化、固定成本下迭代增量交付的敏捷方法应运而生。但由于敏捷方法应对的是快速变化的外部环境与不确定的问题，则更加依赖团队的能力自组织、自适应外部变化，其存在的局限包括：
- 如果迭代成本极高，这个方法就无法实施；
- 对团队成员的综合素质和能力有较高门槛，很难适应大规模的软件开发场景，因为一旦团队规模变大，就必然需要层级管理模式；
- 由于拥抱变化，增加了短期的灵活性，这样操作降低过程风险，则失去了对最终成本的预见性和可控性。
敏捷方法本身也在演进，开始敏捷方法主要是产品开发领域。随着云计算应用的兴起，软件即服务也意味着为真正敏捷的交付软件价值给客户，必须将敏捷扩展至运维端，才能实现真正的端到端的价值流动和及时客户反馈、快速迭代，持续集成、部署的自动化是这一方法体系的核心能力！我们称之为DevOps。
RSA2018大会上出现的一个热词“Golden Pipeline（黄金管道）”，特指一套通过稳定的、可预期的、安全的方式自动化地进行应用持续集成/部署的软件流水线。相比复杂的双环模型，Golden Pipeline无疑是一种便于理解和落地的实现方式：
如果说敏捷是特种兵作战模式强调灵活应变，那么瀑布模式就是集团军作战模式，要求周密的计划和控制。全球95%的500强企业采用的IPD产品开发体系，其生命周期模型也主要是采用的瀑布开发模式。
另外，由于每次交付的周期变短了，速度成为关键制胜因素，任何对速度的影响都会对业务造成明显的阻碍。速度与安全都是业务的属性，都需要投入成本，速度与安全的“冲突”，本质是对各维度投入产出的综合考量。要实现鱼与熊掌兼得，除了在更高一级维度平衡外，唯有通过自动化工具才能缓解但并不能完全消除。
如果从开发安全软件的核心要素考量，其实本身并不在于全量交付还是增量交付，而在于在每个给客户的可交付增量的开发各阶段是否有融入合适的安全实践。举个例子，如果你没有对需求进行安全需求的识别和分解，后面设计与测试工具再快，同样无法实现预期的安全目标。同样，没有进行安全设计，后面测试做的再好、再快，也无法有效实现预期安全目标。
DevSecOps增量持续交付，具体微观到每个需求单件流，也是一个典型的瀑布，也可以应用SDL（瀑布模式），因为SDL提出的安全实践要求依然适用，只是实现这些要求的具体方法需要根据开发目标做调整。
- 相互理解各自的利益关注点；
- 在更高一级统一优先级；
- 通过自动化和文化理念解决二者的冲突。
DevOps解决冲突实际是采用的第3种方法，但第2中方法同样可以解决问题。
Netflix（奈飞）的专家在一次DevOps大会发言，值得我们思考和借鉴。Netflix的业务场景需要面临每天数千次的变化与上线压力，绝对非常适合采用DevOps，而Netflix的软件开发实践绝对是业界的标杆，但他们专家却在报告中多次强调“Netflix不关注DevOps，因为通过公司文化、过程、技术工具、信任，我们已经避免了开发和运维的冲突。没有冲突，也就不需要DevOps”。
开发乐于创新、变革，而运维则希望持续稳定。如果不在更高一级的公司领导层面确定优先级的话，必然导致僵局。奈飞选择了创新，他们不追求完美的7×24小时系统的可靠，愿意承受一些招致可靠性风险的问题也要鼓励产品的创新优化。这个共识渗透了开发团队和运维团队，二者的冲突根本就没有机会造成伤害。因此，也就不需要DevOps了，自然也就不需要DevSecOps了。
正在导入DevOps的组织应该借鉴Netflix的经验：从组织战略层面平衡好产品创新优化和产品稳定运维的矛盾；最大化实现测试自动化；全面形成责任感文化。而不是糊里糊涂推动DevOps以及DevSecOps运动。你可以把马带到河边，但不能逼着它们饮水。你可以去说服开发和运维合力同心，但组织文化不改，仅仅变化工具不会有实质的改进。
开发运维一体化的安全开发，除了DevSecOps，企业通过整合S-SDLC、战略文化、组织流程、工具方法，也同样可以找到更适合自己的方法，Netflix给我们提供一个很好的案例。
- 需求范围明确的软件开发用瀑布模式更合适，即使是互联网软件也是如此。比如：大家可能觉得游戏开发往往采用敏捷模式，但大家参加一些行业分享大会时会发现，有很多大型游戏开发如果在需求明确的情况下，企业依然会采用瀑布模式；
- 迭代修复成本巨大的软件开发过程用瀑布式更合适。比如，与硬件结合的专用系统软件底层软件，一旦有哪个部分出现考虑不周问题，将导致系统推翻重来、前期成本投入浪费的情况；
- 对于IoT类智能终端软硬件结合产品，通常会混合采用瀑布模式与DevSecOps。相对确定的嵌入式系统部分软件采用SDL，相对用户端的云或者APP可以采用DevSecOps；
- 无法对系统拆分成可交付增量的，只能用瀑布模式；
- 需求范围经常变化，面临密集部署的场景用DevSecOps更合适；
- 需求不确定，但开发与部署有明显阶段区别，很难持续端到端价值流动的，采用通常的敏捷方法就好，也没必要采用DevSecOps。
所以，如果从实际应用场景来看，SDL主要用于指导企业研发管理体系的完善和融合，而具体瀑布模式S-SDLC和DevSecOps是解决问题域的方法，在企业策略指导下可以选择性采用。
SDL与DevSecOps有各自的适用场景，对软件安全开发的发展都有着重要的贡献。特别是进入产业互联时代，工业4.0、基础工业与系统软件、大量IoT终端设备等都会大量涌现，均会给SDL与DevSecOps带来更广阔的应用场景。
