一台被植入恶意软件的工程师笔记本，让 CircleCI 客户的密钥在 2022 年末暴露，并触发全平台凭据轮换。 本文是公开报告的摘要与解读，事实以原始报告为准

本文是公开报告的摘要与解读，事实以原始报告为准。

事件概要

2023 年 1 月 4 日，CircleCI 公开披露一起安全事件。1 月 12 日，CTO Rob Zuber 发布正式复盘，确认未授权第三方访问了部分生产系统，并从部分数据库和存储中取走了客户的环境变量、令牌和密钥。报告没有给出受影响客户的总数，只说“少于 5 家客户”告知 CircleCI，其第三方系统出现了与本次事件相关的未授权访问。

CircleCI 的建议很直接：在该时间窗口内把密钥存放在 CircleCI 的客户，应假定这些密钥已被访问；2023 年 1 月 5 日之后写入系统的内容可以视为安全。报告同时把这次事件称为“系统故障”，强调组织性防护，而不是把责任归到某个员工身上。

时间线

影响面

被取走的数据来自“部分数据库和存储”，包括客户环境变量、令牌和密钥。报告使用了“包括”一词，说明这不是一份完整的暴露清单；它也没有给出受影响客户总数，也没有明确声明客户构建、日志或制品未受影响。因此，摘要不应替报告补写“构建完全未受影响”这类结论。

数据在静态存储时是加密的，但攻击者从运行中的进程里取得了加密密钥。报告据此提醒：不能因为数据“加密存储”就认为它没有被访问。对于第三方系统，CircleCI 表示无法判断客户密钥是否被用于未授权访问，只能建议客户按“已泄露”处理并轮换。

报告给出的唯一客户影响数字是“少于 5 家客户”报告了第三方系统的未授权访问；这不是泄露客户总数，而是客户主动告知的数量。下游影响主要体现在凭据轮换：客户需要更新 GitHub、Bitbucket、AWS、SSH 以及 CI 环境中的各类密钥，任何依赖旧凭据的自动化都可能在轮换后失败。

根因

初始入口是工程师笔记本上的恶意软件。报告称该恶意软件没有被杀毒软件发现，它窃取了一个有效的、受 2FA 保护的 SSO 会话，具体机制包括会话 cookie 窃取。攻击者因此可以远程冒充该员工，进入部分生产系统。该员工的日常职责包括生成生产访问令牌，这一权限使攻击者能够进一步访问并取走部分数据库和存储中的数据。

这里的关键不是“2FA 失效”，而是 2FA 保护的是登录动作，不能保护已经被窃取的会话。攻击者不需要再次通过 2FA，只需重放有效会话即可。报告还指出，调查没有发现其他员工的凭据或设备被入侵的证据；它把事件描述为系统性失败，而不是单一个人的疏忽。

从防御角度看，三个条件叠加放大了后果：高权限员工终端被攻破、会话可被远程重放、生产令牌生成权限过于集中。任何一个条件被削弱，攻击者都更难从一台笔记本走到客户密钥库。

处置与恢复

CircleCI 的处置分为“切断访问、替换主机、吊销令牌、通知客户、补强控制”几条线。1 月 4 日 16:35 UTC 终止被入侵员工的访问，18:30 移除几乎所有员工的生产访问，22:30 替换可能暴露的生产主机。随后在 1 月 5 日和 6 日分别吊销 Project API Token 与旧个人 API Token，并与 Atlassian 完成 Bitbucket 令牌轮换，1 月 7 日完成 GitHub OAuth 轮换。

补强措施包括：增加 step-up 认证；通过 MDM 和杀毒软件阻断已观察到的恶意行为；增加监控和告警；发布密钥扫描脚本；为 checkout key 增加 SHA-256 签名；在 Contexts API 中增加 updated_at 字段；向免费和付费客户提供审计日志。

对客户，报告建议轮换 OAuth 令牌、Project API Token、SSH 密钥和其他密钥，调查 2022 年 12 月 16 日之后的活动，搜索报告公布的 IP、域名和恶意文件，检查 GitHub 审计日志中的 repo.download_zip 等命令，并考虑采用 OIDC、IP 范围、Contexts 和 runner 等更细粒度的控制。轮换时应先在源系统吊销，再生成新凭据并更新使用方，避免旧凭据在轮换窗口内继续可用。

教训

第一，会话窃取可以绕开 2FA。对高权限工程师的终端，EDR、MDM、磁盘加密、浏览器会话保护和抗钓鱼 MFA 要一起用，不能把 2FA 当成终点。

第二，CI 中的长期密钥是高价值目标。环境变量、Contexts、项目令牌、SSH 部署密钥往往能直接进入生产；能改用 OIDC 短期凭据的，就不应保存长期云密钥。

第三，静态加密不等于访问控制。只要运行中的进程能取出密钥，加密就只能在存储介质被盗时提供有限保护。

第四，检测不能只依赖客户举报。本次事件由客户发现可疑 OAuth 活动后触发核查；对 OAuth 应用、令牌使用和审计日志的异常检测应前置。

第五，轮换是一场跨系统协作。GitHub、Bitbucket、AWS、SSH 和 CI 变量需要在同一张清单上管理，否则“已轮换”可能只是换了一个地方继续暴露。

第六，报告把事故定义为系统失败，这有助于无责复盘；但无责不等于无边界，生产令牌生成权限、终端隔离和最小权限仍要落到工程控制上。

对本站读者的检查清单

• 是否盘点过 CI 中的环境变量、Contexts、项目/个人令牌、SSH 部署密钥和 runner 令牌？
• 每个密钥是否有 owner、用途、作用域、创建时间和最近轮换时间？
• 云厂商认证是否已迁移到 OIDC 等短期凭据？仍在使用长期 Access Key 的是否有例外审批？
• 生产与非生产密钥是否隔离？CI 是否默认只能读取完成构建所需的最小范围？
• 是否监控 GitHub/GitLab 审计日志中的仓库下载、OAuth 应用授权和令牌异常使用？
• 工程师终端是否有 EDR/MDM、磁盘加密和会话保护？高权限账号是否使用抗钓鱼 MFA？
• 是否限制“生成生产访问令牌”的权限？能否按需申请、自动过期、全程留痕？
• 是否演练过大规模凭据轮换：谁负责吊销、谁更新使用方、如何验证旧凭据已失效？
• 事故沟通是否明确“假定已泄露”的时间窗口和客户行动清单？
• 审计日志是否导出到独立系统，避免攻击者取得生产权限后一并删除？

恢复手册与同类复盘

• 公开复盘索引 — 按根因查找同类事故，并跳到对应 Runbook。
• 凭据轮换可借鉴证书轮换流程 — 对照本次事故的恢复路径与验证点。

相关命令

• circleci：查看流水线配置、Contexts 和项目令牌的使用位置。
• git：检查仓库历史、远端配置和可能写入凭据的提交。
• ssh-keygen：生成、查看指纹并轮换 SSH 密钥。
• openssl：检查证书、密钥格式和加密材料。
• gitleaks：扫描仓库和构建日志中的疑似密钥。
• auditd：审计主机上的敏感文件访问和命令执行。
• incident-command：组织跨团队凭据轮换和沟通。
• postmortem：把时间线、根因和改进项写成可执行复盘。
• incident-response-playbook：按止损、恢复、沟通和复盘推进。
• container-security-checklist：补齐 CI/CD 与供应链侧的安全检查。

参考链接

• CircleCI 官方复盘：CircleCI Jan 4, 2023 security incident report
• CircleCI 官方安全公告：Rotate any secrets stored in CircleCI（Updated Jan 13）
• CircleCI 状态页事件记录

读完自测

合上页面，先回答，再展开对照。

1. 攻击者在拥有 2FA 的情况下，为什么仍能冒充 CircleCI 工程师？
2. 报告说数据“加密存储”，为什么这不足以保护客户密钥？
3. 如果你所在团队在 CI 中保存了长期云密钥，参照本事件应先做哪三件事？