软件供应链安全为何要前移到开发阶段：企业如何建立可追溯的组件体系？

【软盟资讯·新闻导读】软件供应链安全正在从“上线前做一次检查”，转向覆盖依赖引入、代码提交、构建、发布和运行维护的持续治理。企业使用的开源组件、第三方工具、基础镜像和构建服务，都会影响最终软件的安全性与合规性。对CTO、研发负责人和安全治理人员而言，真正需要建立的不是一套孤立的扫描工具，而是一套能回答“用了什么、谁批准、如何构建、发布到哪里、出现问题如何追溯”的工程体系。

软件供应链安全为何要前移到开发阶段，核心原因并不复杂：软件交付物不是从源代码凭空生成的，而是由依赖组件、开发工具、构建环境、配置文件、基础镜像和发布流程共同组成。任何一个环节缺少记录或控制，企业在上线后都可能无法准确判断风险范围，更难快速完成处置。

因此，软件供应链安全不应只是安全部门的单点任务。它同时涉及研发选型、运维环境、采购管理、法务合规和业务交付，必须转化为研发、运维与采购共同参与的工程治理问题。

软件供应链安全，究竟要管什么

软件供应链可以理解为一条从“组件进入企业”到“软件交付客户”的链路，至少包括五类对象。

第一类是依赖组件，包括开源库、商业软件包、第三方SDK、基础镜像和内部公共组件。现代软件大量依赖外部生态，组件数量和嵌套关系往往超出单个开发者的直觉判断。一个直接依赖可能还会带入多个间接依赖，最终进入生产环境的内容，未必都出现在项目负责人最初的清单里。

第二类是开发与构建工具，包括代码仓库、依赖管理工具、编译器、打包工具、持续集成平台和构建脚本。工具本身不等于软件功能，但它们能够影响源代码如何被编译、制品如何被生成，因此也属于供应链的一部分。

第三类是开源许可。组件治理不能只看是否存在安全漏洞，还要确认许可证类型、使用方式、修改情况、分发范围和义务要求是否匹配。安全团队发现“没有已知漏洞”的组件，并不意味着企业可以无条件使用；同样，许可证合规也不能替代安全评估。

第四类是构建与发布过程，包括构建环境、制品仓库、镜像仓库、签名机制、审批流程和发布渠道。如果同一份源代码在不同环境中构建出不同结果，企业就很难证明交付物来自受控流程。

第五类是版本与运行状态。一个组件在进入项目时可能没有风险，后续却可能出现新的安全公告、许可证变化或维护状态变化。组件治理必须能够把版本、制品、应用、环境和责任人关联起来，而不是只在项目启动时做一次登记。

为什么不能把安全检查只放在上线前

上线前检查发现得太晚

如果依赖组件直到上线前才接受检查，研发团队通常已经完成编码、联调和测试，组件更换会牵动接口、功能和交付计划。此时安全部门提出问题，容易被视为发布阻碍，团队也可能为了按期上线而采取临时豁免。

把检查前移到依赖引入和代码提交阶段，风险就会更接近决策源头。研发人员可以在选型时看到组件的维护状态、许可证要求和已知风险，安全人员也能在风险尚未扩散到多个项目之前介入。

风险会沿着依赖关系扩散

软件项目的风险并不只来自直接引入的库。间接依赖、构建插件、基础镜像和外部工具同样可能影响最终制品。只检查源代码目录或直接依赖清单，容易遗漏实际进入生产环境的内容。

这也是SBOM，即软件物料清单，具有工程价值的原因。它不是一张静态表格，而是对某个软件制品所包含组件、版本和关联关系的结构化记录。相关资料显示，SBOM通常还可以记录开源组件、第三方组件、补丁状态和许可证等信息。只有将清单与具体制品绑定，企业才有可能在风险出现时快速定位受影响的应用和版本。

事后追溯成本高于事前约束

当企业无法回答“某个版本到底用了哪些组件”时，安全事件或合规审查就会变成大范围人工排查。研发人员需要重新查看锁定文件、构建日志、镜像层和发布记录，甚至无法确认某个组件是否真的进入了生产环境。

前移治理的目标不是让每一次提交都变成复杂审批，而是把可自动判断的规则嵌入工具链，把必须由人决策的事项明确分级。这样既减少重复人工检查，也避免把所有问题集中到上线窗口。

一套可追溯的组件体系应包含什么

先建立统一组件目录

企业应先定义“什么算组件”，再建设清单。目录至少应覆盖：

• 开源库和间接依赖；
• 商业软件包与第三方SDK；
• 基础镜像、操作系统包和运行时；
• 编译器、构建插件及关键开发工具；
• 内部公共库和共享服务；
• 交付给客户的应用、镜像和安装包。

组件目录中的名称不能只使用团队内部简称，还应尽量记录生态名称、版本、来源、许可证、维护状态和所属系统。对于相同组件的不同命名，应建立归一化规则，否则同一组件可能在不同项目中重复出现，影响统计和风险判断。

用SBOM连接组件与制品

SBOM的关键不在于“生成一份文件”，而在于它能否回答三个问题：这份制品包含什么、这些内容从哪里来、它们最终被部署到哪里。

因此，企业应当以制品为中心生成和保存SBOM，而不是只在代码仓库中维护一份手工清单。每次构建都应关联源代码版本、依赖锁定状态、构建时间、构建环境、生成制品和发布目标。对容器化应用，还应关注基础镜像及其层级变化。

一份具有实际价值的记录，至少应能形成这样的关系：

源代码提交版本 → 依赖解析结果 → 构建任务 → 软件制品 → 发布环境 → 责任团队

这条链路越完整，企业越容易在组件风险变化时完成影响分析，也越容易区分“已经构建但未发布”“已经发布但未运行”和“正在生产运行”的不同处置优先级。

把版本固定与来源验证纳入构建流程

依赖版本如果长期使用浮动范围，构建结果可能随时间发生变化，问题排查也会变得困难。工程上应根据业务场景使用锁定文件、明确版本或摘要等方式，确保同一构建输入尽量得到可复现的结果。

同时，企业需要记录组件来源和构建来源。NIST关于软件供应链的资料将开源软件组件的完整性与来源证明视为相关治理的重要驱动因素。对企业来说，这意味着不能只记录“用了哪个包”，还要尽量确认组件从哪里获取、经过哪些仓库或代理、由哪一次构建进入制品。

这并不意味着所有企业都必须立即建立复杂的密码学体系，而是要先把来源、版本和构建过程记录下来，再逐步增加签名、验证和可信构建等控制措施。

风险分级：不要把所有问题都变成阻断项

组件风险不等于漏洞数量

组件风险应综合判断，至少包括以下维度：

1. 安全风险：是否存在已知安全问题，问题是否影响当前使用方式，是否已有修复版本。
2. 来源风险：组件是否来自可信渠道，是否存在来源不明、包名混淆或异常变更等情况。
3. 维护风险：项目是否持续维护，关键问题是否能够获得响应，企业是否过度依赖单一维护者。
4. 许可证风险：许可证是否与产品交付、商业模式和修改方式相容，相关通知和保留义务是否能够落实。
5. 业务风险：组件是否位于身份认证、支付、数据处理、核心交易等关键路径。
6. 暴露风险：组件是否进入互联网暴露系统，是否运行在高权限环境，是否涉及敏感数据。

这样的分级比简单地按照“有漏洞”和“无漏洞”二分更接近实际治理。一个低风险组件出现在核心生产系统中，处置优先级可能高于一个高风险但从未被构建和发布的测试组件。

建议设置分层处置规则

企业可以根据自身业务建立四级或三级处置模型：

• 禁止引入：来源无法确认、许可证明显不适配、存在重大且无法缓解的风险，或不符合企业基础控制要求。
• 限制使用：允许在特定场景使用，但需要安全负责人、架构负责人或法务共同批准，并设置替代计划。
• 整改后使用：存在可管理风险，要求升级版本、增加隔离、缩小权限或补充监控。
• 常规跟踪：风险可接受，但需要纳入持续监测和版本管理。

规则应尽量自动化。例如，依赖版本未锁定、SBOM缺失、制品没有构建记录，可以作为流程质量问题处理；许可证不明确、组件来源不可信或风险影响核心业务，则应进入人工评审。

把治理责任分配到正确的人

软件供应链安全之所以容易失效，常见原因不是没人关心，而是责任没有落到具体环节。

研发团队负责“正确使用”

研发团队最接近组件引入，应负责依赖选型、版本锁定、代码仓库配置和问题整改。团队不必独立承担所有安全判断，但必须能够说明为什么使用某个组件、在哪些服务中使用、是否有替代方案。

研发负责人还应把组件升级纳入正常迭代，而不是等安全部门发出通知后再临时处理。对于长期无人维护、重复功能过多或高度依赖单一外部项目的组件，应在架构评审中讨论替代和退出方案。

安全团队负责“规则与监督”

安全团队的重点不是替研发团队逐个审批所有依赖，而是建立风险模型、检测规则、例外流程和持续监测机制。安全部门需要明确哪些情况必须阻断，哪些情况可以带条件放行，以及风险接受由谁签字、有效期多长。

对安全团队而言，组件清单和SBOM的价值还在于提高响应效率。出现新的组件风险时，可以先通过清单定位受影响制品，再结合实际运行环境安排处置，而不是向所有项目发出模糊通知。

运维团队负责“制品与环境一致”

运维团队应确保上线制品来自受控仓库，发布版本与审批记录一致，运行环境中的镜像、系统包和配置变化可被记录。构建产物如果可以绕过制品仓库直接进入生产，前端的组件治理就可能被发布环节抵消。

运维还需要维护应用与环境的关联关系，特别是生产集群、边缘节点和长期运行的旧版本。软件供应链安全不能只关注“今天构建了什么”，也要知道“现在运行着什么”。

采购与法务负责“外部关系”

采购部门在引入商业软件、外包开发和第三方服务时，应将组件清单、漏洞通报、版本支持、许可证和退出机制纳入合同或交付要求。法务或知识产权团队则负责对许可证义务进行解释，避免研发团队仅凭名称或经验作出判断。

对于外包项目，企业不能只接收最终安装包，还应根据业务重要性要求交付依赖清单、构建说明、版本记录和必要的安全证明。否则，供应商交付完成后，企业仍然无法独立维护软件的供应链信息。

如何把DevSecOps落到实际流程

软件供应链安全不需要另起一套与研发完全割裂的系统，更适合嵌入现有DevSecOps流程。

在依赖引入时检查

开发者新增依赖时，系统可以自动检查组件是否存在已知风险、许可证是否符合规则、版本是否锁定、来源是否在允许范围内。低风险结果自动通过，存在不确定性的组件进入评审队列。

这一阶段的目标是减少“先用起来再说”的情况。越早发现组件不适配，替换成本越低。

在提交和构建时生成记录

代码提交和持续集成阶段，应自动解析直接与间接依赖，生成对应SBOM，并记录构建环境、构建输入和输出制品。构建失败不应只显示一个笼统的安全错误，而应告诉研发团队具体是版本、许可证、来源还是清单完整性不符合要求。

对于重要系统，还应保留构建日志和制品摘要，确保后续可以将发布版本与原始构建过程对应起来。

在制品发布时进行门禁

发布门禁不应只看扫描结果，还应检查制品是否具备完整的身份信息和关联记录，例如是否有对应的源代码版本、SBOM、审批记录和目标环境。

发布门禁也要支持例外流程。确需临时发布时，应明确风险、补偿措施、责任人和到期时间，避免“临时例外”无限期存在。

在运行阶段持续监测

组件风险会随时间变化，供应链治理不能在软件发布后结束。企业应持续关注组件版本、许可证状态、基础镜像和第三方服务变化，并将新的风险与应用清单、生产环境和业务重要性关联起来。

持续监测的结果应能够形成任务闭环：谁负责升级、影响哪些系统、什么时候完成、是否需要回滚，以及整改后如何验证。只有这样，安全告警才不会停留在信息通知层面。

企业建立组件体系的落地顺序

对于基础薄弱的企业，可以按三个阶段推进。

第一阶段：先看清楚

盘点主要应用、代码仓库、制品仓库和生产环境，建立最低限度的组件清单。优先覆盖面向互联网、承载核心数据和影响关键业务的系统，不必一开始追求所有历史项目一次性完整。

这一阶段的交付结果应包括：应用与责任团队对应关系、直接和间接依赖、主要基础镜像、制品版本以及当前缺失信息。

第二阶段：建立规则

围绕组件引入、版本锁定、许可证审核、制品发布和风险整改制定统一规则。将高风险判断嵌入代码仓库和持续集成流程，把人工审批集中到真正需要判断的事项上。

同时建立例外管理：例外原因、审批人、有效期限和替代计划必须可追踪。没有期限的例外，实际上就是永久放弃治理。

第三阶段：形成闭环

将SBOM、构建记录、制品仓库、运行环境和工单系统打通，支持从组件查应用、从应用查制品、从制品查构建过程，也支持从风险反查责任团队和生产影响范围。

在成熟阶段，企业还可以进一步推进可复现构建、制品签名、可信来源验证和供应商安全评估。但这些能力应建立在资产清晰、流程稳定和责任明确的基础上，而不是先购买工具再寻找应用场景。

软盟观察：供应链安全的关键不是“多一道扫描”

软件供应链安全前移，本质上是企业软件生产方式的一次调整。过去，安全部门往往在交付末端扮演“检查者”，研发团队负责把功能做出来，运维团队负责把版本发布出去，采购部门负责把外部软件买进来。这样的分工在组件数量较少时还能维持，但在开源依赖、云服务、容器镜像和外包交付高度交织的今天，任何一方都无法独立看完整条链路。

对CTO而言，最值得投入的不是先采购一套功能复杂的扫描平台，而是先建立统一的组件身份、制品身份和责任身份。企业需要知道某个组件进入了哪些应用，某个应用由哪次构建生成，某个制品部署在哪些环境，以及出现问题后由谁负责处置。没有这些基础信息，再多的告警也只能增加噪声。

对研发负责人而言，治理规则必须尽量靠近开发工具和交付流程，不能依赖人工记忆。版本锁定、自动生成SBOM、构建记录和发布门禁，应成为正常工程实践，而不是安全部门临时发起的专项活动。对安全负责人而言，真正成熟的策略不是把所有风险都阻断，而是按照业务影响、组件来源、许可证和运行环境进行分级，给团队一条清晰、可解释、可复盘的处理路径。对采购和法务而言，外部软件交付不能只验收功能，还应验收依赖清单、版本记录和持续支持责任。

因此，企业现在最合适的动作通常不是全面停工改造，而是选择一到两个关键系统试点：先生成可用的SBOM，补齐制品与环境关联，再把风险分级和责任闭环接入现有DevSecOps流程。等数据、流程和角色稳定后，再扩大到更多项目。软件供应链安全最终应成为软件质量和交付能力的一部分，而不是上线前突然出现的额外负担。

归根结底，软件供应链治理的判断标准只有一个：企业能否在较短时间内说清楚“用了什么、从哪里来、如何构建、发布到哪里、谁来处理”。如果答案仍然依赖个人经验和临时排查，安全就还没有真正前移。

对于正在推进数字化和云原生建设的企业来说，下一步应优先检查自身是否具备这条可追溯链路，而不是只问“有没有做过一次扫描”。只有把开源组件治理、SBOM、DevSecOps和责任机制连接起来，软件供应链安全才会从安全口号转化为可持续运行的工程能力。