GitHub 如何利用新许可合规工具管理开源依赖

GitHub 工程师日常会将新依赖引入平台、内部应用及开源项目，而负责任地使用开源需遵守相关许可义务。GitHub 开源项目办公室（OSPO）采用新的 GitHub License Compliance 功能来管理数千个依赖。该功能面向 GitHub Advanced Security 客户，可在拉取请求中直接审查新依赖，确保其许可符合组织政策，并能灵活扩展政策以允许新许可或单个项目。两个月前，GitHub 的 OSPO 从内部构建的合规管理工具迁移至该新功能，作为早期采用者提供了反馈。GitHub 原有可接受许可列表作为初始政策，常见的宽松许可如 MIT、Apache 2.0 和 BSD-3-Clause 是良好起点。最初在组织范围规则集上以“评估”模式推出，在拉取请求中生成注释但不阻止合并，让开发者适应新工作流，同时并行运行新旧工具以观察行为差异，约一个月后，警报主要针对具有异常、缺失或明确禁止许可的包。许可合规检查通过规则集启用，通过自定义属性确定仓库是否启用“活跃”或“评估”模式。在目标仓库中，修改项目依赖的拉取请求会触发扫描，检查新依赖的许可。若许可已被允许或有特定包例外，检查通过；若直接或传递依赖存在问题，工具会在拉取请求上评论并针对每个有问题的包发出警报。开发者审查警报后，若认为依赖不可接受，可更新代码或关闭拉取请求；若认为许可或包应被允许，可提出例外请求，通知组织内特定团队决定是否及如何修改政策。GitHub 的许可政策团队由 OSPO 成员和具备许可审查与供应链分析专业知识的工程师组成，成员分布在不同时区以便及时审查警报，目前正在制定审查许可请求的 SLA，实际分类处理时间通常不超过几小时。团队成员通过电子邮件接收新审查请求通知，也可通过仪表板查看待处理请求积压情况。批准请求时有两个决策点：是否允许许可或包，以及确定适用范围（企业或仓库级别）。对于之前未出现的安全许可，会在企业级别添加；对于商业许可，若仅特定团队付费使用，则在仓库级别添加例外。包例外对通常无许可数据的内部软件很有用，工具支持包例外的通配符匹配，例如允许 @github-ui/* React 命名空间下的所有内容，无需逐个批准。为支持此流程，GitHub 制定了联系 OSPO 及使用紧急“突破限制”覆盖的程序。紧急覆盖适用于时间敏感的关键拉取请求，通过切换规则集所依据的自定义属性值，可暂时关闭许可政策执行，目前仅使用过一次。此外，还提供内部文档和培训，帮助开发者理解许可合规的重要性。GitHub Enterprise Cloud 客户可在拥有活跃 GHAS Code Security 许可的仓库中使用 License Compliance 功能。