本文来自：

小马哥 极狐(GitLab) 技术布道师

开源许可证是开源软件的法律武器，是第三方正确使用开源软件的安全合规依据。

根据 Linux 发布的 SBOM 报告显示，98% 的企业都在使用开源软件（中文版报告详情）。随着开源使用率持续提升，企业必须要重视许可证安全合规问题，因为其直接关乎企业品牌，使用不当可能导致经济损失。

根据 OSI 官网显示 ，由 OSI Approved 的许可证就多达 100+ 多种，这还不包括一些企业/组织自定义的开源软件许可证。另外，不同许可证之间的兼容性也是一个很复杂的问题。

图片来源：如何选择开源许可证？ - 阮一峰的网络日志

正是由于这种开源软件许可证的复杂性，让企业在使用开源软件时，违反许可证安全合规的问题时有发生。

违反许可证合规的那些事

---

国外事件

2020 年，CoKinetic Systems Corporation 公司对 Panasonic Avionics Corporation 公司发起诉讼，要求索赔 1 亿美元。原因是 CoKinetic 公司指控 Panasonic 违反了 GPL v2 协议。

根据 CoKinetic 供述的法律文件，其认为 Panasonic 的机上娱乐设施硬件使用了基于 Linux 的操作系统，而 Linux 操作系统是以 GPL 协议分发的，GPL 的特殊性在于当软件使用了 GPL 协议的组件时，该软件本身就必须遵从 GPL 协议规定，对源码进行公开。但 Panasonic 却拒绝开放其操作系统的源码，以此阻止竞争对手开发基于机上娱乐硬件的软件。关于此事件的详细信息可以查看 The $100 Million Court Case for Open Source License Compliance。

上述例子中，两家商业公司走向法律诉讼的直接原因就是开源软件许可证安全合规问题。

国内事件

2020 年，国内某云厂商使用了某 Top APM 开源项目，但是没有遵循该开源项目的 Apache  License Version 2.0 协议，在产品中对于该项目的使用进行相关声明，因此收到了 Apache 基金会关于 Open Source License Violation 邮件。事件发生后，该云厂商和该 APM 项目进行沟通并做了相应调整。关于该事件的详细经过可以查看国内某内容平台对于此事件的报道。这也是一起典型的开源许可证安全合规事件。

上述例子只是众多违反许可证合规事件中的冰山一角。

在开源渗透率如此之高的今天，没有一个企业可以完全 “隔离” 开源软件。如何保障企业在研发过程中安全合规使用许可证，是企业实现稳健发展不容忽视的问题。

企业如何实现许可证安全合规？

---

如开篇所说，许可证本身繁琐复杂，因此，安全合规使用许可证也是一件极其复杂的事情，需要从文化构建、流程制定、工具选型等方面入手。

文化构建

许可证安全合规属于安全范畴，在提倡 “人人为软件研发安全负责” 的今天，需要构建企业安全文化。例如通过安全培训，让软件研发相关人员建立起对于软件许可证的基本认知，明白违反许可证会危害企业和每个人的利益。

同时，文化需要通过流程来避免人为疏忽。

流程制定

流程制定是实现许可证安全合规的关键。企业内部需要根据自身情况制定应对许可证安全合规的响应流程，诸如：

• 明确对应不同许可证应该采取何种策略；

• 如何自动检测软件代码变更所带来的许可证合规风险；

• 一旦发生违反许可证合规事件，如何及时、正确应对，避免进一步发酵等。

流程制定需要跨职能团队的协作，比如 OSPO、法务、DevOps 等部门和人员都需要一起协作制定出符合企业自身发展的安全合规流程。当然，好流程也需要工具协助落地。

工具选型

市面上用于保障许可证安全合规的工具很多，选择适合企业自身发展的工具是关键。但有一点需要明确：工具是手段而不是目的。使用工具是为了支撑安全合规流程能够自动、快速执行，不需要将大量精力花费在工具选择、安装、优化、运维等方面上。对于工具选择维度，应该从以下三个方面入手：

• 易用性：学习成本低；

• 可扩展性：方便和其他工具进行集成，打通数据流；

• 安全性：工具自身的安全性足够高。

最终达到以工具支撑流程，以流程助力构建 “人人为安全负责” 的企业文化。

极狐GitLab 许可证安全合规功能优势

---

许可证合规（License Compliance）是极狐GitLab DevSecOps 九大功能之一。其他几个分别为：依赖项扫描、SAST（包括 IaC 扫描）、DAST、敏感信息检测、容器镜像扫描、模糊测试（包括基于 API 与 Code Coverage 两种模糊测试）。

许可证合规功能在 11.0 版本引入，主要用来检测应用程序引入的外部依赖的许可证是否和自身的许可证策略相兼容，以此来安全合规的使用外部依赖，避免发生违反许可证合规的事件，给企业带来不必要的麻烦。

极狐GitLab 许可证安全合规功能具有以下优势：

➤ 一体化 DevSecOps 平台

许可证安全合规功能和源代码托管、CI/CD 无缝 “集成”。当有代码变更的时候，嵌入到 CI/CD 中的许可证安全扫描功能会自动进行许可证信息扫描，并最终展示到 Merge Request 中。一切操作都在同一个平台上进行，真正实现了安全测试手段 “左移” 与安全数据 “左移”。

同时，一体化 DevSecOps 平台让研发、安全、测试人员都基于一个平台协作，沟通效率大幅提升而成本相应降低。

➤ 简单易用，配置灵活

极狐GitLab 提供针对许可证安全合规的相关配置，能够将企业自身的许可证安全合规流程 “映射” 到极狐GitLab 对应功能上，通过强制配置的方式，让流程保障安全合规。诸如：

• 针对不同类型的许可证采取不同的使用策略（允许 “宽松型”，拒绝 “严格型”）;

• 配置许可证审核人员，当有问题出现时，需要一定数量的审批人来对“有问题”的许可证进行审核。

当然，最重要的是，极狐GitLab 许可证合规功能是可以嵌入到 CI/CD 中，实现许可证安全合规的持续自动化扫描，仅需数行代码即可完成 CI/CD 配置，而无需额外安装、学习、配置第三方工具。

➤ 透明性高，追溯性强

许可证扫描信息都展示在 Merge Request 与安全面板中，项目相关人员均可查看，通过透明性提升安全性。

此外，审核信息可追溯、可审计，可以从安全扫描结果回溯到对应的代码变更，找到“有问题”许可证引入的源头，以及 “有问题” 许可证被审核的信息。

极狐GitLab 许可证合规实践

---

极狐GitLab 许可证合规功能的实现原理为：

1. 利用自身的许可证扫描工具进行许可证信息扫描，出具许可证报告，对比目标分支和源分支之间的许可证信息，并将信息展示在 Merge Request 中；

2. 配合安全测试配置，判断变更代码的许可证信息是否符合企业许可证合规。

极狐GitLab 许可证合规扫描功能可以通过以下三步来开启：

配置许可证合规策略

前文提到了不同的许可证有不同的约束条件，比如 GPL 的 “传染性” 就让很多企业在使用 GPL 协议的第三方依赖时很谨慎，甚至禁止使用 GPL 协议的第三方依赖；而对于 “宽松型” 的 MIT 协议则没有那么多芥蒂，允许使用这类协议的第三方依赖包。这种针对不同许可证采取不同使用策略的方法，是为了确保应用程序研发过程中，对于许可证的使用是符合企业安全合规要求的。

可在极狐GitLab 的安全面板上，通过配置来实现上述功能：

在每个项目的安全与合规（Security & Compliance） → 许可证合规（License Compliance） 中可以通过点击添加许可证策略（Add License Policy）。比如将 “宽松型” 协议（诸如 MIT、Apache 2.0 等）设置为允许使用（Allow）；而对于 “严格型” 协议（诸如 GPL、LGPL、SGPL 等）设置为拒绝使用（Deny）。

上述配置策略最终会在 Merge Request 中展现出来，方便研发、安全等人员查看此次代码变更引入依赖的许可证信息。

配置许可证准入规则

许可证准入规则的配置能够为安全合规使用许可证额外加一层保障：当 Merge Request 中出现了拒绝使用的许可证信息，此时需要有审批人（Approver）来决定此次代码变更是否可以合入。如果在经过评估之后认为代码可以合入，则选择 “批准”，否则选择 “拒绝”。

可以在每个项目的设置（Settings）→ 合并请求（Merge Request）→ 合并请求批准（Merge Request Approve） 中通过点击 “启用”（Enable）来开启 License-Check 功能。

在出现的界面中填写需要核准的人数阈值（最少需要几人同意）与核准人员即可。

接下来只需要简单配置 CI/CD Pipeline 就可以开启使用了。

配置 CI/CD Pipeline

仅需两行代码即可将极狐GitLab 许可证合规扫描功能嵌入到极狐GitLab CI/CD 中，代码如下：

include:
  - template: Security/License-Scanning.gitlab-ci.yml

以检测 Python 代码中的许可证为例来演示整个过程。

对于 Python 代码中的许可证检测是通过 requirements.txt 文件或 Pipfile.lock 文件来实现的。

Source Branch 上的 requirements.txt 文件包含如下内容：

pycurl==7.45.2  # LGPL/MIT 协议

Target Branch 上的 requirements.txt 文件包含如下内容：

pytest==7.2.1      # MIT 协议
urllib3==1.26.14   # MIT 协议
Jinja2==3.1.2      # BSD License (BSD-3-Clause) 协议
flask==2.2.2       # BSD License (BSD-3-Clause)
requests==2.28.0   # Apache Software License (Apache 2.0)
rss2email==3.14    # GPL/GPL v2/GPL v3/LGPL
wurlitzer==3.0.3   # MIT 协议
pycurl==7.45.2     # LGPL/MIT 协议
Flask-Login==0.6.2 # MIT 协议

上述模块的选择，只是为了在多种协议的情况下，演示极狐GitLab 许可证合规功能。上述模块的许可证信息来自 PyPI · The Python Package Index。

接着创建 Merge Request 即可触发 CI/CD Pipeline，在构建成功后可以在 Merge Request 中看到许可证扫描信息：

所有模块及其依赖的许可证信息都扫描了出来，配合之前配置的许可证合规策略进行了分类展示，上述显示 Apache License 2.0 和 MIT License 是被允许使用的；而下图展示的信息显示 GPL 和 MPL 2.0 是被禁止使用的。

此时需要审批人员对于此次许可证扫描结果做出 “拒绝” 或者 “允许” 的决策。

极狐GitLab 许可证合规功能能够帮助研发团队在软件研发过程中严格遵守企业的许可证合规策略，让企业避免因许可证合规问题而造成经济损失，同时也能够以更加安全的方式给客户提供更加优质的软件，提升客户满意度。

当然，许可证合规只是保障软件安全的关键手段之一，需要同时配合其他安全手段来为应用程序研发过程构建坚固的安全防护体系。比如极狐GitLab 的其他 DevSecOps 功能。点击👉获取更多 DevSecOps 干货资料。