CI/CD 中的意图验证差距：为何身份验证在真实攻击下失败
Source: Dev.to
概述
现代 CI/CD 流水线建立在一个看似简单的假设之上：
如果一个操作来源于有效的会话令牌，则它必定来源于有效的人类意图。
这个假设听起来直观。工程师使用 SSO 进行身份验证，获取会话令牌，而这些令牌授权将代码部署到生产环境。如果令牌有效且用户拥有正确的角色，系统就会继续执行。
SolarWinds、Codecov 和 Log4j 表明，这一假设在实践中是错误的。
在这三种情况下，系统从 授权 角度来看都表现“正确”：
- 凭证是有效的
- 令牌是合法的
- 流水线按设计执行
然而，却导致了灾难性的后果。
Source: …
意图验证缺口
本文介绍了我所称的 意图验证缺口：现代 CI/CD 安全模型在区分 凭证拥有权 与 有意识的人类意图 时的结构性失效。该缺口并非理论上的概念——它正是现实世界高级持续性威胁（APT）所利用的攻击面。
随机信任模型
大多数 CI/CD 流水线遵循 随机信任模型：
- 用户在某个时间点进行身份验证。
- 会话令牌会持续数小时。
- 在该时间窗口内执行的操作被视为反映持续的用户意图。
该模型是 概率性的。它假设在令牌有效期间，用户仍然控制着其设备、网络和执行环境。而现代威胁模型打破了这一假设。
一旦恶意软件入侵终端，系统就无法区分：
- 人类有意部署代码
- 恶意软件使用相同的令牌部署恶意制品
从流水线的角度来看，两者是不可区分的：签名有效、角色正确，授权检查通过。这 不是实现上的 bug——而是信任模型本身的缺陷。
身份验证 vs. 意图
在安全术语中，我们区分：
| 概念 | 问题 |
|---|---|
| Authentication (AuthN) | 你是谁？ |
| Authorization (AuthZ) | 你被允许这么做吗？ |
AuthN 和 AuthZ 都没有回答第三个、更重要的问题：
人类是否在此时此刻有意识地打算执行此特定操作？
典型流水线流程
- 身份断言 – SSO / token
- 特权检查 –
DEPLOY_PROD角色 - 执行 – 生产变更
此顺序 证明了权限，而非意图。若恶意软件使用缓存的令牌执行部署，系统在“正确”运行的同时，从安全角度却灾难性地失败。这就是意图验证缺口。
真实案例
SolarWinds Sunburst
通常被描述为“构建系统被攻破”，更深层次的失误是 意图验证：
- 构建系统编译了恶意代码。
- 它对产物进行了签名。
- 它将产物分发给客户。
从 CI/CD 流水线的角度来看，似乎没有任何问题。缺失的关键问题从未被提出：
是否有人类有意识地打算部署这个特定的产物？
一旦构建服务器被入侵，密码学签名便失去了意义。服务器会像签署合法代码一样轻易签署恶意软件。
Codecov 违规
该违规持续了数月，因为 没有不可变的取证痕迹 能记录随时间在流水线中实际运行了哪些代码。从流水线的视角：
- 脚本被下载。
- 环境变量被导出。
- 所有操作正常执行。
没有防篡改的记录，我们无法回答：
- 哪些操作是被授权的？
- 它们何时发生的？
- 实际执行了哪些代码？
无法保留取证真相的安全系统，在遭受入侵后就无法重建真实情况。
The Dirty Laptop Hypothesis
现代开发者工作站是敌对领地。典型的笔记本电脑运行着：
- Browser extensions
- Background daemons
- Package managers
- Chat clients
- Build tools
- Remote‑access agents
这些都可能被攻陷。然而大多数安全系统默认同一台机器可以：
- 显示批准 UI
- 生成加密签名
- 安全传递意图
Dirty Laptop Hypothesis: Any general‑purpose computing device used for development must be treated as compromised by default.
如果批准和签名在同一台开发设备上进行，恶意软件可以在用户看到的内容与实际签名的内容之间做手脚——从而打破信任边界。
为什么基于流程的控制会失败
行业对供应链攻击的响应通常是 程序化 的：
- 更多审批
- 更多政策
- 更多合规检查清单
- 更多培训
这些是 基于流程的控制。当底层执行环境被破坏时，它们会失效：
- 被破坏的编译器不遵守同行评审。
- 被破坏的构建服务器不遵守管理层签字。
基于物理的安全反论
安全必须根植于攻击者仅凭软件无法绕过的约束。 示例：
- 物理存在
- 硬件隔离签名（例如 HSM）
- 空气隔离的审批通道
- 不可变存储（例如 WORM 驱动器）
当安全依赖于物理属性时，攻击者必须跨域：digital → physical，从而显著提升攻击成本。
令牌如空白支票
- 它们在数小时内保持有效。
- 它们可以被重放。
- 它们可能被外泄。
- 它们可以被恶意软件代理。
令牌 消除时间上下文，将高风险操作转换为低熵信号。这就是在敌对端点假设下，基于令牌的部署授权 结构上不安全 的原因。
部署应要求新的意图证明，而不是继承自早前登录事件的授权。
转变焦点：从身份到意图
现代 DevSecOps 痴迷于回答：
这是谁？
但在受损的环境中，身份并不重要。真正关键的是：
这个人是否有意识地授权了此规范？
CI/CD 流水线中的意图验证
- Intent（意图）是行为，而不是状态。
- Identity（身份）是状态，而不是行为。
在现代 CI/CD 流水线中，安全系统如果仅验证身份而不验证意图，就会对最关键的失效模式视而不见。
意图验证缺口
一旦接受了意图验证缺口，随之而来的有若干架构需求：
- 批准必须基于每一次行为，而非每个会话
- 签名必须在物理上与开发环境隔离
- 授权必须通过加密方式绑定到特定的制品和环境
- 日志必须天生不可篡改
- 阻力应与风险成比例，而非统一
这些原则构成了意图验证架构的基础。
关键要点
- Identity（身份）是便利层。
- Intent（意图）是安全边界。
只有当 CI/CD 系统将人类意图视为一等的加密原语时，供应链攻击才会被阻止；否则它们将继续绕过控制，仍能通过所有合规检查。
CI/CD 安全的未来不是更多的仪表盘。
而是更少的信任假设。