2. 云原生供应链的构成与威胁模型

云原生供应链并不是一条简单的“代码到镜像”流水线，而是一张由多个可独立演进的环节组成的依赖网络。要建立有效的治理策略，第一步是准确识别这些环节各自承载什么、信任边界在哪里、攻击者可以从哪里切入。本节围绕镜像、制品、依赖、构建工具、仓库、运行时六个关键环节展开，并给出典型攻击面与风险分类方法。

一、六个关键环节的职责与信任边界

源码与依赖是供应链的起点。除了业务代码本身，真正占据体积和风险大头的是第三方依赖：语言包（npm、PyPI、Maven、Go Module）、基础库、以及间接依赖（transitive dependencies）。一个典型 Node.js 服务，直接依赖可能只有 20 个，但展开后的依赖树常超过 800 个包。攻击者只需污染其中一个深层依赖，就能进入构建产物。

构建工具与构建环境负责把源码和依赖转换成制品。这里的关键对象包括 CI Runner、构建脚本、缓存目录、以及构建时注入的凭据。构建环境是权限最集中的位置：它通常同时持有源码读取权限、镜像仓库推送权限、以及云上部署凭据。一旦构建脚本被篡改，攻击者可以绕过所有源码审查。

镜像与制品是交付单元。镜像由基础镜像层、依赖层、应用层叠加而成，每一层都可能引入漏洞或恶意文件。制品还包括 SBOM、签名、证明（attestation）等元数据，它们本身也是需要保护的供应链对象。

仓库包括代码仓库与制品仓库（Registry）。仓库是分发枢纽，其风险集中在访问控制、镜像覆盖（tag 复用）、以及仓库间信任关系。

运行时是最终执行环境。即使镜像在构建时是干净的，运行时仍可能因为挂载、权限、网络策略或动态拉取而暴露风险。

二、典型攻击面与风险分类

把上述环节的攻击面按“攻击者位置”和“影响面”两个维度归类，可以得到一张实用的风险矩阵。外部依赖作者位于最上游，一次投毒可影响全部下游用户，典型手法包括 typosquatting（抢注相似包名）、依赖混淆（dependency confusion）、以及维护者账号被盗后发布恶意版本。这类风险的检测主要依赖 SBOM 生成与依赖锁定，治理重点是版本固定与来源校验。

内部构建环境的风险更隐蔽。攻击者可能通过被污染的构建脚本、恶意 CI 插件、或缓存投毒进入。由于构建环境通常持有推送凭据，一旦失陷，攻击者可以推送一个“看起来正常”的镜像。检测手段是构建日志审计与构建产物签名，治理重点是凭据最小化与构建环境隔离。

仓库维护者位置的风险集中在 Tag 覆盖与镜像替换。很多团队仍使用 :latest 或可变 Tag 部署，攻击者只要获得仓库写权限，就能用恶意镜像覆盖同名 Tag。防御的核心是使用 digest 引用镜像，并强制签名校验。

运行时入侵者位于最下游，但影响面可能最大。容器逃逸、Kubernetes API 越权、以及运行时动态拉取未校验的镜像，都会让前面的治理前功尽弃。运行时检测与准入策略是最后一道防线。

三、从威胁模型到治理动作

威胁模型的价值在于把“担心”转化为可执行的控制点。针对上述四类风险，可以建立如下对应关系：

• 依赖投毒 → 生成 SBOM、锁定依赖版本、校验包签名与来源。
• 构建环境失陷 → 构建环境无状态化、凭据短期化、构建产物签名。
• 仓库 Tag 覆盖 → 使用 digest 部署、开启镜像签名与准入校验。
• 运行时逃逸 → 最小权限、只读根文件系统、网络策略与运行时检测。

在实际生产中，建议先对现有镜像做一次基线盘点：统计基础镜像来源、依赖数量、是否存在可变 Tag、是否已有签名。以某示例服务为例，假设其镜像基于 node:18，依赖树展开后约 900 个包，其中 3 个包在近 12 个月内有过维护者变更。这类信息就是威胁模型落地的起点——它告诉你哪些环节需要优先加固，而不是平均用力。

理解供应链的构成与威胁模型，是后续策略治理、准入控制与可靠性设计的前提。只有先看清攻击面分布，才能把有限的治理资源投入到真正高风险的位置。