node-supply-chain

node-supply-chain

叠加那些在真实 npm 攻击中发挥作用的防御措施，并说明每一层不能防护什么。此技能要修复的问题：模型会在 CI 中建议使用 npm install，对机器人 PR 一律自动合并（这是有记录的恶意软件传播途径），把冷却期当作全面防护措施，以及在 pnpm/yarn 仓库中应用 npm 专用的脚本策略，而这些策略在那里毫无作用。

不适用场景

• GitHub 仓库设置（规则集、机密扫描、PVR）→ 此集合之外的仓库设置工具（例如 github-skills 的 repo-protections 技能）。
• 发布带来源证明的自有包 → node-release。
• 修复自有代码中的 CVE → 常规开发工作。

工作流

1. 基线审计：

   python3 "${CLAUDE_SKILL_DIR}/scripts/audit_supply_chain.py"
   

   报告内容：锁文件状态、CI 安装命令、Dependabot 配置（冷却期/分组）、未固定版本的第三方操作，以及针对仓库实际使用的包管理器的安装脚本策略。
2. 锁文件规范：提交锁文件；CI 使用 npm ci / pnpm install --frozen-lockfile / yarn immutable 安装，绝不使用不带参数的 install。
3. Dependabot（.github/dependabot.yml）：npm 和 github-actions 生态系统，每周运行，分组，并明确设置冷却期（自 2026-07-14 起，github.com 默认值为 3 天；请写明你想要的时间窗口）——每次都要说明其三个实际限制： 安全 PR 按设计不受冷却期限制，npm 的传递依赖不在覆盖范围内，固定 SHA 的操作不会触发警报。绝不对机器人 PR 一律自动合并——绿色 CI 中也曾因机器人身份而引入恶意软件；审核门槛应与人工提交者相同。
4. 按包管理器制定安装脚本策略（操作手册表格：npm >= 12 使用 allowScripts 允许列表，npm 11 使用 ignore-scripts，pnpm 使用 allowBuilds，yarn 使用 enableScripts）： 应用仓库实际使用的包管理器所支持的机制；仅允许确实需要构建脚本的少数包。
5. 来源证明验证（npm audit signatures——操作手册中注明命令的版本要求）：将其视为来源证明，绝不是安全性证明。
6. 令牌卫生：不使用经典令牌；对于 OIDC 无法覆盖的场景，使用有效期较短的细粒度令牌；在账户层级强制仅使用可信发布（设置本身 → node-release）。
7. Actions 固定版本：第三方操作固定到 SHA，并附带版本注释；使用 node-ci 中的检查器或 zizmor 检查工作流。
8. 事件响应（上游遭到入侵）：遵循操作手册检查清单——根据锁文件确定受影响情况（精确解析出的版本和安装时间窗口），覆盖/固定到已知良好版本，记录时间窗口，然后重新加固。

输出规范

审计脚本检查通过（或已处理每一项发现）；Dependabot 配置包含冷却期和分组，且不对机器人 PR 一律自动合并；每种包管理器的脚本策略都已实际生效；已应用版本固定；报告中明确说明冷却期的三个限制——绝不暗示配置并未提供的防护。

注意事项

• npm/pnpm/yarn 的脚本策略是不同机制——在 pnpm 仓库中只给出 npm 方案，起不到任何防护作用。
• 冷却期是在赌有人能在时间窗口内发现恶意软件——应将其作为分层防护的一环，而不是依赖它。
• overrides/resolutions 能快速降低受影响风险，但会悄然过时——添加日期标记，并在上游发布干净版本后移除。
• 对 npm CLI 的行为（脚本默认设置、审计签名）进行版本检查，并在使用时核对 npm 官方文档。

文件

• references/supply-chain-playbook.md — 分层模型、按包管理器划分的脚本策略表、Dependabot 配置、来源证明的限制、令牌策略、事件检查清单。
• scripts/audit_supply_chain.py — 确定性仓库审计；存在严重违规（无锁文件、CI 中使用不带参数的 install、一律自动合并机器人 PR）时以非零状态码退出。