从代码提交到生产发布：企业如何建立软件供应链安全防线？

当一次代码提交进入生产环境，真正需要保护的并不只是源代码本身。第三方依赖可能携带已知漏洞，构建环境可能被篡改，制品可能无法追溯，发布权限也可能被滥用。对于包含 AI 应用、模型调用组件或自动化编程流程的研发团队来说，软件供应链一旦失控，问题可能沿着依赖、构建和发布链路快速扩散。

软件供应链安全的重点，不是把所有安全工具都接入流水线，而是先明确每个环节要验证什么、由谁负责、出现异常后能否阻断，并且让这些检查能够持续运行。

先画清楚软件供应链的实际路径

一套可执行的防线，应该从企业真实的交付路径开始梳理，而不是从工具清单开始。通常可以沿着下面这条链路检查：

代码提交进入代码仓库后，会引用内部组件、开源依赖、基础镜像或外部服务；随后代码进入构建流程，生成可部署的制品；制品被保存、测试、签名或标记，最后由发布流程推送到测试、预发布或生产环境。

这条路径中的每一个节点都可能成为风险入口。依赖风险来自未经审查的第三方代码，构建风险来自不可信的执行环境或可被修改的构建过程，制品风险来自来源不明、内容不一致或缺少追踪信息，发布风险则常常与权限过宽、审批缺失和紧急操作失控有关。

如果团队无法回答“这个生产制品由哪次提交生成、使用了哪些依赖、经过了哪些检查、由谁批准发布”，就说明供应链还没有形成完整的可追溯链路。

防护顺序：先保证可见，再逐步阻断

企业不宜一开始就把所有检查都设置为强制阻断。更稳妥的方式，是按照“资产可见、风险识别、关键环节保护、发布控制、持续监控”的顺序推进。

第一步：建立依赖和制品清单

首先要知道系统实际使用了什么。清单不应只覆盖业务代码，还应包括直接依赖、间接依赖、构建组件、基础镜像、部署包以及与 AI 应用相关的 SDK、模型调用组件和数据处理组件。

清单的价值在于回答三个问题：

• 某个依赖被哪些项目使用；
• 某个生产制品由哪些源代码和依赖生成；
• 某个风险出现后，哪些应用需要优先处理。

依赖清单不能依赖开发人员手工维护，否则很容易随着版本变化而失真。应尽量从代码仓库、构建文件和制品生成过程自动收集，并将结果与具体项目、版本和发布记录关联起来。

对于企业内部组件，也要避免只把“开源依赖”视为供应链风险。内部共享库、公共构建脚本和基础镜像同样可能影响大量应用，应该按照影响范围纳入管理。

第二步：把依赖检查接入代码提交和构建流程

依赖检查的目的不是简单判断某个组件“安全”或“不安全”，而是帮助团队判断风险是否需要立即阻断。

检查至少应关注依赖来源、版本变化、已知风险、许可证要求以及是否存在未经批准的新增组件。对业务影响较大的依赖，不能只看单个漏洞信息，还要结合它是否会进入生产、是否暴露在外部访问路径、是否处理敏感数据等因素判断优先级。

在代码提交阶段，检查可以用于发现新增依赖和明显风险；在构建阶段，则需要再次确认最终实际进入制品的依赖内容。两者不能完全互相替代，因为开发配置与最终构建结果可能存在差异。

如果检查发现问题，团队需要提前约定处理方式。可以根据风险等级采取阻断构建、要求安全评审、限期修复或记录例外等措施，但例外不能只靠口头确认。每个例外都应说明原因、责任人、有效期限和后续处理计划。

构建流程要解决“产物是否可信”

代码仓库中的内容，并不等于最终部署到生产环境的内容。构建过程中可能引入额外依赖、脚本或配置，也可能因为执行环境变化而生成不同结果。因此，构建流程应尽量做到固定来源、过程可审计、结果可追溯。

控制构建环境

构建所使用的运行环境、依赖来源和脚本都应纳入管理。团队需要明确哪些组件可以进入构建环境，哪些外部来源需要审批，哪些构建步骤不得由个人临时修改。

构建权限也应与开发权限区分开。能够修改业务代码的人，不应自动拥有修改生产构建流程的权限；能够维护构建流程的人，也不应在没有审计的情况下直接绕过发布控制。

对于自动化程度较高的 AI 编程或代码生成流程，还要把生成代码视为普通代码进入同一套验证体系。生成方式不能替代代码评审、依赖检查和测试验证。尤其当生成结果自动引入外部库、构建脚本或配置时，更需要确认其来源和实际影响。

让制品成为发布的唯一依据

生产发布应尽量基于已经完成检查的制品，而不是在发布阶段重新拉取代码、重新解析依赖或临时构建。这样可以减少“测试过的内容”和“最终上线的内容”不一致的问题。

每个制品都应保留基本的关联信息，包括对应的代码提交、构建过程、依赖组成、检查结果和发布记录。制品一旦进入下一阶段，原则上应保持内容不变；如果内容发生变化，就应视为新的制品重新检查。

这项要求看似偏流程管理，实际是事故处置的基础。出现风险时，团队需要快速定位受影响的应用和版本，而不是重新猜测生产环境中究竟运行了什么。

制品管理要防止“来源不明”和“未经验证”

制品仓库不是简单的文件存储位置，而是软件供应链中的信任边界。企业应明确哪些制品可以进入仓库、哪些制品可以被部署，以及制品在不同阶段如何流转。

开发人员或自动化流程不应随意将未经识别的制品推送到生产使用的存储位置。对于外部获取的组件、基础镜像和内部共享制品，都应保留来源信息，并在进入正式交付流程前完成必要检查。

制品的命名和版本管理也应保持稳定，避免通过覆盖同名内容的方式修改已经验证过的制品。否则，发布记录显示的是一个版本，实际部署的却可能是另一份内容。

对高风险项目，可以进一步要求制品具备完整的完整性校验和可信标识，并在发布时验证这些信息是否一致。这里的重点不是增加复杂手续，而是确保发布流程能够识别“制品被替换”或“制品来源不一致”等异常情况。

发布权限要围绕职责分离设计

发布环节通常是软件供应链的最后一道控制点。如果任何拥有代码提交权限的人都能直接发布生产版本，前面的依赖检查和构建验证就很容易被绕过。

权限设计至少应区分以下几类职责：

• 代码维护者负责提交和修改代码；
• 构建维护者负责维护构建逻辑和执行环境；
• 应用负责人负责确认业务变更；
• 安全或平台团队负责制定检查策略和处理高风险例外；
• 发布负责人或授权流程负责批准生产变更。

具体角色可以根据企业规模合并，但关键权限不能无限集中在同一个人或同一个账号上。尤其是生产发布、发布规则修改、制品替换和安全检查绕过等权限，应单独管理并保留操作记录。

紧急发布也需要预先设计流程。真正紧急时，团队可以缩短审批路径，但不能完全取消记录、责任确认和事后复核。否则，“临时处理”很容易变成长期存在的绕过通道。

把检查清单分成三层，避免流于形式

企业可以把供应链安全检查拆成三个层次，使不同角色知道自己应该完成什么。

提交前检查

开发团队重点确认新增依赖是否有明确来源，代码是否引入不必要的外部组件，敏感配置是否被误提交，修改是否经过必要评审。

这一阶段的目标是尽早发现低成本可修复的问题，不宜把所有复杂判断都推给开发人员。检查结果应尽量直接关联到具体文件、依赖或变更，帮助团队快速处理。

构建前后检查

平台或 DevOps 团队重点确认构建环境是否符合要求，实际依赖是否与预期一致，构建脚本是否发生异常变化，生成的制品是否能够关联到源代码和检查结果。

如果构建结果与预期不一致，流程应能够暂停并保留现场信息，而不是直接生成一个无法解释的生产制品。

发布前检查

发布负责人重点确认制品是否来自受控流程，必要的检查是否完成，风险例外是否仍在有效期内，发布权限和审批记录是否完整。

发布前不应重复执行所有开发阶段的检查，而应重点确认前面已经完成的验证没有被绕过，且最终制品与已验证内容一致。

责任分工不能只写在制度里

供应链安全经常失败，并不是团队不知道风险，而是问题发生后没有明确的处理人。责任分工需要落到具体动作上。

研发团队负责维护代码和依赖的合理性，不能把所有问题都推给安全团队。DevOps 或平台团队负责构建、制品和发布流程的可靠性，不能只关注流水线是否“跑通”。安全团队负责制定风险标准、提供检测策略和推动高风险问题处置，但不应成为所有日常变更的人工审批瓶颈。

管理者需要解决跨团队问题，例如依赖升级影响业务、构建规则影响交付速度、生产权限需要收紧等。对于无法立即修复的问题，应由业务负责人参与风险接受，而不是由执行人员自行决定。

更实用的做法，是为每类检查指定一个主责团队和一个协作团队，并明确异常升级路径。这样当某个依赖出现风险、某个制品无法追溯或某次发布需要绕过检查时，团队能够迅速找到决策者。

持续监控应关注变化，而不是只做一次扫描

软件供应链风险会随着依赖更新、权限变化、构建流程调整和外部漏洞披露而变化。一次初始检查只能说明某个时间点的状态，不能代替持续管理。

持续监控可以围绕几类变化展开：依赖版本发生变化，生产制品来源发生变化，构建脚本或执行环境发生变化，发布权限发生变化，以及原本允许的风险例外超过有效期限。

监控结果不应只形成大量告警，还要能够关联到具体项目和责任人。对于同一个风险，如果每次都由安全人员手工通知，流程很难长期运转。更好的方式是将告警与项目负责人、制品版本和处理状态关联，并保留修复、接受风险或撤销发布等记录。

团队还应定期检查“是否存在绕过路径”。例如，是否有人直接使用未经验证的制品，是否存在未纳入统一流程的构建任务，是否仍有长期保留的高权限账号，是否有例外审批从未复核。这些问题往往比单次扫描结果更能反映防线是否真实有效。

适合企业落地的推进方式

如果企业目前还没有完整的供应链安全体系，可以先从生产影响最大的应用开始，而不是一次性覆盖全部项目。

第一阶段，完成代码、依赖、构建任务、制品和发布路径的盘点，先解决“看不见”的问题。第二阶段，把依赖检查、制品关联和发布审批接入主要项目，同时建立风险例外记录。第三阶段，再逐步收紧构建权限、完善制品可信标识，并将持续监控扩展到更多项目和内部组件。

每推进一个阶段，都要观察实际效果：风险是否更早被发现，发布是否仍能追溯，异常是否有人处理，检查是否频繁被绕过。如果安全控制让团队无法正常交付，通常说明规则没有区分风险等级，或责任与流程设计得不够清晰，而不一定意味着需要简单放宽所有检查。

软件供应链安全的最终目标，是让每次发布都具备清楚的来源、可验证的过程、受控的权限和可追踪的责任。企业不必一开始建立复杂体系，但必须先把代码依赖、构建过程、制品管理和发布权限连接起来，再通过持续监控让这条链路保持可信。