3. 供应链安全威胁建模
供应链安全治理的起点不是买工具，而是把“威胁”说清楚。威胁建模（Threat Modeling）就是一套把模糊担忧转化为可核查威胁清单的方法：先界定系统边界与信任假设，再枚举攻击者可能利用的路径，最后用统一语言描述威胁、评估影响并给出缓解措施。本节围绕供应商入侵、软件供应链投毒、硬件植入、服务滥用、第四方依赖五类典型场景，说明如何用 STRIDE 与攻击树（Attack Tree）建立威胁模型并输出威胁清单。
一、先划边界：把“我们”和“供应商”之间的信任面画出来
威胁建模的第一步是确定建模对象。对供应链而言，建模对象通常不是单个应用，而是“组织—供应商—第四方”的交付链。需要明确三类边界：资产边界（代码仓库、构建流水线、制品库、镜像仓库、生产集群、密钥管理系统）、信任边界（哪些外部主体被授予了何种访问权，如供应商运维账号、CI 令牌、制品签名密钥、API 网关白名单）、数据流边界（源码、依赖包、二进制、配置、日志、遥测数据在各方之间的流向）。
一个可操作的判断标准是：凡是“由外部产生、被我们信任、并进入我们系统”的对象，都是供应链威胁的入口。典型对象包括：第三方库与容器基础镜像、供应商提供的 SDK 与固件、SaaS 服务返回的数据、第四方 CDN 或 DNS 解析结果、外包团队提交的代码与构建脚本。
二、用 STRIDE 做“威胁分类器”，避免遗漏
STRIDE 把威胁分为六类：仿冒（Spoofing）、篡改（Tampering）、否认（Repudiation）、信息泄露（Information Disclosure）、拒绝服务（Denial of Service）、权限提升（Elevation of Privilege）。在供应链场景中，它可以直接映射为具体问题：
- 仿冒：攻击者伪造供应商身份提交代码、伪造制品签名、冒充运维人员登录供应商通道。
- 篡改：依赖包在传输或仓库中被替换、构建脚本被注入恶意命令、固件被改写。
- 否认：供应商否认曾发布某版本、外包人员否认提交过某段代码，缺少可验证的签名与审计日志。
- 信息泄露：供应商侧日志、构建缓存、制品元数据泄露内部拓扑或密钥。
- 拒绝服务：关键 SaaS 或 CDN 被攻击导致业务中断，或依赖仓库不可用导致构建失败。
- 权限提升：供应商的低权限账号通过 CI 配置、制品库权限或共享密钥横向移动到生产环境。
STRIDE 的价值在于“逐类过一遍”，它不替代攻击树，而是保证分类完整。实际建模时，建议对每个信任边界分别做一次 STRIDE 扫描，再合并去重。
三、用攻击树把“怎么被打”拆到可验证的叶子节点
攻击树以攻击者目标为根，逐层分解为子目标，直到叶子节点是可以直接观察或验证的具体动作。以“通过软件供应链投毒在制品中植入后门”为根目标，可分解为：
- 获取依赖发布权限 → 窃取 npm/PyPI 令牌、社工维护者、利用仓库漏洞。
- 绕过构建校验 → 篡改构建脚本、污染缓存、替换基础镜像、利用未锁定依赖版本。
- 规避检测 → 使用合法签名、延迟触发、混淆代码、只在特定环境激活。
- 进入生产 → 利用 CI/CD 凭据、制品库写权限、镜像拉取策略缺陷。
每个叶子节点都应能对应到一条可检查的控制项，例如“依赖版本是否锁定并校验哈希”“构建是否在隔离环境执行”“制品是否签名并在部署前验证”。攻击树的输出不是图，而是威胁清单：每条威胁包含场景、攻击路径、受影响资产、STRIDE 分类、可能性、影响、现有控制、建议措施与验证方式。
四、五类场景的威胁模型要点
供应商入侵：重点是供应商账号与通道。检查供应商是否使用独立账号、是否强制 MFA、是否有最小权限、是否记录其操作日志。典型威胁是供应商运维账号被钓鱼后直接进入生产。
软件供应链投毒：重点是依赖与构建。检查依赖是否锁定版本与哈希、是否使用私有代理仓库、构建是否隔离、制品是否签名。典型威胁是恶意包在安装脚本中执行反向 shell。
硬件植入：重点是设备来源与固件。检查设备是否来自可信渠道、固件是否校验签名、是否启用安全启动、是否有防拆封与序列号核对。典型威胁是固件被替换后持久化驻留。
服务滥用：重点是 API 与配额。检查供应商 API 密钥是否按环境隔离、是否有速率限制与异常调用告警、是否限制数据出境。典型威胁是密钥泄露后被用于批量拉取数据或产生高额费用。
第四方依赖：重点是“供应商的供应商”。检查第四方是否被纳入合同与审计范围、是否有替代方案、是否监控其可用性与安全公告。典型威胁是第四方 CDN 被劫持导致前端脚本被篡改。
五、威胁清单的字段与填写示例
威胁清单是威胁建模的最终交付物。建议字段包括：编号、场景、攻击路径、受影响资产、STRIDE 分类、可能性（高/中/低）、影响（高/中/低）、现有控制、建议措施、验证方式、责任人、复核周期。以下为一条示例（示例数据为教学假设，非实测结果）：
| 字段 | 示例内容 |
|---|---|
| 编号 | SC-TM-003 |
| 场景 | 软件供应链投毒 |
| 攻击路径 | 攻击者窃取 npm 发布令牌 → 发布恶意版本 → 构建流水线未锁定版本 → 恶意代码进入制品 |
| 受影响资产 | 制品库、生产镜像、CI 令牌 |
| STRIDE 分类 | 篡改（T）、权限提升（E） |
| 可能性 / 影响 | 中 / 高 |
| 现有控制 | 依赖版本已锁定，但未校验哈希；构建环境未完全隔离 |
| 建议措施 | 启用私有代理仓库并校验哈希；构建在隔离容器执行；制品签名并在部署前验证 |
| 验证方式 | 抽查构建日志与制品签名记录；模拟替换依赖包观察是否被拦截 |
| 责任人 / 复核周期 | 供应链安全负责人 / 每季度 |
六、建模过程中的常见偏差
第一，只画图不落清单。攻击树画得再漂亮，如果没有可核查的字段和验证方式，就无法推动整改。第二，把 STRIDE 当成流程步骤而不是分类器，导致逐类扫描流于形式。第三，忽略第四方。很多团队只审直接供应商，却不知道供应商自身依赖了哪些 CDN、DNS、日志与支付服务。第四，缺少“验证方式”字段，导致措施无法被检验。建议在每次建模后，至少挑选两条威胁做一次桌面推演或小范围验证，确认控制项真实有效。