Keyv 和其他项目在正在进行的 Shai-Hulud 供应链攻击中遭入侵

平台责任与恶意软件扫描

• 有些人惊讶于 GitHub 和 npm 没有更积极地自动检测并阻止那些显然恶意的仓库或数据外泄枢纽，至少在它们变得可被公开搜索到之前应该如此。
• 也有人指出，GitHub 近期确实宣布了 npm 发布时恶意软件扫描和“dual-use”元数据，但执行是渐进式的，而攻击者可能已经在绕过这些措施。
• 令人沮丧的是，GitHub 现在理应能够检测到类似 Shai-Hulud 的 GitHub 外泄仓库或模式，但显然还没有做到。

指标、影响与文章叙述方式

• 一些评论者批评文章强调“每月 20 亿+ 次安装”具有误导性，因为很多安装发生在 CI 中，不一定是在敏感环境里。
• 另一些人反驳说，CI 往往持有最特权的密钥，所以 CI 被攻破非常严重。

pre/post-install 钩子与代码执行

• 普遍观点是：在现有包中新增一个 pre-install 钩子应被视为高度可疑；有人甚至呼吁暂停新增 pre/post-install 钩子。
• 也有人认为这只是“必要但不充分”：它能降低风险，但无法阻止攻击者把逻辑移到 index.js 这类运行时文件中。
• 少数人认为这种局部缓解不值得增加复杂度；反对者则把这看作对纵深防御的误解。

依赖更新、冷却期与 CI/CD 实践

• 一个广泛推荐的缓解措施是强制版本冷却期（例如 3–7 天，npm 或 Renovate 中的 min-release-age），这样通常会很快被发现的蠕虫就不能立刻影响你。
• 多位评论者建议不要在 CI 中自动更新依赖，或者只在人工审查后更新。
• 所描述的最佳实践是：把工作流分开，让构建/测试步骤不持有发布或生产凭据，而由一个单独、最小权限的作业来执行真正的发布。

检测、IoC 与清理

• 关键指标包括：新增的 setup.mjs、体积很大（约 700–800 KB）的 Math_Symbol.js 或 math_init.js，以及 package.json 中的 "preinstall": "node setup.mjs"。
• 需要警惕的是：另一个包里确实存在一个合法的 Math_Symbol.js（约 1 KB）；体积很重要。
• 一些工具和文档被共享出来（例如 Antimiasma、Packj、威胁报告），还有使用 find 或 fd 搜索 node_modules 的命令行示例。
• 一项分析指出：
  • 最初的恶意包是通过 npm 的“Trusted Publishing”发布的，并带有有效的 provenance；provenance 证明的是“是什么”，但不能证明“谁本不该改它”。
  • 该蠕虫设置了一个 watcher：当被窃取的 GitHub token 被吊销时它就会触发，因此补救顺序很重要。
  • 持久化可能通过 .claude/settings.json 和 .vscode/tasks.json 增加。
  • C2 端点在运行时从一个 Ethereum 合约中解析出来，域名类似 npm-cache.com。

NPM 与其他生态系统

• 有些人坚持认为 npm 是独一无二地糟糕：小包太多、没有标准库、历史上默认执行安装脚本，以及庞大的依赖图。
• 另一些人回应说，如今大多数现代 JS 包管理器都默认禁用安装脚本、使用 lockfile，并支持 Trusted Publishing 和冷却期之类的特性；攻击者之所以盯上它们，是因为其流行度，而不是设计本身。
• 与 Debian 精选包集合的比较则认为，规模、目标和精选模式根本不同，不能直接类比。

隔离、容器与密钥处理

• 有几位主张更强隔离：使用 devcontainer、VM 或沙箱化开发环境，而不是在拥有完整文件系统/网络访问权限的情况下运行 Node。
• 反方观点是：只有当凭据也被拆分并最小化时，容器才有帮助；一旦把强权限 token 挂载进容器，这道边界就没什么作用了。
• 讨论还涉及：在今天为每个工具和环境维护细粒度、最小权限的 IAM 和 token 映射是否现实。

猜测、厂商与执法

• 一位评论者推测，一些供应链攻击可能是由安全厂商自己推动的，目的是增加需求；其他人则强烈反对这种说法，认为毫无根据且不宜轻率指控。
• 还有人质疑为什么执法机构（例如 FBI）没有公开逮捕行动；回复指出，幕后很可能是外国行为者，因此存在管辖权限制。