Gheist偷的不是代码，是云钥匙

一场名为 Gheist 的供应链攻击正在持续进行：攻击者不再费力挖漏洞，而是把 GitHub 令牌当成撬棍，从数千个开发者仓库里收割凭证，再顺藤摸瓜摸进云端资产。

这件事最值得警惕的地方，不是又多了一个APT代号，而是它宣告了一个事实：攻击面已经从“代码”迁移到“身份”。CI/CD 流水线，正在成为新的边界。本文拆解 Gheist 的攻击逻辑、令牌为何成了软肋，以及防御的重心到底该往哪里摆。

🔓 一场从流水线里开始的失窃

凌晨两点，某创业公司的 CI 流水线照常跑完一次构建，绿色对勾，无人值守，无人知晓——三个小时后，AWS 的临时密钥已经在攻击者的收集端排队等待兑换。

这就是 Gheist 事件的典型场景。根据公开披露，这是一场仍在进行中的供应链攻击：攻击者武器化 GitHub 令牌，从数千个开发者仓库中持续收割凭证与敏感数据。换句话说，这不是一次“打完就撤”的入侵，而是一条运转中的偷窃流水线。

其攻击链并不复杂，复杂的是它对信任链的利用：

注意最后三步——真正值钱的东西不在 GitHub 上，而在 GitHub 能打开的地方：云厂商控制台、对象存储、数据库、内部 API。仓库只是钥匙柜，云端才是金库。

据多位接近事件响应的业内人士透露，这波受影响仓库的共性非常扎眼：几乎都把长期凭证直接塞进了 CI 的 secrets 里，而且从未做过后审计。“大家默认 GitHub 内部是可信的，就像十年前大家默认内网是可信的一样。”一位做过多家企业 CI 排查的工程师私下这么说。

产业判断很清晰：当开发平台自身成为攻击者的“基础设施”，传统的 WAF、EDR 边界全部失效。你防得住外面的扫描器，防不住自己流水线里那只手。

🎫 令牌为什么成了新的攻击面

安全圈流传一句话：漏洞要找，凭证是捡的。

Gheist 选这条路不是偶然。拆开看，开发平台上的令牌有三种天然缺陷：

第一，生命周期过长。 很多团队的 Personal Access Token 一签就是一年甚至不过期，而开发者离职、仓库转手、组织重构时，几乎没人去系统性地吊销。一枚被遗忘的令牌，就是一把挂在门外的备用钥匙。

第二，权限默认过宽。 GitHub Actions 的 GITHUB_TOKEN 与用户 PAT 的作用域，经常远超单个 workflow 的实际需要。攻击者只要在一个共享的 Action 或依赖里注入几行代码，就能顺着令牌权限横扫组织内的一串仓库。

第三，密钥注入方式太“诚实”。 CI 里的 secrets 以环境变量形式注入进程，攻击者控制执行环境后，读取它们几乎没有技术障碍。而很多仓库的 secrets 命名直白得像标签——看到 AWS_ACCESS_KEY_ID 就知道该去哪。

攻击者的收益模型也随之改变：与其花几周挖一个需要特定条件才能触发的漏洞，不如花几天部署一套自动化凭证收割脚本，7×24 小时“钓”那些被偷走的钥匙。数千个仓库，哪怕只有 5% 的 secrets 有效，兑换成云资源就是可持续的“生意”。

这也是近年攻击者的集体转向。身份与凭证类攻击的投入产出比，已经全面碾压传统的漏洞利用。当偷钥匙比撬锁容易，窃贼自然改行。

🕸️ 供应链攻击的复利效应

Gheist 不是孤例，它站在一条清晰演进的路线上：

这条时间线揭示了一个残酷的乘法结构：上游污染一份，下游沦陷一片。 SolarWinds 证明了构建环节的价值，Codecov 证明了 CI 环境里全是钥匙，tj-actions 与 GhostAction 证明了开源生态的“共享组件”是最高效的传播媒介，而 Gheist 则把终点站——云端资产——直接焊进了攻击目标。

用冰山模型看这场事件，水面上下的比例可能远超想象：

水下的部分才是产业真正的课题。过去企业谈开源风险，谈的是 CVE、是依赖版本；现在谈的必须是“我的凭证有多少个副本、分布在谁的执行环境里、多久没人盘点过”。据多位接近厂商的人士反馈，很多安全团队是先在云账单里看到陌生资源，才倒查出仓库早已失陷——检测顺序整个是反的。

这就是供应链攻击的复利：攻击者投入一次，收割持续数月；防守者排查一次，只能确认昨天是干净的。

🛡️ 防御：把信任收窄到最小

那该怎么办？思路只有一句话：让“偷到令牌”变得没有价值。

具体措施可以按“技术门槛 × 防护价值”摆进一张四象限图，排一个行动优先级：

右上角的领跑者是 OIDC 短时凭证：让 CI 通过 GitHub 的 OIDC 机制向云厂商换取几分钟生命周期的临时凭证，静态密钥直接从流水线里消失——令牌被偷了也没东西可偷，釜底抽薪。紧随其后的是令牌最小权限，把每个 workflow 的权限声明到行级，默认只读。

左下与中部的措施——依赖版本锁定、密钥定期轮换——技术门槛低，但只能压缩暴露窗口，治标不治本，适合作为过渡。CI 审计与告警值得单说：绝大多数团队对自家流水线的执行记录一无所知，连“哪些 workflow 动过 secrets”都答不上来。可观测性先于控制，这是应急响应的老规矩。

落到组织层面，还有三件必须做的事：对全部 PAT 做一次彻底盘点并强制过期策略；对第三方 Action 采用版本锁定加允许清单，而不是无脑追最新标签；把 CI 排入应急响应演练范围——出事时，第一个被查的应该是流水线，而不是用户电脑。

一位常年做云上应急的红队成员说得更直白：“客户总问我怎么防 Gheist，我的回答是——先回答你有多少把钥匙、放在哪、谁配过。答不上来，防什么都是玄学。”

🧭 小结

Gheist 的真正杀伤力，不在于偷了多少仓库，而在于它验证了一条低成本、高回报、可持续的攻击路径：令牌即入口，CI 即内网，云即战利品。

对开发者来说，该重新审视的不是某一段代码，而是自己贴在流水线里的每一把钥匙。对企业来说，开源供应链安全的预算，该从“漏洞扫描”分一块给“凭证治理”了。可以预见，短时凭证与工作负载身份（Workload Identity）将从可选项变成行业标配——而那些还在用长期密钥跑 CI 的团队，最好祈祷自己还没出现在下一条披露公告里。