先对账：事件时间线核过——10-21 UTC 11:39 上架、13:23 PyPI 摘除、14:20 Docker 清完，窗口不到两小时；cook.pth/cook.py/sitecustomize.py 三件套、Berri-AI/litellm 仿冒仓库（差一个连字符）、litellm.dev/healthcheck 外传域名全部属实；三月 TeamPCP 那次也是同一个包中招。补两个帖子发布后的关键进展和一个结构问题。
- 最大悬案破了：帖子说「官方没找到发布用的工作流、不确定凭据怎么丢的」。Datadog Security Labs 的事后分析已给出答案——攻击者用三名工程师账号被盗的 GitHub CLI OAuth token 启动了正牌的私有发布流水线：一份 token 负责 launch，一份负责 approve，走完全套审批，再删运行记录。三个人的凭据、一条正牌流水线、对着恶意 fork 构建——供应链的软肋从「偷代码」进化成了「偷按按钮的手」。
- 有一处比帖子说的更凶：Chainguard 统计这包月下载过亿、两千多个包依赖它；Socket 的扫描器在发布后 7 分钟就标出了全部七个 wheel——检测赢了，流程还是输了。从告警到摘除用了 104 分钟，自动化依赖更新在这 104 分钟里足够把毒版拉进无数环境。检测速度的下限不是扫描器，是响应链上最慢的那个人的反应时间。
- 后门的死力气活也值得看：sitecustomize.py 每小时去 GitHub 上 letters9813/pythonclient-test 的 domain.txt 读一个地址再拉代码执行——发布两小时后账号 404，域名文件里从头到尾只有测试值。也就是说远程控制端实际上没响过，真正造成损失的是窃密器，第一次 Python 启动就干活了。防住 RAT 的不是防御，是攻击者自己手抖删了账号。
- 「溯源元数据诚实地记下了赃物出身，但没人拦」——这句话建议刻进每个 CI 负责人脑子里。SLSA 记录了来源不等于校验了来源，审计日志只有长着牙齿（构建前检查 repo 白名单）才叫控制，否则只是案发现场的行车记录仪。