本文整理自 OSCS 软件供应链安全技术论坛- 谭中意老师分享的《OpenChain-企业软件开源合规国际标准介绍》完整内容。
谭中意，第四范式架构师，开源专家，OpenChain 中国工作组联合创始人，在 Sun、Baidu、腾讯等有超过 20 年开源研发、治理、运营相关经验。
大家好我是谭中意，现在是第四范式公司架构师，也是企业智能化转型开源社区—星策社区发起人，开放原子基金会 TOC 副主席，国际开源合规项目 OpenChain 中国工作组联合创始人。今天我将围绕以下几点进行分享：
- 什么是开源软件供应链，为什么重要；
- 常见的风险和挑战；
- 国际标准 OpenChain；
- 如何评估和构建安全的供应链。
什么是开源软件供应链，为什么重要
Software Supply Chain（软件供应链）即一个企业所依赖的软件，包括研发，运营，销售等各项活动所依赖的软件，包括引入和输出的软件。我们面临的核心问题是如何信任企业内部的开源软件供应链是高效、安全、合规的。
首先要看一个问题，企业能否不用开源软件？答案是否定的，可能十多年前还有一家公司可以说我不用开源软件还能活下去，但是现在世界上已经没有一家公司能离开开源软件活下去。Linux 基金会统计，日常工程师使用的 90% 的代码都是开源软件，如果哪个企业说他有一半的软件都是自研的，你就可以嘲笑他一下。
开源软件供应链全景图
开源软件的对企业来说，它的供应链全景图是什么东西？首先它从上游社区拿到了开源软件 abc 进入到企业之后，经过 devops 的一系列的开发和运营，最后对外输出的形式包括以 online service、软件、硬件，这个链条我们称之为开源软件供应链全景图。
常见的风险和挑战
常见的风险和挑战有以下几种：
- 合规风险
- 安全漏洞风险
- Bugs 风险
开源软件供给是什么状态？
海量供给、海量需求、还在递增。一份来自 Sonatype 的统计报告——《2021 State of the Software Supply Chain》以 Java 为例显示出，在 Maven 中心仓有 430 个软件项目，730 个版本，平均每个工程师每年下载 3万+个软件包，总下载数从 2020 年的 267 Billion 到 2021 年的 457 Bilion，增长 71%。
以 JavaScript 为例在 npmjs 中心仓库统计有 1800 万软件包，2100 万个版本，平均每个工程师下载 10 万+个软件包，总下载数从 2021 年的 1 trillion 到 2021 年的 1.5 trillion，增长50%。
从我的评估来看，国内只要是超过 1000 人的团队、只要是用过用 Java 的，那么它使用开源软件的数量级就在 1 万以上，如果是使用 JavaScript 的那就是至少在 10 万级别。如果哪个公司告诉你，他们内部使用开软件只在千级别，大家就可以想象，他根本不清楚业内现状。
国际开源合规标准 Openchain
政策/流程/培训是相似的
这个标准的产生是在 2014 到 15 年，很多企业在 Linux 基金会的里面聊我们怎么能做到开源的合规管理？开源软件的 License 虽然多，但是常见的也就那么几种，每个公司要做到合规，都有大量相似的工作：
- 使用开源软件的政策；
- 确保合规的流程；
- 让工程师理解的培训材料等…
OpenChain 应运而生
所以大家就聚在一起讨论，形成了开源软件管理社区，制定了一系列的规范，最后把它变成了国际标准。
国际标准它首先是一个规范，即 Spec。其次是一个 Linux 基金会下的子基金会：
- 理事会；
- Working groups；
- 相关服务：认证，培训等…
OpenChain Spec：国际标准ISO/IEC 5230
上图就是他们的全景图 Openchain 的一个全景图。2020 年 12 月 16 日的时候，Linux 基金会、Joint Development 和 OpenChain 项目宣布 ISO/IEC 5230 已被核准成为国际标准。
OpenChain Spec 相关内容简介
OpenChain Spec 重点描述企业的开源合规计划应该“做什么”以及“为什么要做”，而不是“如何做”、“何时做”。
具体内容：
- 企业需要有一份开源政策，而且需要让员工都知晓；
- 企业需要指定参与合规工作的人员，并确保他们具备能力；
- 企业需要有流程来审核许可证，确保符合权利和义务；
- 企业需要有流程来为交付软件创建软件组件清单，包括许可证信息等；
- …
一份中文标准的说明书（https://github.com/OpenChain-Project/Specification/blob/master/Community/zh-Hans/2.0/OpenChainSpec-2.0-zh-Hans.pdf）供大家下载参考。
SPDX：ISO/IEC 5962:2021
SPDX 简单说就是 License 的精确、简单、统一、语言无关的表示，例如：
- // SPDX-License-Identifier: MIT
- // SPDX-License-Identifier: GPL-2.0+
OpenChain 同时也是一个社区
OpenChain 有它的理事会：Microsoft，Google, ARM, CISCO, Toyota, Oppo，Huawei，Hornor 。也分有各种邮件的组：toolchain，spec，自动驾驶、教育…还会有一些 Partner：包含各种法律咨询，合规工具厂商。
OpenChain workgroup
社区内也有各种各样的 working group 包括：
OpenChain 培训
OpenChain 会提供一些培训材料 ：
- 针对工程师的开源合规培训材料；
- 针对 OSPO 的开源管理政策模版；
- 更多案例。
OpenChain 包含合规认证
OpenChain 提供一些认证，比如针对规范制定的一系列问题，答复都是 Yes， 即符合要求。
例如针对软件发布的过程相关有如下几个问题：
- 是否有明文规定的流程，用于识别、记录和存档软件中的开源组件信息；
- 是否有明文规定的流程，保证随软件发布按照许可证要求而提供合适的文档。
例如针对公司员工对外开源进行贡献相关有三个问题：
- 是否有对外开源贡献的政策；
- 是否有对外开源贡献的流程；
- 是否有流程让工程师都了解对外开源贡献的政策和流程。
OpenChain第三方认证商
如何评估和如何构建
如何构建企业开源软件供应链？
构建其实很简单，就是政策流程加工具。
评估企业开源软件供应链治理（从结果）
当一个常用开源软件发现高危 CVE bug 和 fix 之后，多长时间内能在该企业内部定位和修复？现在开源软件的 bug 在开源社区的修复大概是以周为单位，更快的有的甚至当天就能出新版本就能把它修掉。当该企业对外输出软件时候，是否快速输出高质量的 SBOM（软件组件清单）和 Notes，满足合规要求？一般两个都需要。
SBOM（软件组件清单）
SBOM（Software Bill of Materials）类似食品的配料清单，对于每个软件组件需要提供如下信息：
- 软件名称，软件版本
- 软件许可证
- 对软件做的修改
- 许可证文本和著作权申明（对于部分开源软件）
Notes文件
Notes 文件包含所使用开源组件的 Copyright 和 License，开源 License 要求随软件包发布的 notes 文件中包含：
- MIT 要求 include License，Copyrihgt
- Apache V2要求 include License，copyright，changes
- BSD 3 要求include License，Copyright
评估企业开源软件供应链治理（从过程）
刚才说了，从结果来说就衡量，接下来说下是否建立起完善的开源组件管理机制，包括：
- 人员组织
- 政策和流程
- 培训和工具
通过OpenChain的认证是一个不错的验证方式。
企业理想的开源软件供应链状态
当引入开源软件的时候，我们需要确保工程师:
- 使用高质量和有限的组件，并从可信的提供商哪里获得
- Keep a record when consuming them
- 了解使用该组件的法律合规需求
当对外输出软件或服务的时候，我们需要确保工程师:
- 发布时同时有一份软件组件清单和 Notes 文件
- 满足这些开源组件的合规要求
- 及时修复安全/SRE/法务提出的各种问题
基本原则
这张图其实是来自于一个著名质量大师德明在丰田做供应链管理时候的一个图。这个图和供应链管理的图原则上一模一样，以我本人经验，其实就是组建跨部门多功能小团队，包括法务，安全，工具团队，然后制定相关政策和流程并落实，使用工具尽可能的自动化并且进行大规模和多层次的培训和宣导。结果对于同样 fastjson 的一个高危 CVE bug 来看：
- 之前：安全部门向全员发出修复通知，半年内修复状态未知
- 之后：30 分钟内定位受影响代码仓库并精确发出修复通知，3天内全部修复
以上为我的完整分享，感谢大家的观看。
发布者：墨菲安全，转发请注明出处：https://www.murphysec.com/blog/solution/4540.html
