1.3.4 开源软件的供应链

当今的软件开发，为了快速提供软件功能，没有人会从零开始去编写每一行代码，开源软件可以提供成千上万个功能，从开源软件中寻找并引用一些成型的功能，将大大加快开发人员的创新速度，这便在基于开源软件的项目中引入了隐形的供应链关系。

由于开源软件的广泛运用和云原生时代的到来，基础架构越来越复杂和多样化，即使是同一个开源软件，每个公司的架构方式和实施方式也会存在差异，选用的周边配套组件也不尽相同。虽然开源软件本身不存在使用权的限制，但是在全球复杂的政治、经济格局下，开源软件供应链中只要有一个环节出现中断，最终也会像工业制造的供应链一样，波及最终的使用端。软件供应链出现问题，不仅新的软件供应会受到影响，甚至会直接影响到当下正在使用的软件的可用性。

软件的开发过程不像物品的制造过程，不需要供应链的上一环节每次都把生产出来的产品交付给下一环节，因为软件一经生产完成，你就可以无限次地部署和使用它，不再需要供应链的参与。但实际上，软件需要安装，出了问题需要有人服务，存在缺陷需要有人修复，这些环节也是供应链的过程。进一步讲，对于企业版的开源软件，提供授权许可就是供应链中的一环。

只要基于开源软件的源代码进行编译，得到二进制安装和运行文件或者使用社区提供的可运行文件，就可以自由使用开源软件。这个供应链从表面上看非常简单，但实际上开源软件有着更为复杂的供应链结构。

开源软件的源头是开源项目，但事实上，开源软件供应链的源头起始于不同领域的开源软件基金会。作为某一领域开源软件方向的主导者，虽然多数基金会自身并不直接制定技术标准，但是基金会组织、引导并孵化该领域中的开源项目，这样的过程最终会形成一种事实标准，并且基金会本身毕竟是一个经国家批准的实体组织，依然要受注册国的法律约束。

很多大型开源软件要引用和集成几十甚至上百个其他开源软件，比如Linux操作系统就是把Linux Kernel通过Fedora、openSUSE、openEuler等若干不同的发行版，将应用、工具、类库、各种运行时集成在一起，形成安装即可用的操作系统。如今，没有人会为了用Linux操作系统而从一个Linux Kernel开始做搭建。其他类似的系统还有很多，如AI平台、容器平台，大的集成性开源项目往往会关联众多的其他开源项目。

开发开源软件的社区本身并不会为用户提供技术服务和各种商业化的发行服务，比如广泛的兼容性测试、产品手册，甚至是安装和升级工具。没有足够技术积累、人力资源和使用规模的商业用户很难自己完成这类工作，这时一些IT公司担当起开源软件服务商的角色。比照以往的传统软件，软件服务商可以分为两类。第一类是软件的发行商，这类服务商既可以提供软件的日常使用类的服务，也可以提供缺陷修复类的服务，发行商掌握软件的源代码，能够将运行代码中的故障还原到源代码的准确位置并进行修改，帮助用户进行根因分析。第二类是掌握了该软件技术能力的服务商，可以提供日常使用和配置类的维护，根据已知故障和修复方法，帮助用户尝试解决问题。但是由于这类服务商不具备对软件源代码的维护能力，因此他们无法帮助客户进行代码级的故障排查。但是对于开源软件，这一状况就发生了变化，开源软件的源代码是公开的，得到源代码的服务商即使不是该软件的主要开发者，也可以通过源代码帮助客户进行根因分析，并将修复的内容提交到社区以彻底解决软件故障。只要服务提供者能够编译该软件的源代码，并能够复现编译过程，就能够提供该开源软件的全面服务。

前文中提到了代码库，作为开源软件承载的载体，代码库也是供应链中重要的一环。为开源软件提供代码库的机构往往都是企业，这和基金会有所不同，企业会受到所在地政府更为直接的管控，政府有权限制企业服务于某个人、某个企业、某个地区，甚至某个国家。2019年，全球最大的代码托管平台GitHub更新了用户协议，表示GitHub企业服务器及用户上传的信息要接受美国法律监管。

所以，开源软件供应链是否可以长期安全可控，是一件很复杂的事情。软件不像硬件，存在性能接近的产品，可以直接替换使用。一个特定的开源软件一定是唯一的，任何克隆或者仿制的结果都是一个独立的新软件，可能在开始克隆时两个软件基本相同，但是随着时间的推移，两者会存在越来越大的差异，无法做到既平行发展又保持高度一致。这就好比RHEL和SUSE Linux两种流行的Linux操作系统，两者都采用类似的架构、RPM包的安装运行机制，相似度非常高，但是如果RPM包安装错了环境，应用也无法正常运行。

采用全新的供应链安全方式，不仅要看该软件的供应链上游，还要看其下游是否能够跟随全新的供应链体系，这也是谈到开源软件的时候，生态建设远比供应链可控更为重要的原因。在生态建设中，每一个参与方都应该是受益者，否则这个生态将无法长久存在，开源软件的参与者可以是企业或者个人，但没有谁完全依靠兴趣和荣誉而为社区做贡献。就像在前端开发方面非常流行的core-js项目，这是一个JavasCript库，由Denis Pushkarev全职开发，在全球前10000个网站中，超过一半的网站在使用这个模块，其中包括苹果公司等大型公司。因为依靠目前的捐赠方式无法维持生计，Denis打算放弃对core-js的维护。在2015年之前，红帽一直是Linux Kernel的最大贡献者，但是Intel后来居上成为第一，其原因是参与Kernel项目让Intel可以在第一时间把CPU的新特性推向市场，Linux的流行会带来Intel CPU在企业端的广泛应用。

对于最终用户来说，最大的供应链安全是选择上的自由而不是仅仅依靠信任来建立安全。与传统软件相比，开源软件的变动更为频繁，社区没有义务为使用社区软件的用户提供软件功能的连续性保障，因此在早些时候，经常可以看到一些基础开源软件中已弃用的函数让开发人员崩溃，甚至是一个开源项目突然销声匿迹。我们曾经帮助一个有上万台服务器的客户做了一个估算，是否可以把当前的操作系统A都替换成B，结果发现这是一件非常吃力又不讨好的事情。虽然操作系统看起来不像数据库那样关键，不像中间件那样和应用直接相关，不像开发框架那样嵌入在应用代码里，但是如果要更换操作系统，各种兼容性验证、环境的参数还原、稳定性测试，以及寻找切换的时间窗口，整个数据中心全年只能干这一件事，前提是业务应用开发部门会全力配合。

实际上，随着云架构的广泛运用，一些新的技术和管理方法能够帮助企业来解决这类可能会发生的事情。基于容器化的部署、不可变基础设施、模板化管理，再改变数据中心的系统构建模式，这不仅能使操作系统的更换变得更为容易，而且其他基础设施的可替换性、中间件的可替换性都在大幅提升。企业需要尽快落地云架构能力，做到一切皆可换，才能真正实现“我的开源软件供应链，我做主”，避免上游改道、下游遭殃的情况发生。