Trigger.dev团队在2025年11月25日遭遇了Shai-Hulud 2.0供应链攻击，该恶意软件通过npm包感染了5万多个仓库。攻击导致内部代码库出现异常提交和强制推送。虽然公司官方包未被感染，但一名工程师的开发机因安装受污染包而遭到入侵。事件促使团队改进安全措施以防止类似事件再次发生。

标题：我们如何遭遇Shai-Hulud攻击：完整事件复盘 | Trigger.dev

事件概述
2025年11月25日，Trigger.dev团队在调试生产问题时，发现内部代码库的PR被异常关闭，提交记录显示为“Linus Torvalds”的“init”提交。随后，#git Slack频道爆发大量通知，多个仓库的PR被关闭，分支被强制推送。团队确认遭遇了Shai-Hulud 2.0攻击——一种针对npm供应链的蠕虫病毒，已感染超500个包和2.5万个代码库，PostHog、Zapier等公司同样受影响。

关键细节
- 攻击路径：一名工程师在开发机上安装受感染的npm包，导致GitHub凭证泄露，攻击者借此入侵组织权限。
- 攻击时间线：
- 11月24日20:27 UTC：工程师通过pnpm install触发恶意脚本。
- 11月25日15:27 UTC：攻击者开始破坏性操作（强制推送、关闭PR等）。
- 15:32 UTC：团队通过Slack警报发现异常，4分钟内撤销攻击者权限。
- 攻击手段：
- 恶意脚本通过preinstall钩子运行，窃取GitHub、AWS等凭证。
- 使用TruffleHog工具扫描并外泄敏感数据，创建随机命名的GitHub仓库存储信息。
- 部分破坏行为（如伪造成Linus Torvalds提交）可能为攻击者手动操作。

影响范围
- 669个仓库被克隆（含基础设施代码和内部文档）。
- 199个分支被强制推送，42个PR关闭，4次因分支保护拦截。
- 未受影响：生产数据库、AWS资源、npm发布包（因启用2FA）。

应对措施
1. 即时响应：
- 移除攻击者权限，恢复被篡改分支（7小时内完成）。
- 轮换GitHub App私钥，通知潜在受影响客户。
2. 技术改进：
- 全局禁用npm脚本（ignore-scripts=true），升级至pnpm 10（默认禁用脚本）。
- 启用全仓库分支保护，改用OIDC发布npm包，避免长期凭证留存。
3. 工具推荐：
- 使用Granted加密AWS SSO会话，设置minimumReleaseAge延迟新包安装。

经验教训
- 供应链风险：npm包的任意脚本执行是核心漏洞，建议强制禁用并白名单例外。
- 最小权限原则：本地开发机避免存储发布凭证，依赖CI/CD流程。
- 监控价值：嘈杂的Slack频道成为早期警报来源。

资源链接
- Socket.dev技术分析
- npm可信发布指南
- pnpm安全配置

总结
此次事件凸显了开源生态的供应链脆弱性。尽管团队快速响应未造成更严重后果，但根本解决方案需依赖npm生态的架构改进。

（注：原文中的时间线表格、图片链接及部分技术细节已精简，保留核心信息。）

以下是评论内容的总结，平衡呈现不同观点并保留关键引用：

1. 对事件透明度的赞赏

   • 多位评论者肯定事件分析的透明度，认为有助于行业学习。
   • 引用："Really appreciate the transparency here. Post-mortems like this are vital for the industry."
   • 引用："Points for an excellent post-mortem."

2. 对安全措施的讨论

   • 开发者关注如何加强开发环境安全，如严格出口过滤和Git凭证管理。
   • 引用："We’ve been looking into stricter egress filtering for our dev environments."
   • 引用："How do I make my git setup on my laptop secure?"

3. 对攻击行为的疑问

   • 部分评论者质疑攻击者制造噪音的行为（如强制推送仓库）不符合逻辑。
   • 引用："But then why make so much noise with trying to force push repositories?"
   • 引用："Very script kiddie-like, which does not really fit the main complexity of the virus."

4. 对NPM生态安全的批评

   • 批评NPM安装脚本的潜在风险，建议增加审查工具。
   • 引用："NPM post-install scripts considered harmful."
   • 引用："The security failure is in an ecosystem that allows packages to run arbitrary code silently."

5. 对漏洞命名的调侃

   • 有评论者提到漏洞名称的洛夫克拉夫特风格有趣。
   • 引用："I am loving the ancient Lovecraftian horror vibe of these exploit names."

6. 对数据库是否被入侵的分歧

   • 有评论者认为即使未确认数据泄露，凭证泄露也应视为系统沦陷。
   • 引用："I’d definitely consider that compromised even if the guy didn’t read anything from the database."

7. 对后续工具的需求

   • 建议建立类似haveibeenpwned的凭证泄露查询服务。
   • 引用："it would be nice to be able to search using a compromised token to find out what else leaked."

8. 对防御措施的补充建议

   • 指出缺乏终端检测与响应（EDR）工具可能影响调查。
   • 引用："Sounds like there’s no EDR running on the dev machines?"

9. 对小团队影响的关注

   • 强调小团队受攻击的后果，推测大企业可能面临更严重风险。
   • 引用："The org only has 4-5 engineers. So you can imagine the impact a large org will have."

总结呈现了技术讨论、生态批评和实用建议，涵盖安全实践、攻击分析和行业改进方向。