4. 开源合规治理组织与流程

开源合规不是安全团队一个部门的事。一个组件从被研发引入到最终对外发布，中间会经过选型、编码、构建、测试、发布、运维等多个环节，每个环节都可能引入或放大许可证风险。如果没有明确的角色分工和流程约束，合规工作就会退化成"出事之后再补救"。本节要解决的核心问题是：把开源合规从个人自觉变成组织能力，让每个关键节点都有明确的责任人、判断标准和留痕机制。

一、角色分工：谁在什么位置负责什么

开源合规治理通常需要四类角色，规模较小的团队可以一人兼多职，但职责边界必须清晰。

• 合规负责人（Compliance Owner）：通常是法务或专职合规岗，负责制定许可证策略、裁定高风险许可证的使用边界、审批例外申请。他是最终的风险裁决者，不负责日常扫描操作。
• 研发工程师（Developer）：组件的实际引入者，负责在引入前查询组件许可证、填写引入申请、在代码中保留必要的版权声明和许可证文本。他是风险的第一道关口。
• 安全/工具工程师（Security Engineer）：负责维护 SCA（软件成分分析）工具、配置扫描策略、生成 SBOM（软件物料清单）、对扫描结果做初步分级和去重，把真正需要人工判断的问题推送给对应角色。
• 发布经理（Release Manager）：负责在发布前核对合规检查是否通过，对未闭环的高风险项有权拦截发布。他是流程的"闸门"。

这四类角色的关系不是简单的上下级，而是一条带反馈的协作链：研发引入组件，工具自动扫描，安全工程师分级，合规负责人裁定，发布经理放行。任何一个环节缺失，风险都会向下游传递。

二、准入机制：组件进入项目前的三道判断

准入机制的目标是"事前拦截"，而不是"事后清理"。一个组件要进入项目，需要依次通过三道判断。

第一道：许可证类型判断。把许可证分为三档。宽松型（MIT、Apache-2.0、BSD）通常可直接使用，只需保留声明；弱传染型（LGPL、MPL）需要评估链接方式和修改情况；强传染型（GPL、AGPL）在闭源产品中默认禁止，必须走例外审批。判断依据是组件的 LICENSE 文件和源码头部声明，不能只看包管理器上的标签。

第二道：使用方式判断。同一个组件，静态链接、动态链接、独立进程调用、仅用于构建工具，对应的合规义务完全不同。例如 LGPL 组件在动态链接且未修改源码时，义务相对可控；一旦静态链接或修改源码，就可能触发源码开放义务。

第三道：替代方案判断。如果组件属于高风险档，研发需要说明是否有功能等价的宽松许可证替代品。只有在替代成本明显过高、且业务确有必要时，才进入例外审批。

三、审批流程与台账管理

审批流程要解决"谁有权批、批到什么程度"。建议设置两级审批：常规宽松许可证由研发负责人确认即可；弱传染型和例外使用强传染型组件，必须由合规负责人审批，必要时上升至技术负责人和法务会签。审批不是走形式，审批人要对判断依据负责。

台账管理是合规治理的"账本"。台账至少应包含以下字段：组件名称、版本号、许可证标识、引入项目、引入时间、使用方式、风险等级、审批状态、审批人、SBOM 关联标识、备注。台账不是一次性录入的静态表格，而应随每次构建自动更新——SCA 工具扫描出的组件清单可以直接写入台账，人工只需补充审批状态和风险裁定。

台账的价值体现在三个场景：一是发布前快速核对是否存在未审批的高风险组件；二是出现新的许可证漏洞或诉讼案例时，能快速定位受影响的项目和版本；三是对外提供 SBOM 时，台账就是数据来源。

四、跨部门协作模式

跨部门协作最容易出现的问题是"信息在部门边界处断裂"。研发知道引入了什么组件，但不知道许可证含义；法务知道许可证风险，但不知道哪个项目在用；安全团队能扫出组件，但无权决定是否放行。打通这三个断点，需要固定的协作节奏和统一的工具平台。

建议采用"例行 + 触发"两种协作模式。例行协作包括：每周合规例会同步高风险组件处理进展；每月更新台账和风险看板。触发协作包括：引入高风险组件时自动通知合规负责人；扫描发现新增强传染型许可证时自动创建工单；发布前合规检查未通过时自动通知发布经理和研发负责人。

工具平台是协作的载体。SCA 工具负责自动发现组件和许可证，工单系统负责流转审批和例外申请，代码仓库负责保留声明文件，CI/CD 流水线负责在构建阶段执行合规门禁。四者打通后，合规动作就嵌入到了研发流程中，而不是额外附加的负担。

五、把流程落到可执行的检查点

组织与流程最终要落到具体的检查动作上。以下检查点可以直接嵌入研发流程：

需要强调的是，流程的严格程度应与项目风险等级匹配。对外发布的商业产品、涉及核心竞争力的模块，应执行完整流程；内部工具、一次性脚本，可以适当简化，但许可证类型判断和台账记录不能省略。合规治理的目标不是制造障碍，而是让风险可见、可控、可追溯。

最后，跨部门协作能否持续，取决于是否有统一的语言和统一的工具。研发、安全、法务、发布对"高风险"的定义必须一致，对"审批通过"的标准必须一致，对"台账字段"的含义必须一致。这些一致性靠制度文件约束，靠工具平台固化，靠例行沟通维护。三者缺一，合规治理就会退回到"靠人盯"的状态，难以规模化。