2. 供应链安全威胁与攻击面分析

供应链攻击的本质，是攻击者不去正面突破防御严密的核心系统，而是沿着信任链向上游或下游移动，在某个防护相对薄弱的环节植入恶意能力，再借助正常的交付、更新或集成通道进入目标环境。理解这一点，才能把"供应商准入、开发、交付、运维"四个阶段看成一条连续的信任传递链，而不是四份彼此独立的检查表。

一、四个阶段的威胁建模

准入阶段的核心风险是"身份与资质失真"。攻击者可能注册空壳公司、伪造安全认证、借用他人案例投标，或通过收购一家已入库的小供应商获得准入资格。此阶段的可观测对象包括：营业执照与股权穿透结果、ISO 27001 或 SOC 2 报告的有效期与审计范围、实际办公地址与人员规模、历史安全事件与诉讼记录。建模时应重点回答：这家供应商能接触到我们的哪些数据、系统或代码？它的失陷会不会直接导致我方失陷？

开发阶段的风险集中在代码与构建环境。典型威胁包括：开发人员账号被钓鱼后向仓库推送后门、第三方依赖包被投毒（typosquatting、依赖混淆）、CI/CD 流水线凭据泄露、构建产物被篡改。此阶段的关键控制点是代码签名、依赖锁定（lockfile）、构建环境隔离与制品仓库的完整性校验。

交付阶段的风险是"运输途中被替换"。软件可能通过官网下载、镜像站、U 盘、邮件附件或自动更新通道送达。攻击面包括：下载页被挂马、更新包签名校验缺失、离线介质未做哈希核对、交付版本与测试版本不一致。判断依据通常是发布包的哈希值、数字签名链、SBOM（软件物料清单）与版本清单是否三方一致。

运维阶段的风险来自持续访问权。供应商远程运维账号、VPN 隧道、API 密钥、监控代理、备份通道都可能成为长期驻留的入口。此阶段应关注：权限是否最小化、会话是否可审计、离场后账号是否及时回收、供应商侧是否发生横向移动。

二、两个典型案例的根因对照

SolarWinds 与 Log4j 常被并列讨论，但它们的根因并不相同。SolarWinds 属于主动植入型攻击：攻击者先攻陷供应商的构建环境，把后门写进 Orion 平台的更新包，再用供应商合法的代码签名证书签名。客户看到的是"来自可信厂商、签名有效"的正常更新，因此几乎不会拦截。它的教训是：代码签名解决的是来源真实性，不解决构建过程完整性；必须把构建环境当作高价值资产隔离，并对制品做可复现构建或二次校验。

Log4j 属于被动暴露型风险：开源组件本身存在 JNDI 注入缺陷，任何使用该组件并记录用户可控字符串的应用都可能被远程利用。它的难点不在"是否知道漏洞存在"，而在"是否知道自己用了它、用在哪、哪个版本"。很多团队在漏洞公开后才发现，自己的产品通过三层传递依赖引入了 log4j-core，而资产台账里根本没有记录。因此 SBOM 与依赖清单不是合规装饰，而是应急响应的基础设施。

三、把威胁建模落到可执行动作

威胁建模不应停留在画图。对每个阶段，至少要产出一组可验证的判断条件。以下是一份可直接用于供应商评审的检查表示例，字段按"阶段—威胁—验证方式—判定标准"组织：

四、攻击面收敛的优先级判断

并非所有威胁都需要同等投入。可以用两个维度排序：可达性（攻击者能否实际触达该环节）与影响半径（一旦失陷会波及多少下游系统）。构建环境通常可达性中等但影响半径极大，应优先加固；离线交付介质可达性低，可按批次抽检；供应商远程运维账号可达性高且影响直接，应强制最小权限与会话审计。把资源压在高可达、高影响的位置，比平均用力更有效。

最后需要强调，供应链安全不是一次性准入审查，而是贯穿合作全周期的持续验证。准入时看资质，开发时看依赖与构建，交付时看完整性与清单，运维时看权限与行为。四个阶段的证据链能够互相印证，才构成真正可审计、可追溯的供应链信任基础。