企业如何建立软件供应链安全防线：从依赖管理到发布审核的落地清单

很多企业把软件供应链安全理解成“扫描一下依赖漏洞”，但真正容易出问题的地方，往往不是某个漏洞有没有被发现，而是依赖从哪里进入、谁批准使用、构建过程是否可信，以及最终发布的制品是否与审核对象一致。要建立可持续的防线，研发、安全、平台和发布团队需要把这些环节连成一条可追溯的流程，而不是各自维护一份孤立的检查表。

先把供应链边界画清楚

第一步不是购买扫描工具，而是明确“什么东西会进入软件交付链路”。应用代码只是其中一部分，第三方库、传递性依赖、构建工具、容器镜像、基础镜像、部署脚本、生成的二进制文件，以及研发流程中使用的外部服务，都可能影响最终软件。

对于涉及人工智能的应用，还应把模型文件、模型运行时依赖、数据处理组件和智能体相关配置纳入同一套治理视角。这里不必一开始就追求覆盖所有系统，但至少要能够回答四个问题：某个生产制品包含哪些组件？这些组件从哪里获得？谁批准它们进入项目？如果风险发生，谁负责处置？

建议企业先建立一份统一的组件与制品清单。它不只是漏洞扫描结果，而应同时记录组件名称、版本或唯一标识、来源、所属项目、许可证信息、维护状态、使用场景和责任团队。对构建产物，则应保留其对应的源代码版本、依赖清单、构建过程信息和审核记录。软件物料清单（SBOM）可以作为这类信息的重要载体，但不能把生成一份静态清单当成供应链安全的终点。

如果团队无法确认某个依赖是否已经进入生产，后续的风险分级和应急处置就很难准确展开。因此，资产可见性应当排在流程的最前面。

依赖进入之前：先审来源，再审用途

第三方依赖的风险不只来自已知漏洞。来源不明、维护状态不稳定、版本长期无人更新、许可证不适用，或者依赖在项目中承担了超出预期的权限，同样可能带来长期问题。

依赖引入流程可以按照“申请—评估—批准—锁定”推进。开发人员提出使用需求时，应说明组件解决什么问题、会被哪个服务调用、是否处理敏感数据、是否需要访问网络或文件系统，以及是否存在组织内已经批准的替代组件。安全或架构团队不必对所有低风险依赖进行同等强度的人工审查，但需要定义哪些情况必须升级处理。

例如，直接处理身份认证、支付、密钥、客户数据或生产环境连接的组件，应进入较高等级的审核；构建阶段使用、不会随应用进入运行环境的工具，也要记录用途，但审查重点可以放在来源可信度和构建权限上。对于传递性依赖，不能因为开发人员没有直接选择它，就完全排除在责任范围之外。最终制品包含什么，项目团队就应当对什么负责。

批准之后要避免依赖版本自动漂移。项目应保留明确的版本约束和完整的解析结果，使相同代码在不同时间构建时尽量得到可解释的依赖集合。必要时，可以将经过审核的组件和制品集中存放在受治理的内部仓库中，限制生产构建直接从不受控的公共来源获取内容。这样做的重点不是阻止开发使用开源软件，而是让组件进入企业后有统一的身份、来源和流转记录。

依赖检查至少覆盖四类问题

依赖检查不应只输出“有漏洞”或“无漏洞”两种结果。更有用的检查方式，是把发现的问题放回业务语境中判断：

• 组件是否来自可确认的来源，下载内容是否与预期一致；
• 当前版本是否存在已知安全问题，问题是否实际影响企业使用的功能；
• 组件是否长期无人维护，是否存在突然变更、名称混淆或来源迁移等异常；
• 许可证是否符合项目的交付方式，是否会给商业发布或二次分发带来约束。

这里的“发现”与“处置”必须分开。扫描系统发现风险后，项目负责人需要确认影响范围，安全团队负责给出风险判断和处置建议，架构或研发负责人决定升级、替换、隔离或接受风险。没有责任人的告警，数量再多也不会自动变成安全能力。

代码提交阶段：让风险尽早暴露

依赖治理应当尽量前移到代码提交和合并之前。提交阶段至少要检查依赖变更、锁定文件变化、构建脚本修改和新增外部下载行为。相比上线后才发现问题，这一阶段更容易找到引入者、理解变更目的，也更容易要求补充说明。

不过，提交检查不适合把所有问题都设置成“一票否决”。如果任何低影响告警都阻断合并，开发人员可能会绕过流程，或者在告警堆积后忽略真正重要的问题。更合理的方式是建立分级策略：高风险且与当前业务路径直接相关的问题阻止进入下一阶段；需要进一步确认的问题要求补充评估；低风险问题进入跟踪队列，并设置后续处理责任人。

风险等级至少应综合考虑以下因素：漏洞或异常的可信程度、组件是否处于运行路径、应用暴露范围、组件拥有的权限、是否涉及敏感数据，以及是否存在可用修复版本。单纯按照扫描结果排序，容易把一个不参与生产运行的开发依赖排在关键认证组件之前。

代码审查不能替代供应链审查

代码审查关注业务逻辑和变更质量，供应链审查关注代码之外的来源、构建和交付过程，两者需要配合。审查人员应特别留意以下变化：

• 新增或替换了外部依赖，但提交说明没有解释原因；
• 依赖版本被放宽，导致后续构建可能自动取得不同内容；
• 构建脚本新增外部下载、动态执行或权限提升行为；
• 发布配置改变了制品来源、仓库位置或审核条件；
• 依赖升级没有同步更新组件清单和风险记录。

这些变化不一定意味着恶意行为，但它们会降低构建的可解释性。规则的目标不是把开发流程变成安全部门独占的审批流程，而是让高影响变更有足够证据可查。

构建阶段：保护“可信的生成过程”

即使源代码和依赖都经过审核，构建环境被修改，最终制品仍然可能不可信。因此，企业需要单独保护构建流程，而不能默认“代码仓库安全，构建结果就安全”。

构建平台应采用最小权限原则。构建任务只获得完成当前任务所需的仓库、密钥和发布权限，开发人员不应通过普通代码提交直接取得生产发布凭据。用于构建和发布的身份凭证应尽量缩短有效时间，并避免长期、共享、无法追踪归属的秘密信息。构建节点完成任务后，应减少残留凭据、缓存和临时文件，避免下一个任务继承不应拥有的访问能力。

构建定义本身也应纳入版本控制和审查范围。任何能够改变编译、打包、签名、上传或发布行为的配置，都不能被视为普通辅助文件。对关键构建任务，应保留执行记录，包括使用了哪些源代码和依赖、由哪个流程触发、生成了什么制品，以及是否经过必要的检查。

在这个阶段，企业还需要建立制品来源证明。其核心不是增加一份漂亮的报告，而是让发布人员能够核对：当前制品确实由已审核的代码、依赖和构建流程生成，没有在中间被替换。软件物料清单可以帮助识别制品内部组件，构建记录则用于解释制品是如何产生的，两者应当关联保存。

发布审核阶段：审核“要上线的东西”

发布审核最常见的错误，是只审核版本说明和功能测试结果，却没有核对实际要上线的制品。安全审核应以最终制品为中心，而不是只看某次代码合并。

上线前可以按照以下顺序检查：

1. 确认制品的来源、版本和对应的源代码提交记录；
2. 核对制品中的直接依赖与传递性依赖是否已经生成清单；
3. 检查高风险问题是否已修复、隔离，或经过有权限人员批准接受；
4. 确认制品没有绕过规定的构建流程，也没有使用未经登记的外部内容；
5. 核对发布环境、运行权限和配置是否与风险评估一致；
6. 保存审核结论、例外理由、批准人和后续处理期限。

“发现问题但先上线”并不必然是错误，关键在于是否经过明确的风险接受。风险接受应写清楚影响对象、临时措施、责任人和复核时间，不能只在聊天工具里留下“先发了再说”。对于高影响组件，如果暂时无法升级，可以考虑限制暴露范围、收紧权限、关闭非必要功能或增加运行期监测，但这些措施只能降低风险，不能替代后续修复。

发布审核还要防止“最后一分钟替换”。如果审核的是一个制品，正式发布的就必须是同一制品，不能审核后重新构建一个看似相同的版本。对关键软件，应优先采用审核后直接晋级的方式，并保留制品唯一标识，确保测试、预发布和生产环境之间传递的是同一份内容。

用责任分工把流程闭环

供应链安全不能由单一岗位包办。比较实用的分工方式，是让每个团队对自己最熟悉的环节承担明确责任。

研发团队负责说明依赖用途、维护项目依赖文件、及时处理分配到项目的问题，并保证构建脚本和应用代码一起接受审查。平台或开发运维团队负责仓库、构建系统、制品库、身份权限和流水线策略，确保流程不会因人工操作而失去记录。安全团队负责制定风险分级标准、维护检测规则、协助判断复杂问题，并推动高风险事项闭环。架构团队负责处理重复引入、关键组件替代和跨项目共性依赖。发布负责人则负责确认最终制品满足上线条件，不能把“扫描通过”直接等同于“可以发布”。

对于每一类风险，记录中至少应有四个字段：发现者、处置负责人、批准人和截止时间。发现者不一定是修复者，批准人也不应默认是项目开发人员。这样才能避免告警在团队之间来回转移，却没有人真正负责结果。

建立持续运行的检查节奏

软件供应链风险会随着依赖更新、维护者变化、构建权限调整和业务架构变化而改变，所以一次性清点只能解决起点问题。企业可以把检查分成三个节奏。

在每次代码变更和依赖变更时，重点检查新增内容、版本变化、构建脚本和高风险组件。在每次发布前，重点核对最终制品、物料清单、风险例外和发布权限。定期治理时，则检查长期未处理的问题、无人负责的依赖、重复组件、失效账号、过期例外和不再使用却仍被保留的仓库内容。

衡量效果时，不要只看扫描出了多少问题。更值得关注的是：从发现到分级是否及时，责任人是否明确，高风险问题是否按期处置，发布制品能否追溯到构建过程，例外是否按时复核，以及出现紧急事件时能否快速查出受影响的项目。指标的目的不是制造更多报表，而是验证这条链路能否真正支持决策。

一份可直接落地的上线前清单

如果企业目前还没有完整体系，可以先从一条关键业务流水线开始，按下面的顺序建立最小闭环：

• 列出该项目使用的直接依赖、传递性依赖和构建制品；
• 为每个关键组件指定项目责任人和风险处置路径；
• 统一记录依赖来源、版本、用途和审核状态；
• 在代码合并前检查依赖变化与构建脚本变化；
• 对高风险问题设置阻断条件，对例外设置批准人和期限；
• 限制构建与发布凭据权限，保留构建执行记录；
• 为最终制品生成可追溯的组件清单；
• 发布前核对审核制品与生产制品是否一致；
• 将未解决问题、临时措施和复核时间写入发布记录；
• 发布后保留能够快速定位受影响项目的组件信息。

软件供应链安全的落地重点，不是把所有风险都交给一个扫描环节，而是让依赖管理、代码提交、构建生成和发布审核彼此衔接。研发团队知道什么必须说明，安全团队知道什么需要升级，平台团队能够控制流程，发布负责人能够根据证据做决定，企业才算真正建立起从代码进入到软件上线的安全防线。