许可风险与依赖治理

Category

server / security 子树。节点定位：第三方依赖与许可证是长期治理对象——开发期不盘点，融资、并购、出海、审查时说不清用了什么。

Definition

很多项目能接受代码里有技术债，却很少真正把第三方依赖和许可证风险当成长期治理对象。结果往往是：开发期为了快，先接了很多 SDK、库、素材和工具；等到上线、融资、并购、出海或合规审查时，团队才发现已经说不清到底用了什么、哪些能商用、哪些必须开源回传、哪些供应商一旦失联就会卡住发布。

Problem

技术债可以接受，依赖清单说不清不能：等到上线、融资、并购、出海或合规审查才发现哪些能商用、哪些必须开源回传、哪些供应商失联就卡住发布——依赖治理必须尽早做，事后盘点成本极高。

依赖风险为什么不只是法务问题

依赖治理之所以重要，不仅因为许可证义务，也因为它会直接影响技术稳定性和业务连续性：

• 第三方 SDK 可能崩溃、卡顿、泄露数据或改变接口
• 开源组件可能停止维护、爆出漏洞或升级破坏兼容
• 商业授权可能限制平台、地区、并发规模或二次分发方式
• 关键工具链如果无人维护，会直接拖住构建、发布和运营

也就是说，依赖风险既是法律问题，也是供应链问题和工程治理问题。

游戏项目为什么更容易依赖失控

游戏项目通常会接入大量外部能力，而且这些能力分散在客户端、服务端、运营后台和工具链中：

• 登录、支付、广告、推送、客服、统计 SDK
• 引擎插件、音视频库、反外挂组件、崩溃上报组件
• 图像、字体、音频、动效、地图和其他素材资源
• 构建脚本、热更新工具、打包插件和自动化平台

这些依赖一旦没有统一登记和版本策略，就会出现几个常见问题：

• 同一能力在不同项目接了不同供应商，维护成本持续上升
• 升级一个 SDK 牵出多个不兼容问题，却没人知道受影响范围
• 出现许可证争议时，团队无法证明素材或库的来源与授权范围

许可证问题最容易在哪些地方踩坑

• 把开源代码复制进项目但未保留许可证说明
• 使用带有强传染义务的组件却没有评估分发方式
• 商用素材、字体、音频的授权范围与实际发行平台不一致
• 外包、插件市场或论坛获得的资源没有清晰来源记录

很多坑不是因为团队故意违规，而是因为开发早期没有把依赖当成资产来管理。

更实用的依赖治理方式

对多数团队来说，依赖治理至少应该做到：

• 维护统一的依赖清单，包括版本、来源、用途、负责人和授权类型
• 对高风险依赖建立准入流程，例如支付、账号、广告、数据 SDK 和核心开源库
• 给客户端、服务端、工具链和素材资源分别做生命周期管理
• 在版本升级和漏洞修复时，知道哪些项目和模块会受影响

如果团队规模更大，还可以进一步做：

• 依赖分级和审批
• 许可证扫描与供应链安全扫描
• 替代方案预案，避免关键供应商单点失效

为什么依赖治理要尽早做

因为依赖一旦进入多个项目、多条发布链路和多个外包流程，再想回头统一会非常痛苦。相比之下，早期多花一点力气把来源、版本、授权和负责人记录清楚，成本低得多。

常见错误

• 只关心代码能不能跑，不关心依赖来自哪里、能不能长期用
• 第三方 SDK 接入由单个开发者决定，没有统一登记和升级策略
• 只管理代码库，不管理素材、字体、音频和外部工具授权
• 直到被审查、被投诉或要出海时才回头梳理许可证问题

许可风险与依赖治理真正成熟的标志，不是清单做得多漂亮，而是当某个库爆漏洞、某个 SDK 被下架、某个素材授权被质疑时，团队能迅速知道影响范围、替代路径和处理责任人。

实战案例：一次「出海审查，三天说不清用了哪些 SDK」的依赖盘点排查

案例为教学示例（非摘自真实项目），数字经过取整简化。它把本页「游戏项目为什么更容易依赖失控」「许可证问题最容易在哪些地方踩坑」「更实用的依赖治理方式」用到深水区：审查来了才发现说不清用了什么——这是依赖没当资产的排查，也是「怎样让影响范围与责任人随时可知」的完整展开。

背景与现象：某产品出海合规审查，团队三天说不清接了哪些 SDK、哪些能商用：盘点发现 2 个强传染组件未评估分发方式，1 个素材授权范围与发行平台不一致，审查延期 3 周。

第一步：现象与口径——先数说不清的是哪几类

清单口径：依赖无统一登记，客户端、服务端、运营后台、工具链各自接入，同一能力在不同项目接了不同供应商。

许可口径：2 个带强传染义务的组件没有评估分发方式，商用素材、字体、音频的授权范围与实际发行平台不一致。

授权口径：外包和插件市场获得的资源没有清晰来源记录，出现许可证争议时无法证明来源与授权范围。

第二步：分层归因——按本页踩坑点比对

依赖失控归因  占比
  依赖无统一登记与版本策略         52%
  许可证义务未评估，商用范围不清    30%
  素材与工具授权没管，来源无记录    18%

逐项比对：三天说不清用了什么——命中「第三方 SDK 接入由单个开发者决定，没有统一登记和升级策略」；强传染组件未评估——命中「使用带有强传染义务的组件却没有评估分发方式」；素材授权不一致——命中「商用素材、字体、音频的授权范围与实际发行平台不一致」。

第三步：根因——没把依赖当成资产来管理

很多坑不是因为团队故意违规，而是因为开发早期没有把依赖当成资产来管理。依赖一旦进入多个项目、多条发布链路和多个外包流程，再想回头统一会非常痛苦——开发期不盘点，审查期就要用三倍时间还债。

第四步：处置与回填——清单、准入、生命周期

1. 统一依赖清单：版本、来源、用途、负责人、授权类型逐项登记，客户端、服务端、工具链、素材资源分别建册。
2. 高风险依赖准入：支付、账号、广告、数据 SDK 和核心开源库走准入流程，强传染组件先评估分发方式再引入。
3. 生命周期管理：给四类依赖分别定升级与淘汰策略，版本升级和漏洞修复时按清单定位受影响项目和模块。
4. 替代方案预案：关键供应商单点失效有备选，避免某个 SDK 被下架就卡住发布。

复核账：审查延期 3 周 → 2 天出完整清单；2 个强传染组件完成评估并补许可证说明；素材授权对齐覆盖率 0% → 100%。

回填清单：

回填项	动作	回填处
统一依赖清单	版本/来源/用途/负责人/授权类型逐项登记	更实用的依赖治理方式
高风险准入	支付账号广告数据 SDK 与核心开源库走准入	更实用的依赖治理方式
许可证评估	强传染组件先评估分发方式，商用范围对齐发行平台	许可证问题最容易在哪些地方踩坑
素材来源记录	外包插件市场资源留来源与授权证明	游戏项目为什么更容易依赖失控

案例的三个教训

1. 依赖清单说不清，审查期要还债。开发期不盘点，出海审查用三天说不清用了什么。
2. 许可证义务要在引入时评估。强传染组件不分发方式就引入，后面补的是整个合规成本。
3. 素材与工具也是依赖。只管理代码库不管素材字体音频，授权争议一样卡住发行。

Used By

依赖与素材清单盘点；许可证合规检查；供应商风险评估。

Related

关系链：不只是法务 → 易失控原因 → 许可坑点 → 治理方式 → 尽早做 → 常见错误。上游：security/04（合规面）。下游：tools 树（工具链依赖，规划迁入）。

Reference

本页为工程经验归纳；页内实战案例为教学示例（数字取整简化）。