读懂｜GitBook 被入侵时，客户的代码仓库被动过吗？

GitBook 复盘称入侵者曾能以其应用身份进入客户授权的仓库，却无法确定对方是否动过；关站约 16 小时、全量换钥匙做得对，仓库这一条答不出。

GitBook 自己答不上来。这家文档平台 11 月 4 日公布的事故复盘写明，入侵者一度能以 GitBook 应用的身份，在每个客户授权过的 GitHub 和 GitLab 仓库里行事，而它「无法确定」对方有没有在客户仓库里做过什么。

关站、换钥匙，GitBook 处理得干脆。站不住的是这句「无法确定」：一个文档工具握着客户代码仓库的代理权限，就必须能交代这份权限被谁用过。

劫持客户账号 5 小时 21 分后进了生产环境

复盘的时间线用协调世界时，下面照录，间隔为编辑据原文计算。

告警只比入侵者进生产环境晚 22 分钟，但离第一个客户账号被劫持已经过去 5 小时 43 分。前面五个多小时，入侵者从客户侧一路走到员工会话和内部代码库，监测没有出声。

11 月 3 日的通报说，攻击者在欧洲中部时间 19:00 拿到部分基础设施凭证，「我们立即发现」。这个说法只对最后一段成立。据 Decrypt 当天的报道，那版通报也没有说明攻击者怎么用 AI 智能体、凭证从哪来。

GitBook 禁用了全部受影响的内部服务账号，轮换生产环境每一个密钥和它代管的每一个客户密钥，作废截止时点前签发的全部 API 令牌。应用到 11 月 3 日 11:56 才全部恢复，按时间线停了 15 小时 24 分，GitBook 自称约 16 小时。

复盘的理由很实在：入侵者已经在云基础设施里，继续运行就是让对方接着找入口。目标只是一个客户，GitBook 仍把全部客户数据按已暴露处理。这两步我们认为都对。

「攻击主要由自动化和 AI 驱动」是 GitBook 自己的判断，复盘没有给出工具或证据，只能按企业宣称读。就算属实，它也不改变入口在哪：SSO 漏洞和配置错误的 GitHub App 都是 GitBook 自家的。

GitBook 的文档写明，Git Sync 是双向同步，在编辑器里的改动会自动同步进仓库。GitBook 应用本来就能往客户仓库里写。复盘让客户「无需操作」，因为它已经替客户轮换了 Git Sync 的密钥；可轮换只管以后，管不了入侵那几个小时。

有人会说，客户可以在 GitHub、GitLab 自己的审计日志里查 GitBook 应用做过什么，仓库层的结论本不该由平台代答。我们接受客户应当去查，不接受平台就此免答：这份权限是 GitBook 向客户要的，它能列出三个攻击者 IP，就该能给出自家应用在每个仓库里的操作记录。

这类中间层正在成为靶子。据 SecurityWeek 的统计，过去一个月至少十几家 AI 开发平台被攻破，攻击者都在翻平台上存着的客户密钥；云安全联盟指出，这一层替许多下游客户保管凭证，攻破一处就能拿到一串钥匙。

GitBook 复盘里第三条教训写的也是这个：SaaS 供应商是客户安全边界的一部分。客户已经在用脚投票，据 Decrypt 报道，PancakeSwap 把文档从 GitBook 迁到了自己控制的设施上。

一个文档工具向客户要了仓库的写权限，就欠客户一份「动没动过」的答案。GitBook 答出了停机时长、换掉的钥匙和三个攻击 IP，唯独这一条答不出，而这份权限是它自己要来的。