模型供应链安全不能在镜像签名顺利获得时结束。签名通常证明某个镜像摘要由受信主体签发、内容在签发后未改变，却没有自动证明运行时加载的模型文件、配置、依赖、挂载和节点状态都符合预期。容器启动后若允许高权限写入、动态下载模型或替换共享卷，实际环境就可能偏离已签名制品。

覆盖范围：面向模型构建、发布、容器平台与安全团队，聚焦从制品到运行时的完整性证据，不讨论具体攻击利用方法。

先说清镜像签名证明了什么

签名的对象通常是一个明确摘要的镜像或制品。验证顺利获得可以说明当前拉取对象与签名记录匹配，并满足企业设定的签发者、仓库或策略条件。它不能证明构建输入没有风险，不能证明模型文件一定包含在镜像内，也不能证明部署配置没有添加新的可变内容。

很多模型服务采用“基础镜像+启动时下载模型”或“镜像+共享模型卷”。前者签名覆盖运行代码，但模型权重可能来自另一个仓库；后者的模型文件在持久卷中，镜像签名完全看不到。启动脚本、环境变量、配置中心、插件和驱动也会改变最终行为。

所以，签名应被视为一段证据，不是最终安全结论。企业还要定义谁能签、签什么、何时撤销、准入如何验证，以及运行后哪些对象允许变化。

签名证明到哪里结束，运行时校验就从哪里开始

下图把制品来源、签名、准入、启动基线和运行时监测串成陆续在完整性链。阅读任务是标出每段的对象、责任人和回执，避免只在镜像仓库留下一个绿色状态。

制品阶段记录源码或构建输入、模型文件、依赖清单、构建任务和摘要；签名阶段绑定签发者与策略；准入阶段核对目标环境、签名、来源和部署声明；启动阶段生成实际镜像、模型、配置、挂载、权限与节点快照；运行时再观察文件、进程、网络、权限和配置漂移。

完整性链只要有一段不能把“预期对象”与“实际对象”关联，签名证据就无法延伸到正在运行的服务。不同工具可以分别承担这些环节，但应使用统一发布标识或可关联摘要。

模型文件、依赖和配置是三个主要可变面

模型文件可能内置于镜像、存放在对象存储、挂载共享卷或启动时下载。无论采用哪种方式，都应记录模型标识、版本、摘要、来源与允许环境。模型热更新需要明确切换过程、旧版本保留、回退和审计，不能因为无需重建镜像就跳过审批。

依赖包括系统包、语言库、插件、推理后端和启动时安装项。运行时动态安装虽然灵活，却让构建清单与实际环境分离。企业可以限制生产环境动态安装，或至少将下载来源、版本、摘要和执行者纳入启动证据。

配置与挂载同样重要。环境变量、密钥、启动参数、配置文件、模型卷和工具插件都会影响服务权限与数据路径。签名镜像若以高权限运行并挂载可写主机路径，攻击面仍然很大。最小权限、只读文件系统和受控挂载是常见方向，但具体设置需按工作负载验证。

准入检查要验证部署声明，不只查一个签名状态

部署前可以建立声明清单：允许的镜像摘要、模型摘要、配置版本、服务账号、权限、挂载、网络范围和目标环境。准入层将实际提交内容与声明比较，未知或缺失对象进入拒绝或人工复核，而不是默认继承开发环境的宽松设置。

以下证据适合在发布时一并保存：

表格不是要求保存全部原始内容。敏感配置可保存版本和摘要，调查时在受控权限下回到真源。关键是让发布和运行证据能指向同一版本。

运行环境被篡改，可能是合法变更失控

并非所有漂移都来自恶意行为。运维人员临时进入容器修复文件、启动脚本下载新依赖、配置中心热更新、共享卷被另一个任务写入，都会造成实际环境与发布基线不同。若这些动作没有审批和回执，安全团队只能看到变化，无法判断是否被授权。

运行时监测应优先关注高影响对象：可执行文件、模型摘要、启动参数、服务账号权限、关键挂载、外联目标和异常进程。告警要携带变更前后值、主体、时间、工作负载与发布版本。过度收集完整文件或内存可能引入新的敏感信息风险，需要按调查目的控制。

发现漂移后也不应一律立即终止。低风险、可解释变更可以隔离并复核；涉及高权限、模型替换或异常外联的服务可能需要停止流量、保留现场并回退。处置由安全、平台和业务共同决定，自动化负责按已批准规则执行。

例外和紧急修复不能脱离完整性链

生产故障时可能需要紧急修改配置或切换模型。与其迫使团队绕过控制，不如建立短期例外：明确工作负载、允许变更、操作者、时限、观察项和恢复基线。完成后重新构建或签发正式制品，撤销临时权限，并确认运行环境回到可证明状态。

例外期间的监测不应关闭。恰恰因为控制被放宽，需要加强行为记录和人工复核。例外到期仍存在漂移，应该继续隔离或升级，而不是自动把现状设为新基线。

平台能提供签名验证、准入、权限和监测能力，企业负责构建信任根、模型来源、发布审批、节点维护和事件响应。购买平台不会自动保证供应链安全，也不能替代对第三方模型和依赖的尽职评估。

用一次受控漂移检验发现、处置和回退

选一个非生产模型服务，记录镜像、模型、配置、挂载和权限基线。然后在批准范围内分别模拟配置变化、模型摘要变化或临时文件写入，观察准入或运行监测能否发现、告警是否关联发布版本、责任人是否收到通知，以及回退后基线是否恢复。

测试不需要尝试真实攻击，也不应包含敏感模型。结果要区分“预防成功、检测成功、处置成功、证据完整”，因为某项变化可能无法阻止，但能快速发现和隔离。若系统只告警却无法定位受影响版本，也不能判定闭环完成。

在 AI基础设施分类 可继续查看模型服务与平台运行相关内容。完成制品清单与漂移演练后，再结合实际发布链评估 AI解决方案 。

下一步：建立一个可验证的发布基线

从一个模型服务开始，为镜像、模型文件、依赖、配置、挂载和运行权限建立版本与摘要。把签名、准入、启动快照和运行事件用同一发布标识关联。再执行一次受控漂移，验证告警、隔离、人工判断和回退。最后将紧急变更纳入有期限的例外流程，避免合法修复长期变成未管理状态。

常见问题

模型文件和容器镜像是否需要分别校验？

取决于模型文件是否真正包含在镜像的已签名摘要中。如果模型权重内置且不在启动后替换，镜像摘要可以间接覆盖它；如果模型从对象存储下载、挂载共享卷或支持热更新，就需要独立记录来源、版本、摘要和授权，并在启动或切换时验证。

即使内置，也建议在制品清单中明确模型标识与镜像版本，方便调查和回退。分别校验不等于必须使用两套工具，而是保证每个可变对象都有可复核身份。还要关注分词器、配置、插件等伴随文件，它们也可能改变行为。验证顺利获得只证明对象匹配预期，模型本身的安全、质量和适用性仍需其他评估。

镜像签名顺利获得后还要检查哪些运行时对象？

至少检查实际加载的模型与依赖、启动命令、环境配置、服务账号权限、文件和卷挂载、网络目标、关键进程以及节点状态。这些对象可能不在镜像内，或能在启动后被高权限进程修改。具体监测范围应按业务影响和性能成本分级，避免无目的收集敏感内容。

同时要把对象关联到发布版本、工作负载、主体和时间。只看到“文件变化”但不知道来自批准热更新、紧急修复还是未知进程，告警很难行动。平台可提供监测与限制，运维团队仍要登记变更窗口，业务团队确认影响，安全团队定义升级条件。检查项越多不一定越安全，可执行的责任与回退更重要。

发现运行时漂移时应该立即终止服务吗？

不应一概而论。涉及模型被替换、高权限提升、异常外联或关键可执行文件变化时，可能需要快速停止流量、隔离工作负载并保留证据；低风险配置漂移或已批准但记录延迟的变更，可以先限制范围、复核来源并安排回退。自动终止关键推理服务也可能造成更大业务影响。

企业应提前按对象和影响定义处置等级：告警观察、隔离副本、停止新请求、回退版本或全面停服。处置前尽量保存发布标识、变更前后摘要、主体、进程和时间线，避免修复后无法调查。恢复条件由平台、安全和业务共同确认；不要把当前漂移直接吸收成新基线，否则完整性控制会逐步失去意义。