合并前怎么拦住不合规的开源许可证
这篇讲依赖用了不合规的开源许可证时,怎么在合并前拦住。看完你可以在仓库 设置 → 安全 里打开许可证门禁和 未通过时拒绝合并,并到 AngusSecurity 策略里勾上 许可证合规,看允许名单和禁止名单在哪填。 仓库 xlliu/e2e-license-gate 的安全概览现在写着「许可证门禁未通过,拒绝合并」。许可合规页有两条开放发现,高危的 GPL-3.0-only 属于强互惠(分发软件时,要把相关代码也按同样的许可证公开),低
这篇讲依赖用了不合规的开源许可证时,怎么在合并前拦住。看完你可以在仓库 设置 → 安全 里打开许可证门禁和 未通过时拒绝合并,并到 AngusSecurity 策略里勾上 许可证合规,看允许名单和禁止名单在哪填。
仓库 xlliu/e2e-license-gate 的安全概览现在写着「许可证门禁未通过,拒绝合并」。许可合规页有两条开放发现,高危的 GPL-3.0-only 属于强互惠(分发软件时,要把相关代码也按同样的许可证公开),低危的 MIT 属于宽松(基本只要求保留版权声明)。
先登录 AngusGit,再打开仓库 xlliu/e2e-license-gate;你自己的仓库也从登录后的仓库列表进入。安全扫描在团队版、企业版和云服务中提供;社区版没有 安全 菜单。开始前先让扫描跑起来:系统管理员打开 管理 → 安全设置,页面标题是 AngusSecurity 集成,配置启用 为 已启用、平台可达 为 正常;还没开通时点 开通集成。页面要求 angus.git.external-security.enabled=true 时,把环境变量 ANGUS_GIT_EXTERNAL_SECURITY_ENABLED 设为 true 并重启 AngusGit。仓库管理员再到该仓库 设置 → 安全,打开 本仓自动安全扫描 和 许可证合规,保存后提示「安全设置已保存」。对照本文时按仓库里已经保存的设置来看即可,不必再点 保存、立即扫描 或 立即执行。
1. 先弄清「不兼容」是怎么判断的
AngusGit 仓库设置里的许可证门禁有三项:不兼容时拒绝 和 无法判定也拒绝 会拦住合并,选 不启用 则不按许可证拦截。
勾上 AngusSecurity 策略里的 许可证合规 之后,允许名单、禁止名单和分发场景才会出现。判断顺序是:
- 禁止名单:依赖的许可证在禁止名单里,判为不合规。
- 允许名单:允许名单不为空时,名单以外的许可证都判为不合规。
- 分发场景:前两项都没有命中时,按软件怎么交付来判断。表单说明是:「GPL 在仅内部使用和 SaaS 下默认不算不兼容,分发二进制或容器镜像时算。AGPL 除了仅内部使用都算不兼容。」
分发场景没填时,按 分发二进制 判断:强互惠(GPL)在这种默认下算不兼容,宽松许可证(例如 MIT)算兼容。无法判定 指扫描没认出许可证;选 无法判定也拒绝 时,这类依赖也会挡住合并。
2. 策略里的名单要先打开许可证合规
AngusGit 投递的扫描默认走 AngusSecurity 策略 [System] GIT Inbound。策略详情编号是 378599664200187905。
详情页上能看到的是:
- 标题
[System] GIT Inbound,徽章 已启用,说明Auto-created for GIT inbound scans。 - 门禁阈值 是 高危,说明「出现高危及以上的发现即判定未通过」。
- 能力集 是 代码安全、密钥检查、依赖/制品漏洞。没有 许可证合规。
- 右侧概要:默认 否,创建时间 2026/08/03 12:02:29。
编辑页里 许可证合规 是一个复选框,说明是「依赖许可证是否合规」。没勾上时,允许名单、禁止名单、分发场景都不显示。这条策略目前没勾 许可证合规;勾上之后才会出现名单和分发场景,表单里的标识只是占位示例,不是这条策略已经保存的内容。
-
打开策略
在 AngusSecurity 侧栏进入 策略。列表说明是「配置检查门禁策略和默认阈值。」打开
[System] GIT Inbound,点 编辑策略。 - 勾上许可证合规 在 检测能力 里勾上 许可证合规。保存前先确认公司允许把许可证结论写进这条共用策略。
- 选分发场景 勾上之后才出现 分发场景:仅内部使用、SaaS、分发二进制、分发容器镜像。产品以安装包或容器镜像交付时,选后两项之一。不选则按分发二进制判断。
-
填名单(按需)
允许名单 和 禁止名单 填 SPDX 标识,逗号分隔。表单占位分别是
MIT, Apache-2.0, BSD-3-Clause和AGPL-3.0, SSPL-1.0。同一个许可证不能同时出现在两个名单里。允许名单一旦不为空,名单以外的许可证都判为不合规。 - 保存 保存后对之后的检查生效。已经写在拉取请求上的状态检查不会自动重算。
内置目录没有收录的许可证,可以在 策略 页的 自定义许可证 页签里添加,标识用 SPDX 标识或 LicenseRef-*。内置目录已经能认出 GPL 时,不必先去这个页签。
3. 在 AngusGit 里打开检查和门禁
仓库自己的开关在 设置 → 安全,地址是 ?tab=settings§ion=security。xlliu/e2e-license-gate 现在的表单是:
截图里能看到的开关:
- 代码安全、密钥检查、许可证合规 开着。依赖/制品漏洞、代码质量 关着。
- 未通过时拒绝合并 开着。
- 漏洞门禁阈值 是 高危。许可证门禁 是 不兼容时拒绝。
详情页顶上的能力点只点亮了 密钥检查 和 许可证合规,设置页的 代码安全 开关却是开的:两处读的不是同一组字段。打开页面对照即可,不必为了让两处一致而立刻保存。
许可证合规 的说明是「识别依赖许可证,并按门禁决定是否拒绝合并。」如果设了许可证门禁、却没打开这项能力,页面会提示:「许可证门禁已启用,但没有打开「许可证合规」检查。打开拒绝合并后,PR 会因为缺少许可证结论而无法合并。」
只设许可证门禁、不打开 未通过时拒绝合并,结果会记下来,但不会拦住合并。许可证门禁选 不启用 时,策略里的名单只用于展示风险。
4. 这个仓库现在的结果
安全详情在 https://git.anguskit.com/security/repos/xlliu/e2e-license-gate。概览分数 95,严重、高危、中危、低危、信息、密钥、质量都是 0,许可风险 是 1。默认分支显示 main@d3ebc5a。
红字是「门禁建议: 未通过」,下面一行是「许可证门禁未通过,拒绝合并」。已有开放发现时,先看这些发现即可,不必马上点 立即扫描。
许可合规 页签、处置状态 开放,共 2 条:
| 级别 | 标题 | 类别 | 位置 |
|---|---|---|---|
| 高危 | GPL-3.0-only in e2e-with-gpl |
强互惠 |
package.json,组件 [email protected]
|
| 低危 | MIT in e2e-with-gpl |
宽松 | LICENSE |
高危那条的分支是 e2e-git07 @591d671,处置状态 开放,说明是 Declared by project manifest。抽屉里可以点 在代码中查看 或 在安全台打开;只是查看结论时,保持处置状态为 开放 即可。
页面上的许可证类别还有公有领域、弱互惠、网络互惠、专有、未识别、禁止使用。这条 GPL 显示的是 强互惠。
拉取请求上的状态检查认的是该提交最新一次扫描,文案有三种:
- 许可证没过:「许可证门禁未通过」。
- 漏洞和许可证都开着并且都过了:「提交 {提交号前 8 位} 的漏洞门禁与许可证门禁均已通过」。这个仓库已合并的 #1、#2 就是这句。
- 只记了漏洞门禁:「提交 {提交号前 8 位} 的漏洞门禁已通过」。
拉取请求 #4 e2e X-03 GPL merge gate(e2e-x03 → main,已合并)现在是第三种。链接是 https://git.anguskit.com/pulls/xlliu/e2e-license-gate/4。
同一提交 d3ebc5a 上,更早的推送扫描里许可证门禁是失败;后来一次手动扫描把许可证标成跳过,门禁按最新一次记成通过。所以 #4 这行没有写成「许可证门禁未通过」。概览仍写着拒绝合并,是因为开放的 GPL 发现还在,仓库设置里的许可证门禁也还开着。已经合并的检查行不会因为后来改设置而重算。要按新阈值重算,需要对分支重新扫描。
被拦住之后,常见处理是换成许可证合适的依赖。法务确认可以用的,再由管策略的人把它放进允许名单,或改分发场景,然后推送新提交。改名单只影响之后的检查。
5. 最容易配错的地方
| 你看到的 | 原因 | 怎么处理 |
|---|---|---|
| 「许可证门禁已启用,但这次检查没有包含许可证合规」 | 打开了许可证门禁,但没有打开 许可证合规 | 在 设置 → 安全 打开 许可证合规,再推送一次 |
| 几乎所有拉取请求都提示「许可证门禁未通过」 | 允许名单不为空,但漏写了常用许可证 | 补全允许名单,或者改用禁止名单 |
| 引入了 GPL 依赖却没有被拦 | 分发场景是 仅内部使用 或 SaaS。这两种场景下,强互惠默认不算不兼容 | 按实际交付方式选择分发场景,或者把该 GPL 标识加进禁止名单 |
| 策略详情里看不到允许名单 | 许可证合规 没勾上,名单不会出现 | 编辑策略并勾上 许可证合规。勾上之前先确认这条策略是仓库共用的 |
| 改了名单,已合并的拉取请求结论没变 | 新规则只对之后的检查生效,状态检查认最新一次扫描 | 推送新提交,或对源分支重新扫描 |
| 概览写拒绝合并,拉取请求却是成功 | 开放发现还在,但该提交最新一次扫描把许可证标成了跳过 | 看扫描历史里同一次提交的推送扫描和手动扫描,不要只看合并请求上的一行 |
常见问题
许可证门禁和漏洞门禁要分开配吗?
两者分开判断,都在 合并门禁 里,由 未通过时拒绝合并 决定是否拦截。打开拒绝合并之后,漏洞门禁一定会参与,阈值没有「不启用」。这个仓库的漏洞阈值是 高危,当前严重到低危的数量都是 0。只想主要管许可证时,把漏洞阈值调到 严重。
这和代码溯源有什么区别?
许可证检查看的是依赖声明了什么许可证。代码溯源看的是这段代码和别的仓库像不像。两件事分开做。
每个仓库的名单能不能不一样?
允许名单、禁止名单、分发场景在 AngusSecurity 的策略上。AngusGit 投递的扫描共用 [System] GIT Inbound 时,名单对走这条策略的仓库相同。每个仓库可以各自打开许可证合规、选择 不兼容时拒绝 或 无法判定也拒绝,并决定是否拒绝合并。这个仓库就是自己开了许可证门禁;系统策略的能力集里目前没有许可证合规。
小结
xlliu/e2e-license-gate 的仓库设置已经打开 许可证合规,许可证门禁是 不兼容时拒绝,并且打开了 未通过时拒绝合并。开放发现里的 GPL-3.0-only 是强互惠;分发场景没填时按二进制分发,这种许可证算不兼容。概览因此写着「许可证门禁未通过,拒绝合并」。
策略 [System] GIT Inbound 的能力集目前是代码安全、密钥检查、依赖/制品漏洞,门禁阈值是高危。允许名单和禁止名单要等勾上 许可证合规 才会出现。这条策略目前没勾、也没保存名单。已合并的 #4 状态检查是「提交 d3ebc5ab 的漏洞门禁已通过」,因为它认的是后来那次跳过许可证的扫描。
安全扫描在团队版、企业版和云服务中提供。社区版没有这条门禁。
结论: 仓库设置里同时打开许可证合规、不兼容时拒绝和未通过时拒绝合并,不合规的许可证会记进安全概览并建议拒绝合并。允许名单和分发场景在 AngusSecurity 策略里,要先勾上许可证合规再填写,保存后只对之后的扫描生效。
参考文章
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.
![策略 [System] GIT Inbound:门禁阈值高危,能力是代码安全、密钥检查、依赖/制品漏洞](https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fyf8ko2o8gbyim678t15e.png)



