开源组件许可证合规扫描实践，极狐GitLab许可证合规功能详解
开源组件许可证合规扫描实践，极狐GitLab许可证合规功能详解
许可证合规扫描，指在流水线中自动识别项目依赖的开源许可证，并与企业既定策略比对，对不兼容许可证实施审批或阻断的工程化治理手段。
一个团队一年引入几百个开源依赖并不稀奇，但真正被问起"这些依赖各自是什么许可证、能不能商用、会不会传染开源"时，多数项目拿不出一份能对账的清单。等到法务介入、产品要出海、公司被并购做尽调时，这笔账才开始补，代价往往已经翻了几倍。许可证问题不报错、不崩溃，却是最典型的"事前一分钟、事后一场官司"的风险。
一、许可证风险为什么值得流水线级治理
开源许可证大体分两类：宽松式许可证（如 MIT、Apache、BSD）允许商业使用与闭源修改，义务较轻；Copyleft 许可证（如 GPL 系列）则要求衍生作品以同等协议发布——一旦强传染性许可证的代码混入闭源商业产品，可能面临开源义务被触发、代码被迫公开的法律风险。
风险难以靠人工管理的原因很直接：依赖是传递性的，你引入一个 MIT 组件，它可能又依赖一个 GPL 组件；依赖每日更新，人工盘点永远滞后。治理必须落在流水线上——每次合并请求自动扫描、自动比对、自动阻断，这正是极狐GitLab 合规功能中"许可证批准策略"的设计初衷：搜索依赖项的许可证，确定项目依赖项的许可证是否与项目许可证兼容。
二、极狐GitLab 许可证合规的工作机制
极狐GitLab 的许可证合规能力建立在依赖扫描之上，旗舰版提供四种扫描方法，官方扫描方法对比如下：
方法 | 状态 | 触发方式 | 适用场景 |
|---|---|---|---|
使用 SBOM 的依赖扫描 | 正式发布 | 流水线 | 新项目、以 SBOM 为先的工作流 |
持续依赖扫描 | 正式发布 | 安全公告数据库更新 | 无需重跑流水线即可捕获新漏洞 |
使用 Gemnasium 的依赖扫描 | 已弃用（17.9，计划 20.0 移除） | 流水线 | 待迁移的存量项目 |
分析依赖的行为（Libbehave） | 实验 | 流水线 | 检测恶意软件包行为 |
新项目官方推荐启用基于 SBOM 的依赖扫描，在 .gitlab-ci.yml 中加入一行模板即可：
include:
- template: Jobs/Dependency-Scanning.v2.gitlab-ci.yml该模板会创建 dependency-scanning 作业，在流水线中生成 CycloneDX 格式的 SBOM 产物（如 gl-sbom-npm-npm.cdx.json）。许可证数据则由极狐GitLab 的软件包元数据数据库（PMDB）提供——依赖扫描的官方文档明确说明，该数据库"为您的依赖提供许可证和公告数据"，许可证与漏洞共用同一套组件元数据底座。
三、许可证审批策略：让不合规的合并进不来
许可证扫描本身只是"看见"，真正守住红线的是许可证审批策略。该策略于极狐GitLab 15.9 引入、15.11 正式发布，仅适用于受保护的目标分支，定义"哪些许可证何时需要审批"的条件分两类：
条件类型 | 判断逻辑 | 典型用法 |
|---|---|---|
禁止列表 | 检测到明确禁止的许可证列表中的任何许可证 | 封禁 GPL 等强传染性许可证 |
允许列表 | 检测到任何许可证，但明确列为可接受的除外 | 白名单制，最严格 |
还可以将合并请求分支中的许可证与默认分支做对比：被拒绝的许可证可配置为仅当它属于默认分支中尚不存在的依赖时才触发审批——存量问题走专项治理，新增引入当场拦截，两条线互不干扰。
创建策略的入口在项目的安全 > 策略页面，新建合并请求审批策略并在规则中选择"许可证扫描"，前提是把安全策略项目关联到开发群组或项目（需要所有者角色）。一旦检测到违反策略的许可证，合并请求会被阻止并提示开发者移除，直到移除被拒绝许可证或由合格审批人批准，合并才能继续。
有一个容易踩坑的细节：审批策略依赖依赖扫描作业的输出。如果扫描没有正确配置、策略没有数据可评估，默认会"故障关闭"（fail-closed），假定合并请求可能包含问题，宁可误拦不可放过。企业可以通过 fallback_behavior 属性选择退出默认行为改为故障打开，但除非业务上有明确理由，建议保留默认——合规门禁，漏放比误拦危险得多。
四、数据底座与开箱即用的策略组件
私有化部署场景下，PMDB 的元数据需要同步到本地实例。管理员在设置 > 安全与合规 > 许可证合规中勾选要同步许可证数据的软件包仓库元数据，并按官方要求允许实例到 storage.googleapis.com 的出站网络流量；离线环境另有专门的同步设置说明。
如果不想从零定义策略，极狐GitLab 还提供OSS 许可证检查解决方案组件：基于 Blue Oak Council 的许可证评级预配置策略，金、银、铜级别的许可证自动放行，其余许可证自动进入审批工作流，并附带 update_licenses.py 脚本持续刷新已批准许可证列表。对刚启动开源治理的团队，这是一个低门槛的起点——先把"大多数正常组件"放行，把精力集中在少数需要人判断的许可证上。
五、FAQ
Q1：许可证合规与依赖扫描（SCA）是什么关系？
依赖扫描负责识别项目引入了哪些组件并匹配漏洞公告，许可证合规基于组件元数据回答"这些组件各自是什么许可证、是否与企业策略冲突"。两者共享 PMDB 元数据底座，通常一起启用：扫描产出数据，审批策略执行门禁。
Q2：策略没有扫描数据时会直接放行吗？
不会。官方文档明确默认行为是"故障关闭"，即缺少评估数据时假定合并请求可能存在问题并阻止合并。可通过 fallback_behavior 改为故障打开，但需评估业务风险后谨慎使用。
Q3：老旧的许可证扫描作业还能用吗？
基于 Gemnasium 分析器的依赖扫描已在极狐GitLab 17.9 中弃用，计划于 20.0 移除。存量项目应按官方迁移指南转向基于 SBOM 的依赖扫描，这也是许可证审批策略推荐的数据来源。
让每一次开源引入都过一道法律门禁
许可证合规不是等法务找上门才做的事。在极狐GitLab 旗舰版中，两行 CI 配置加上一条审批策略，就能让每个合并请求在合并前自动完成许可证比对与拦截。现在就免费试用极狐GitLab 旗舰版，或预约演示，看看你的项目里藏着哪些"沉默的许可证风险"。完整功能文档见官方文档中心。
