开源生命周期管理

​ 开源软件的生命周期管理，从本质上来说，和开源软件使用规范中，所陈述的开源软件供应链管理有一定的区别。开源软件供应链管理更多讲述的是开源软件本身的引入、使用以及维护，这是开源软件本身端到端的流程。

​ 但是开源软件的生命周期管理，跳出了开源软件本身的角度看问题。众所周知，开源软件使用是集成在产品代码当中，开源软件跟产品息息相关，产品的生命周期问题会导致开源软件的生命周期问题，所以这门课程阐述的是：如何从产品角度看开源软件的生命周期管理。

一、软件工程课程框架

在企业做产品管理阶段遇到复杂的软件工程场景下，如何做好开源的管理？

​ 单看开源软件的一些风险，比如安全、合规等，只要有开源的基础意识，包括开源管理能力、工具等，通过组织就能解决该问题，或者消减风险；但如果产品具有各个不同的模块，甚至不同的组件，由厂商整体打包后向客户分发产品或提供服务，尤其在制造业或金融业，具有成套硬件和软件，包括由云服务仪器提供的这类产品，以上这种情况中产生的开源安全和合规问题，会不可避免受到不同部件的限制，比如硬件从生产到交付客户使用，但最后却无法工作，或者过时——已经走出生命周期的过程了；硬件的使用周期很长，一台电脑可能十年都不换，但运行在电脑内的操作系统，比如 Windows 7 却早已退出其生命周期的时间，由此可见，软件的生命周期比硬件的生命周期时间要短的多；而建立在操作系统之上的应用软件（Office、微信等），在新版本覆盖掉旧版本后，那么有个问题就产生了：上层软件平台、软件组件都是如何修复的呢？软件平台和软件应用，对软件维护的要求，包括运行时间的要求、投入的人力资源都不一样（因为生命周期不一样）。因此如何协同处理相关安全漏洞问题以及合规问题，就是开展全生命周期需要解决的问题。

​ 在现代化的软件开发过程中，怎样通过软件的配置管理，统一化管理开源、产品组件平台等，用相应的软件开发工程体系（比如构建工程、测试工程、发布工程）解决问题，就是开源的生命周期管理。

1、现代化软件开发生命周期管理

从生命周期角度，探讨如何持续构建高安全产品的研发能力

① Why：从客户问题、产业现状、企业竞争力三个视角看生命周期面临的挑战，转变对生命周期的意识。

② What：优选解决优生问题，生命周期解决死的问题。从合同/产品/单板/软件版本/平台/工具/开源软件各层识别挑战。

③ How：以某产品实际面临问题为实战，探讨如何做生命周期管理，谁来做，怎么做？

2、配置管理

了解配置管理的 why、what、how。

① Why：配置管理对于产品的意义？

② What：配置管理存在的问题是什么，产生的原因是什么？

③ How：解决这些问题的方法是什么？

3、构建工程

1）了解构建工具的管理要求、业界高阶构建工具的主要功能与优劣、构建环境封闭的要求

2）实战演练：通过对 demo 系统的实操加深理解

二、认识软件版本生命周期所面临的挑战

1、发现身边的安全隐患

​ 在软件开发过程中，不论是使用 Bugzilla，还是使用开源社区内的 issue、PR 来进行漏洞跟踪，总之每天都会收到软件内爆发的漏洞，然后再给漏洞打上补丁，这已经是一个常规操作。如果只是构建单一的软件，那每天可能只有 1~2 个漏洞，但对于产品来说，产品里会有各种各样组合性软件，一天收到几百个漏洞单是件很正常的事情。如果你是项目经理，或者软件开发经理，明天产品发布，突然收到 100 个漏洞单，在这种情况下，你会怎么处理？

• 先发布？
• 发布之后怎么解决或者是需不需要解决？
• 客户是否认可？

​ 如果只是站在我们自己的角度上看待这个问题，可能第一时间就想把这 100 个漏洞找出来，一个个打上补丁。理论上需要这样做，因为漏洞第一时间肯定是要响应，但是否考虑过一个问题：这个 100 个软件时分布在哪些组件/应用软件里？可能这个 APP 有 50 个开源软件有漏洞，另外 50 个可能在操作系统里，比如安卓服务里有20 个漏洞，手机里统一安装这种服务，交付客户之后，还是有 20 个漏洞，甚至可能不在安卓系统里，而是在硬件里。因此这 100 个漏洞修复，如何满足第一时间、安全应急、是否可修复以及是否能落地等要求，就需要通过生命周期管理和软件工程来解决。

2、客户需要的是持续、系统的安全

结合多年与客户交流总结的软件工程问题，发现客户更关心的一些方面在于：

​ 首先就是产品代码质量问题，包含是否容易产生漏洞？来源是否可靠？使用的软件是从官网下载还是第三方下载？是否被别人做了后门等问题。

​ 其次，代码是否遵循编码规范问题，有些企业聘用一些员工，这些员工可能有编码经验，但这并不代表这个员工的编码水平很高/代码写得好，因此很多公司相应会有些编码规范，以降低代码里的安全问题，并且要求开发者写代码时需遵守这些规范，比如不能有魔鬼数字、写代码要空行空格、变量需写清楚具体含义等。

再次就是一些会扩大攻击面的问题：

1）片段使用：当我们引用其他人写的软件的一些片段，这看似稀疏平常的事情，但我们不知道是，拷贝的这份代码里面可能有个很大的漏洞，而因为我们没有这个软件的具体版本信息及来源信息，导致在做代码检查时，并未能察觉出这个漏洞。

2）老软件：不论是开源软件，还是自己写的软件，所有软件更新迭代的速度都非常快，基本至少三个月就会更新一个版本，新版本一定会修补之前老版本的漏洞或者安全问题，如果一直使用老软件版本，会使得漏洞/安全问题像滚雪球一样越滚越大，直到无法修复。

3）一个开源软件多版本：比如使用一个开源软件，不仅使用一个版本，还可能使用多个版本——可能是因为这个版本有兼容性问题，为了快点上线，顾不及兼容性问题，所以使用多个版本，总之能运行就可以。而这样会导致什么问题呢？每个版本都有各自不同的许可证，有各自不同的安全问题和漏洞，如果不做版本的归一，而是放任自由多版本，鱼龙混杂，当这个多版本软件经过 4~5 年的售卖，雪球越滚越大，最后导致信息无法跟踪，不清楚这个版本由谁引入，又是谁对这个版本负责，软件管理成了另一大难题。

4）多组件产生多副本：比如一个片段引用，a 组件引用了，b 组件也引用了，那 a、b 组件如何协同修复片段漏洞？所以即使能识别片段代码内有漏洞风险，但因为片段集成的地方太多，也会导致最后完全无法跟踪漏洞并进行修复；

5）多组件产生多副本：片段本身有很多副本，片段集成之后的软件也不可能是单一的代码段，还可能集成了其他软件（一代软件），如果主软件有一个版本，一代软件有多个版本，一代软件的一代软件又有多个副本，最后形成软件灾难，变成难以维护的软件垃圾，无法用手段来进行管理，这时就很容易受到攻击。

​ 这些也是在软件开发过程中会面临的很现实的问题：不论软件如何开发，越开发攻击面越大。因此站在开发者，或者企业的供给侧角度来看问题，需要做好以下这些方面：

​ ① 用的软件是真的、可靠的，代码是安全的，尽量避免扩大黑客的攻击面，保障系统整体上是安全的；

​ ② 但这样还不够，客户看到的可能不是这些问题，客户更希望拿到的产品，从生产到发布再到最后生命周期 结束退出应用，整个过程都是有人持续维护，也不是单一的组件问题，而是整体一套系统；

​ ③ 及时跟踪开源软件漏洞，确保漏洞真的被修改，而且是改的很完全；

​ ④ 以及环节出现漏洞时，应有一个能够及时响应的机制，快速定位到漏洞，在客户发生之前解决问题。

3、产业现状：开源社区既是创新沃土，又易被黑客利用

​ 开源软件缩短了产品上市时间、提升了创新能力，大家能用很少的人力、资源以及时间，把新技术移植到产品中，使产品获得收益的时间越来越快，收益越来越多，但也因为开源中的代码是透明且易获取，当我们在研究代码如何编写以及使用时，黑客同时也在研究如何攻破，因此开源社区和开源软件都具有两面性：既是创新沃土，又易被黑客利用。

​ 根据统计，整个信息行业大约有80%的代码都使用了开源软件，一旦爆发漏洞，像 OpenSSL 这种高危漏洞，系统就很容易被攻破。所以开源软件的安全观需要上升到整个产品的安全观，这也是开源软件的生命周期管理会上升到产品的生命周期管理这个维度的原因。

1）开源社区是创新沃土，广泛应用于产品

​ 在云计算领域，大约 80% 甚至 90% 的软件都是开源软件，由此可见，基于云计算构建的金融业、制造业、科技行业等，所有的服务已经被开源软件所包围，一旦开源软件被大量引入系统之后，经过长期的开发，开源的硬件、软件、操作系统、组件以及 APP 等技术栈都会被开源软件所取代，这种情况下，不得不从整个生命周期和整个软件栈的角度来看软件的风险。

2）开源的漏洞易被黑客利用，漏洞一旦公开必须快速在产品修复

​ 很多开源社区非常健康、欣欣向荣，一旦出现漏洞立马有人进行修复，同样也有些开源社区——技术不错、idea也很好，但这个开源软件的维护者/贡献者人数特别少，寥寥无几，在这样的社区里提的问题，可能需要等上一个星期甚至一个月，才会有人答复，当爆发严重的漏洞时，若无人及时修复，有些黑客可能就会利用这个漏洞来做些事情，因此如果使用该社区的技术，可能需要长一个心眼。

​ 当年 OpenSSL 这个心脏滴血漏洞还未爆发时，根据之前的一些统计数据，大约 70% 的 CC 认证功能及系统、80% 的网络加密传输系统等都在使用 OpenSSL 这个软件，如此大的使用率让大家都认为该社区非常安全健康，开发者的维护应该很积极，而事实上，在这个心脏滴血漏洞爆发前夜，社区的维护者，包括项目负责人，因为没有资金支持运作，正在讨论这个社区是否还能继续下去、是否需要解散的问题，导致社区爆发漏洞之后，长时间无人修复，仅能依赖于企业自发的维护、拯救使用 OpenSSL 的系统，最后大量用户信息被泄露，产生了巨大的经济损失，为业界敲响了警钟。

​ 而大家对这事的认知仅仅停留在：单一把 OpenSSL 这个软件录入修复，软件有漏洞，修复就安全了，然而到 2021 年，Log4j 同样爆发安全漏洞时，造成的影响远不止 OpenSSL 爆发时只是单一修复系统的问题，这个 Log4j 从爆发到现在 2022 年，它的影响仍然没有消去，现在还有很多云服务在扫描，管理员连 Log4j 的漏洞在哪都没有找到，这是什么原因呢？因为云服务在大规模使用开源软件之后，经过日积月累的开发，整个软件栈，不论是犄角旮旯，还是肉眼可见的能接触到的应用，都被开源软件占据，这个漏洞的影响方面就不止原来的那一小块部分，它会贯穿整个产品的生命周期。

4、企业竞争力与现代软件开发的核心矛盾

1）分与合的矛盾

问题：把所有的安全、合规问题都解决了，但同时需要花大量的精力、时间和人力去维护、修复，也因此没有时间、人力去做竞争力，那这个问题怎么解决呢？这就是现代软件开发当中的一个核心的矛盾——分与合的矛盾。

① 竞争力

​ 企业内部使用开源软件为何能具备竞争力？

​ 开源软件可以改变交付方式。以前大家做软件开发，需要自己一段一段进行编码，而现在只需要集成某些能力强的开源软件，就能包含这一块的特性功能，比如 k8s、OpenStack，这是一个全功能的开发软件，围绕操作系统或者镜像管理，包括容器管理等这部分的事情都不再需要我们去操心，他们都能帮我们解决，这时我们组件的交付方式变成黑盒模式——不需要关心里面的内容，只需要关心是否实现这个功能，能用接口调用出来，那么就可以交付了。

​ 因此企业内部分工，以组件方式交付产品，能大幅提升产品线质量/效率/竞争力。

② 挑战

​ 正因为是黑盒，我们不知道内部究竟有些什么，所以可能产生以下一些挑战：

• 不归一：老组件一直在网使用，导致单产品同时使用一款软件的不同版本
• 版本老：考虑到稳定性因素，部件年老龄化，采用延长维保覆盖产品生命周期
• 多副本：基于开源修改，片段代码散落在自研代码中 这就是企业竞争力与现代软件开发的核心矛盾之一。

2）稳定与升级的矛盾

① 竞争力

​ 发布产品前，需要保证产品能够稳定、可靠地运行，尤其在一些国计民生行业，比如电信、能源、交通等行业，稳定性和可靠性可能是这些企业赖以生存的竞争力。

​ 修复漏洞可能有几种方法，要么将软件的版本进行升级，从头开始升级，操作系统到应用，甚至硬件的漏洞也进行修复，全部升级下来，就会产生一个问题——升级可能需要跨部门协作，比如硬件部门、软件部门、操作系统部门、开发部门等都得协调，那效率如何进行保证？如果效率不能进行保证，就会选择不升级而只是打补丁，还是用着原来稳定的版本，把这个漏洞继续留着，后面再去解决。如果从头进行升级，同时考虑到兼容性问题，那这个成本会变得非常高，站在生命周期角度考虑，产品经理一定会犯难：升级还是不升级？如果不升级，老版本稳定，不一定会被攻破，而一升级整个架构可能都会改变。

​ 因此当我们频繁地修复漏洞、升级组件、升级软件等，甚至解决不了某些漏洞时选择绕开，这些问题都会给整个系统带来很大的不确定性，从而影响软件的稳定性和可靠性。这也是为何现在很多客户或者软件企业，都不愿意升级那些老旧组件、不愿意升级产品。

② 挑战：升级新版本才能规避漏洞

​ 那怎么办？是否可以不升级，承担风险即可？实际上是不行的，如果不升级或者部分升级，那么这个漏洞就会像滚雪球一样，越滚越大就会出现前面所述情况：整套系统可能会出现，开源版本大概十多个，OpenSSL 的版本也有十多个，有些团队认为升级很简单，比如 OpenSSL 升级到 2.0，但有些团队，人力资源比较少，或者为了稳定不进行升级，在日积月累中，整套系统就会遍布开源的版本，未来黑客拿到开源软件的漏洞清单，因为整套系统里面所有开源软件版本都有，只要在任何开源软件随便找一个漏洞，就能攻破，这就是前面所述：一旦不从生命周期端到端考虑产品的漏洞修复，就会导致攻击面会被扩大。

建议：竞争力跟产品安全、产品合规是一个严峻的挑战。要解决攻击面变大的问题，需要从生命周期的端到端看问题。

例如，某个公司，当产品出现问题时，应该如何解决呢？

​ 第一层，现网上发生了一个漏洞，需要及时修补。

​ 第二层需要审视合同，在与很多企业进行沟通时发现，他们只会跟客户说：“把这个 APP 的问题解决掉就可以了，其他事情不解决。”这说明行业基本就是这样一个共识，或者说是潜规则，但在合同里没有表明清楚，合同里写的是需要对这个系统的所有安全问题进行负责，那客户就会站出来说，“你只是把这个 APP 的问题解决了，并没有解决操作系统的问题，那下次安装 APP 又会出现这个问题。” 而合同内约束的是某某漏洞解决的责任。

​ 第三层，如果漏洞解决责任是一揽子工程，不仅包括 APP，还包括操作系统，甚至包括硬件，这时就不能简单去看现网的问题，还需要回到整个产品的配置中去，看 SBOM，看信息树，到底产品里挂接了多少个平台、组件、硬件，而这些硬件平台组件又分别是哪些部门在管理，他们的漏洞一级响应、合规一级响应以及相应的问题处置方案是什么，配置内包含的内容越多，攻击面越大。

​ 第四层，再回头看各个组件漏洞如何修复，开始的软件漏洞如何修复，自研代码如何修复，整个代码修复完之后，甚至硬件问题修复完成之后，统一再上线到现网里提供给客户使用。

​ 这就是端到端解决问题的一个思路。

​ 整个过程如果没有自动化跟踪机制，或者成熟的软件开发流程，是无法 cover 所有的事情，或者自动化程度不高，也会导致产品修复、产品开发，不能按照合同约定及时提交给客户，而有些维保人员或销售人员，会因此搪塞客户：“这个不修复也没事，出现问题的概率很低，修复还可能影响你的网络，要不咱就不修复了。”从此而埋下了一个隐患，久而久之，若爆发出来则不可收拾。

- 生命周期内持续有人维护

​ 要修复一个漏洞，安全部门观察到某个开源软件包含了一个漏洞，请产品去修复这个漏洞，安全响应部门已经将所有的漏洞，包括它的行为都已经归档，但是产品在过程中是否修复了呢？产品修复肯定是在新版本的软件包里修复的，或者是给一个新版本的补丁，从企业内部来说有可能产品确实是修复了，但是到客户，到销售部门，到维护团队，整个修复的流程是否真的都做到了？因为涉及到中间的环节太多，如果没有一个跟踪机制，这个修复流程实际上是不清楚的。

-所有代码需要代码级安全

​ 代码级安全不仅仅指在企业内研发阶段需保证代码级安全，也包括客户提的二进制代码，所有的程序都要做到代码级安全。假如说有些产品因为某种原因不停迭代，新版本和老版本都在老的硬件上，因为需要兼容老的硬件，所以某些软件不能升级，这种就是一个新的兼容性挑战。

5、开源安全之殇

开源软件升级的事情，怎么会威胁公司的生存？

案例：ONUS 是越南的一家金融科技公司

​ 2021 年 12 月 9 日，由 Log4j 引起 Log4Shell 0day 漏洞的执行程序在 GitHub 上公开。这个事件和心脏滴血事件类似，看上去 Log4j 社区一直有人维护，社区内也有很多人在贡献，但在 JDBC 上做的一个链接/模块长期无人维护，当这个点被黑客发现并且利用，他们在各种试验之后，证明可用来攻击其他系统，因此就爆发了 Log4j 事件，而在这事件出来之后，大家第一反应就是等，等社区出补丁、“work-around” 的解决方案，然而等到后面，才发现这个问题非常底层，短时间内没办法解决，虽出了一系列方案，但也解决不了根本问题，等到最后企业开始真正去解决这个漏洞时，发现应用软件、中间件等都被攻击了，而中间应用软件修复好之后，服务器、服务器软件、云也都被攻击了，因为服务器的应用范围非常广，很多系统都拿它来记录日志、遥测信息，这时就不仅仅是一家公司的问题了，大家都把自己的系统托管在云服务厂商上，云服务厂商与硬件厂商一起运营云服务，当其中一个应用出问题，导致整个基础设施都出现问题，因此需要整个上下游都需要修复这个漏洞，系统才会变得安全。

​ 然而很不幸，ONUS 成了黑客们的攻击目标。在 12 月 11 日至 13 日期间，黑客成功地利用了 Cyclos 服务器上的 Log4Shell 漏洞，200 多万条客户信息被出售，并被黑客勒索 500 万美元。

​ 在 Log4j 漏洞爆出来之后，这家金融公司第一时间知道这个漏洞并进行修复应用及相应的算法。但是很不幸的是，没有进行端到端的生命周期管理模式，以及还应用很多从外部采购的第三方平台，包括服务器的软件。

​ 从这个案例看来，即使修复了上层应用的风险和漏洞，但仍然会暴露底层软件，包括操作系统、云服务问题。对漏洞修复、开源软件升级、生命周期配套已经威胁到公司利益！不改不行，不说不行！

三、探讨如何持续构建高安全产品的研发能力

1、管生

建立软件BOM（SBOM），全流程产品视角管控

​

​ 如何持续看护整个生命周期的产品安全和漏洞问题，实际上软件开发需要经历几个阶段，从整个产品的研发阶段，包括规划、开发、质量测试、生命周期的发布，到最后的维护，整个生命周期都会建立一个追溯机制。

​ 从社区开始，有不同的开发者进入社区，优先于企业发现社区里的各种漏洞、洞察可能存在的风险，一旦发现风险，就会拿到专家组里进行评审，比如这个 Log4shell 漏洞会不会影响公司的产品，比如云计算的产品，还是计算的产品，还是无线的产品？专家组会对这个问题的严重程度进行分类，通过评估标准，把相应漏洞挂接到软件库里，这个软件库有系统，这个系统会将所有产品及产品所使用组件、组件下使用的开源软件，包括开源软件的漏洞，通过树状的方式全部记录下来，这是典型的 SBOM 的一个应用场景。

​ 产品使用需要遵守研发申请的过程，先提出申请：我需要用这个软件实体库内的某一个开源软件。那么就需要做各种合规的、安全的审核，审核通过之后，才会被调入到产品的配置库内，和产品一起进行构建。

​ 产品构建之后会进行扫描，因为在使用开源软件过程中，可能会对其进行裁剪或者增强，这个过程可能会引入新的问题，所以需要再次扫描排除问题，没有任何问题之后才会将整个产品进行发布，然而产品发布并不是整个过程的终点，还需依据合同对产品进行维护，在社区内排查漏洞并进行修复。

​ 有这样一个追溯机制，任何一个漏洞到底影响了哪一个组件或者产品，都可以被快速定位出来，一旦被定位，就能给出建议，比如云计算里的某个产品，server 出问题了，可能会影响到产品的安全，那么我们会对产品进行扫描，确定这个漏洞会影响的范围，比如只会影响 1.0~1.1 版本，我们马上会有相应的应急方案，对这个软件的漏洞，要么打补丁，要么进行升级，会产生兼容性问题，升级的版本与操作系统不兼容，所有东西都会通过内部研发的机制，先进行兼容性测试，比如 a 版本和 b 版本，都能修复漏洞，通过内部的兼容性测试，可以知道修复 b 版本既可以保证兼容性，又可以保证能修复漏洞，那我们就会优先去选用 b 版本解决这个漏洞。

​ 通过这样一套机制，能保证交付到客户的这些软件，它的解决的方案，包括产品，能够从端到端的视角，把所有漏洞犄角旮旯的这些问题都能找出来，进行妥善处理。

2、开源软件技术组织和产品线的矩阵管理

​ 产品安全管理过程中需要有一个专家机制做技术上的评判，这个专家机制，不是按照产品来进行划分，而是按照技术来划分，比如大数据的技术，云计算里面可能用到的大数据、AI、知识图谱，还有各种各样的技术，通过技术去划分开源软件，每个技术都有一类专家进行看护，可以看到库里面的哪些软件是漏洞少的，引入的新软件里面有多少漏洞，新的漏洞多的版本，我们及时将其剔除，因此在华为的软件库里，安全组件占比是最多的，在特殊场景下需要带漏洞的软件是极少的，只有在某些特定的场景下，允许其进入华为的软件库里使用。这就是华为公司在使用开源软件提交产品的竞争力所在。

​ 看护的目的是什么？在这以增长率表示。图内的增长率是指：当我们使用开源软件时，符合我们要求的版本有多少。一开始建立时定的要求比较低，因此满足我们要求的版本就比较多，相应增长率就比较高，后面增长率会稳定在某一水平，也代表我们的标准日益趋同，标准逐渐统一，即每月审核通过的软件/能用在产品内的软件会固定在一个数量，以保证整个研发体系的风险可溯、可控。

​ 除了技术组织看护之外，还有产品线的各种组织来看护，因为在技术看护下来之后，还需要针对各个不同产品的特征来进行看护，比如将某个产品交付给山东的客户，是以公有云方式进行交付，交付给陕西的客户，是以私有云的方式进行交付，那么应用场景就不一样，从 license 来看，如果是 GPL，线下交付给客户的方式，属于分发，风险则会更大，如果以云服务的方式交付，那么风险就很小，通过技术组织的看护，可以将风险进一步降低，保障效率的同时，又能保障风险被快速处置，这个就是通过组织的矩阵管理进一步细化的方式。

​ 成立软件选型专家组织，集中把控软件选型：在做优选的时候，要有相应的开源软件的一些技术组织，对开源软件来进行管控。比如说对软件的分类，专家对软件进行分类，按照分类，专家评估，评估报告会影响产品引入开源软件的优先级。在产品线的团队里，应该也有相应的专家能对产品做分层的管理，把产品线的开源软件的优选管控起来，只有这样形成一个矩阵化的管理，才有相应的保障。

3、管死：生命周期

挑战：层层嵌套带来的配套复杂性

生命周期管理模型：

① 合同；② 产品；③ 主要硬件；④ 其他硬件；⑤ 软件版本；⑥ 平台版本；⑦ 硬件配套软件；⑧ 构建工具；⑨ 开源软件；

​ 从合同开始，产品包含有很多很多内容，可能有整机，可能有内部的硬件，包括主控板等硬件，还有软件，软件分平台类的软件，应用类的软件，针对芯片的某些驱动，构建工具的软件，这些都需要有生命周期的规划。本软件的生命周期一定要包含上层软件的生命周期，也就是说平台软件也好，芯片软件也好，驱动也好，它的生命周期一定要包含上层应用的生命周期。

​ 在一个现代化的软件开发流程中，企业要开发一款产品，包含各种交付件，硬件、软件、平台、应用等等，都是需要软件的看护，硬件的生命周期往往很长，差不多 5~10 年，软件就逐渐缩短，比如基础软件可能远一点，比如操作系统 openeEuler，比如 Ubuntu，大概有 3~4 年的生命周期，但是存在在操作系统上的平台，比如云平台或者一些开源软件平台，可能只有 1~2 年的生命周期，再在上面构建 APP 应用系统，比如 OpenSSL、Log 4j，这种软件可能一两个月都在升级版本，无时不刻会有漏洞出来，因此越是底层的软件或硬件，越要 cover 处上层应用的安全风险，不能上面的应用还在用着，下层的平台或者操作系统就已经停止支持。这个风险就是 APP 不论怎么修复，上面的应用，一旦操作系统出现问题之后，交付给客户的整套产品都会出现问题，而且没法通过 APP 的支持人员来解决。这就是为什么要层嵌套，特别是现代软件开发过程中层嵌套的产品，如果不对生命周期进行管理，一定会造成即使知道漏洞要修复，也修复不了的问题，因为平台无人看护，资源撤了，人也离开，最后导致落地困难。

​ 如果想要解决这个问题，就要考虑一个思路，不仅要考虑如何开发产品，还需要再开发之前就考虑清晰，需要支持这个产品多长时间？如何在支持时间内保障交付在各个客户收集的各个部件，其安全风险都能够被 cover？这个设计一定要在产品开发之前就设计好，且设计完之后，在合同层面告知客户，比如这个版本只能维护四年，用到的开源平台，比如 Red Hat 的版本就只有 5 年，如果 5 年之后，可以新签订合同进行维护，也可以提供新产品，继续提供 4 年或 5 年的维护周期，一定要让客户知道产品的生命周期是有期限的，知识能力是设计出来的，这时生命周期设计，也是交付给客户，让客户更安心地在这个生命周期时间内，享受企业带给客户维保的承诺。

4、产品各层级生命周期可维护

​ 比如产品里集成的 openSSL，12 个月内每个月都发布一个开源软件发行版，每个版本对应的软件版本都需要进行看护，逐层分解：产品软件下又分平台软件，平台软件可能有 4 个版本，每个版本支撑产品软件的时间得进行确定，平台软件定义好之后，开源的操作系统能支撑平台软件的时间、人力等也要进行计算。整个过程就如计算客户的合同，每层进行细分，投入的人力、资源等在内部逐一签订契约，以保证所有生命周期管理的项目能逐一执行下去。

​ 制定产品生命周期的时候，需要注意生命周期可维护。产品硬件，软件它都有生命周期的模型的约束，产品是要不断迭代演进的，如果某一个产品版本一直用下去，肯定会出现网络安全问题的。硬件也是有生命周期的，因为硬件很难去被替换，所以我们在硬件设计的时候要预留相应的空间，使得我们的软件能够进行升级，不能因为硬件而不允许升级，相应的产品的软件平台，工具、芯片、软件，同时能够保证升级，不会被上一层和下一层的软件生命周期所约束。

通过硬件/软件配套管理，避免生命周期失控，执行 EOX 管理

1）合同界面：产品、硬件、软件生命周期模型有约束；

2）产品：代内、代际皆可持续演进，更换硬件设备做到最少；

3）单板：有 EOS；

4）产品软件与 EOS 硬件配套策略：如果现网要升级新软件，则需替换 EOS 硬件；

5）产品软件：内部各组件以及与硬件、产品有配套机制；

6）内部组件：按大特性版本做 EOX 管理，EOM（停止配套）严格执行，确定好 EOM 到 EOS 时间，用补丁方式升级；

7）开源软件：开源软件生命周期无法覆盖的，产品/平台在 GA 与 EOFS 之间要升级；开源软件版本 EOS 前，责任 owner 提供缺陷修复（含安全漏洞）服务

–– 组件级小软件：增加 EOS 点，采取社区维护+企业维护模式，拉长 EOS 点 (最少 1 年)

–– 系统级大软件：确定生命周期 GA-EOM、EOM-EOS 时间

8）构建工具：自研类遵循平台生命周期管理要求；开源类遵循开源软件生命周期管理要求；

9）硬件配套软件：硬件配套软件执行单独的生命周期，与硬件生命周期管理对齐。

四、小结

1、生命周期管理长效机制总体策略

对外：完善供应商、企业、客户三个对象的生命周期规则，确保产业链生命周期不脱节；

对内：完善各对象的配套关系，建立完整的产品树，确保生命周期风险可视 & 可控。

1）客户合同界面：规范客户合同界面对产品/硬件/软件生命周期管理的约束。

2）产品：各个组件+硬件

① 产品：断代模式下，明确并加快产品断代。比如之前有个开源软件 python 软件，官方在 2020 年停止对其进行维护，我们如果大规模使用了这个软件怎么办呢？我们只能通过跟客户沟通——因为产生了重大的不可预知的变更，我们的这个版本只能维护到 2020 年，希望客户能够理解，我们需要在 2020 年升级到下一个版本，这个版本里使用更新的可维护的组件。如果社区已经不维护了，还强硬跟客户解释我们可以一直维护下去，这种做法是欺骗客户，是不可取的行为。

② 硬件：执行单独的单板/部件的生命周期管理，以及与产品软件的配套关系管理。硬件也会产生漏洞，比如之前报道出来的关于 Intel 的 CPU，爆发的幽灵漏洞，正是因为硬件设计本身的问题所造成的。

③ 产品软件：单产品软件、内部组件、开源软件、硬件配套软件、工具软件；很多人往往会忽视工具软件，认为工具软件只是在公司产品内部使用，关系不大，但往往工具软件会生成一些配置文件，或生成代码嵌入到产品内，如果不进行管理，这些自动生成的代码就管理不到，产生的风险也因此无法识别。

3）供应商合同界面：规范供应商合同界面对三方件的生命周期管理约束。

​ 随着产品越做越大，产生的事情越来越多，不太可能仅靠人工就能进行管理，需要依靠工具、自动化系统，比如信息树、漏洞跟踪系统等，将信息可视化，一旦遇到风险，能进行自动预警、自动分发任务，从而在相应团队里进行修复。因此所有的这些东西都由数字化平台承载，进行统一风险管理。

2、生命周期优化必须解开两个扣

产品必有死期，合同必有约束

​ 生命周期的管理总结：产品它必有死期，产品无限制的固定的维护下去，一定有死亡或者是退出生命周期的一天，即软件和硬件需要不停迭代，只有迭代才能保证软件中的安全、合规问题能够被解决掉。

​ 跟客户谈合同的时候，合同也应有约束，合同不能无限制，对某一个老的硬件或产品一直维护是不切实际的，总有一天会有大量的安全问题，产品不可用，以及对商业造成损害。在研发的角度上，持续产品的研发能力，保证所有的东西都是可以维护，易于升级。