关注企业开源供应链：开源有风险，使用需谨慎！

所谓的软件供应链，就是一个企业在生产环境中，包括研发、运营、销售等环节所依赖的计算机软件。如今，大部分企业所使用的基础软件都是基于开源软件实现，有研究表明目前企业所使用的软件中，开源软件占比已高达 90%，可见开源软件在今天的重要地位。

然而，开源软件不同于有供应商提供一站式服务的商用软件。很多企业使用的开源软件通常来源于开源社区或各大代码托管平台，如何保证这些软件的安全性与合规性，就成为了每个使用开源软件的企业必须思考的问题。

开放原子基金会 TOC 副主席谭中意是一位拥有 20 年开源经验的软件工程师，同时也是国际开源合规项目 OpenChain 中国工作组联合创始人。本文将整理谭中意老师在 GOTC 全球开源技术峰会「开源运营与治理」直播专场的演讲内容，为大家介绍企业开源软件供应链常见的风险和挑战，以及国际开源供应链标准 OpenChain 项目如何帮助企业解决和避免这些问题。

直播回放：https://play.itdks.com/watch/10441588?player

开源软件供应链的风险与挑战

开源软件在企业软件开发中的地位无需赘言，但很多企业的开发团队在使用开源软件时，往往会忽略一些潜在的风险。

这里有一个真实的案例。美国芯片巨头 Broadcom 曾在某款 802.11 芯片中使用了 Linux 系统，随后该芯片被通信设备公司 Linksys 收购，并集成在了自家的 WRT54G 无线路由器中，再后来 Linksys 公司在 2003 年被业界巨头思科收购。理论上，由于 WRT54G 使用的芯片采用了GPL 协议的 Linux 系统，那么包括芯片源码、集成了芯片的产品源码都要遵循 GPL 协议开源出去。然而出于商业利益考虑，思科并没有这么做。随后，思科就被自由软件基金会 FSF 投诉，起初双方互不让步，经过数年交涉，思科被迫开放了一百多款路由器的源代码，并向基金会捐款数千万美元才把事件平息。这件事对开源社区来说无疑是一件好事，但对于思科公司来说确实造成了一系列损失。

在来看看另一个案例。知名前端开发框架 React 最初是 Facebook 公司在内部开发 Instagram 时构建的项目，是一个用来构建用户界面的优秀 JS 库，于 2013 年 5 月开源。React 最初是在 BSD 协议下开源，在世界范围内吸引了大量的企业用户。然而在 2016 年 7 月，Facebook 毫无预兆地在 React 的开源协议中附加了一项专利条款（patent grant），该条款规定如果你使用了 React，你不能做构成与 Facebook （包括其子公司及其合作方）竞争的事情，一旦你做了，就会面临法律诉讼。此条款一出立即引发了轩然大波，导致国内外众多企业用户不得不放弃 React 改用其他的替代软件。这个案例告诉我们，开源项目来源一方也存在协议变更等事件带来的法律风险。

除了法律合规性方面的风险以外，开源软件供应链中也存在代码安全性的风险，后者给企业带来的损失往往更加直接和巨大。

2017 年 9 月，美国三大信用评估机构之一的 Equifax 公司被曝出遭黑客入侵，导致约 1.43 亿用户的个人隐私数据泄漏。事后的调查显示，Equifax 内部使用了开源的 MVC 框架 Apache Struts 项目，黑客利用该项目 2.3 版本中的一个漏洞实现入侵。而事实上， Apache Struts 社区早在当年的三月就修复了该漏洞，但是 Equifax 在五月中旬出现了泄漏，直到七月底才被发现，Apache Struts 方面认为是 Equifax 内部没有及时更新版本导致漏洞被黑客利用。这次事件导致 Equifax 公司直接经济损失近 4 亿美元。

此外，由于不像商业软件一样有完善的售后服务，在使用开源软件的过程中遇到大大小小的 BUG 也是家常便饭。对于有能力的企业来说，可以专门安排开发人员参与开源工作，将 BUG 问题反馈到开源社区等候维护者解决，或是自己解决并将代码回馈到开源社区，这也是我们鼓励的一种参与开源建设的良性方式。但对于很多中小型企业来说，面对这些 BUG 时往往会手足无措，损耗大量的时间和人力成本。

解决问题的思路

开源软件供应链存在各种各样的风险，针对这些风险建立标准化的合规流程迫在眉睫。

一个完整的开源供应链如下图所示：

企业从上游开源社区（Upstream）引入一个开源项目，在公司内部通过一系列 DevOps 研发、定制、上线，最后对外以线上服务、软件包、硬件捆绑等形式输出。要使得整个供应链过程充分地高效、安全、合规，要面临的挑战很多。

首先是来自上游开源社区的开源软件所包含的组件数量庞大。以国内最常用的编程语言 Java 和 JavaScript 相关技术栈为例。根据 Sonatype 发布的《2020 年软件供应链调查报告》中的数据，目前共有 5 百万 Java 软件包在 maven 中心仓，其中有 30 万个开源项目，平均每个工程师每年下载 29,736 个软件包；而在 node.js 相关的 npm 中心仓中，共有约 130 万软件包，2019 年新增 50 万软件包，平均每个工程师下载 93,457 个软件包。在面对人均使用量如此庞大的开源软件包时，为了保证供应链的合规性，需要确保团队内部每一个工程师都对开源软件相关协议、版权等问题有所了解。

经过多年的经验，人们注意到每个公司要做到开源供应链合规，都有大量相似的工作。比如开源软件的 License 虽然多，但是常见的也就那么几种，相关材料可以归纳总结之后复用；又比如公司使用开源软件的政策，指定使用开源软件的合规流程，让工程师理解相关知识的培训材料，建立供应商之间的信任链条等，这些都是大量重复性的工作。

什么是 OpenChain

为了简化这些重复性的工作，指定标准化、流程化的开源供应链，业内的一些头部大厂开始进行合作，联合 Linux 基金会共同创立了 OpenChain 项目。OpenChain 提出了一整套开源软件供应链的规范，并制定为 ISO/IEC 5230 标准。2020 年 12 月 16 日，Linux 基金会、Joint Devlopment 和 OpenChain 项目宣布 ISO/IEC 5230 已被核准为国际标准。

OpenChain 为企业开源软件供应链提供了一个开源的法律框架，各个企业可以根据这个法律框架来定制自己需要的内容。其主要内容由三部分组成，分别是：

Spec：定义企业达到开源合规的一系列政策，流程和人员角色。
认证：根据 Spec 在政策/流程/人员/培训等方面的要求，达标即通过认证。
培训：提供了一系列培训材料可以参考。

OpenChain Spec

Spec 重点描述企业的开源合规计划应该“做什么”以及“为什么要做”，而不是“如何做”、“何时做”。具体内容包括：

企业需要有一份开源政策，而且需要让员工都知晓
企业需要指定参与合规工作的人员，并确保他们具备能力
企业需要有流程来审核许可证，确保符合权利和义务
企业需要有流程来为交付软件创建软件组件清单，包括许可证信息等

OpenChain 认证

OpenChain 还包含合规认证，即针对规范制定了一系列问题，企业能够满足所有的这些问题，即符合要求。

例如针对软件发布的过程相关有如下几个问题：

是否有明文规定的流程，用于识别、记录和存档软件中的开源组件信息
是否有明文规定的流程，保证随软件发布按照许可证要求而提供合适的文档

例如针对公司员工对外开源进行贡献相关有三个问题：

是否有对外开源贡献的政策
是否有对外开源贡献的流程
是否有流程让工程师都了解对外开源贡献的政策和流程

OpenChain 培训材料

此外，OpenChain 还给参与企业提供了统一的培训材料，包括针对工程师的开源合规培训材料，针对 OSPO 的开源管理政策模版等。

除了是 Linux 基金会旗下的一个开源项目以外，OpenChain 同时也是一个社区，并按照 Linux 基金会开放治理的工作模式运转。OpenChain 设有董事会，董事会成员包括微软、谷歌、ARM、 CISCO、Toyota 和 Oppo 等厂商。合作伙伴包括各种法律咨询公司、合规工具厂商等。

OpenChain 给出了一系列评估企业开源软件供应链管理能力的标准，比如当一个常用开源软件发现高危 CVE bug 和 fix 之后，多长时间内能在该企业内部定位和修复？当该企业对外输出软件的时候，能否快速输出高质量的 SBOM（软件组件清单）等。