软件供应链的风险，往往不在某一个开源组件本身，而在企业无法持续回答三个问题：代码和模型从哪里来，进入产品后由谁负责，出现漏洞或许可证冲突时如何处置。随着人工智能工具、开源项目和云端服务进入研发流程，开源治理已经从法务审核事项，转变为研发、采购、安全与交付共同承担的工程能力。
先建立可追踪的依赖账本
企业应对产品依赖的开源组件、模型、数据集和第三方工具进行统一盘点，保留来源记录、版本信息和使用范围。这里的重点不是简单列出名称，而是明确每项依赖被哪些产品和研发环节使用，是否经过修改，是否会随商业软件分发。
许可证审查也不能停留在“能不能用”。企业需要判断许可证对修改、分发和商业使用的要求，并将审查结果与产品交付边界对应起来。对于来源不清、维护状态不明或无法确认授权条件的依赖，应限制其进入核心产品，而不是等到发布前再被动补救。
把安全责任嵌入研发流程
开源治理必须与代码仓库、测试、发布和运维反馈衔接。企业需要持续关注项目维护活跃度、版本更新、漏洞响应以及对单一社区或单一维护者的依赖，并为组件版本锁定、漏洞修复和替换安排责任人。
人工智能生成代码和智能体应用进一步提高了治理要求。生成结果应经过人工复核、测试和安全检查；涉及核心业务、敏感数据或关键基础软件的任务，应设置明确的人工确认、操作留痕和回滚机制。工具能够提高研发效率，但不能替代责任边界。
将治理能力写进供应商评估
采购软件或算力、模型、工具一体化服务时，不能只看演示效果和功能数量。供应商应能够说明开源清单、依赖管理、漏洞处理、版本维护和持续交付安排，同时明确数据权限、日志留存、环境迁移和服务退出条件。
更成熟的做法，是把开源合规、安全响应、人工干预和维护周期纳入验收标准，并由研发、法务、采购和安全团队共同确认。开源治理的目标不是拒绝使用开源，而是在可追踪、可审计、可替换的前提下使用它，使技术开放不会演变为供应链失控。