npm 维护者发布表：把发包、审批、安装来源放在一张表

这篇解决什么

供应链安全常分散在发包、CI、依赖安装和权限管理里。维护者需要一张轻量发布表，把 staged publishing 和 install source allowlist 一起落地。

适合谁

适合开源维护者、企业 npm 包负责人、前端基建和安全团队。

操作步骤

1. 列出每个包的发布仓库、CI、审批人和 2FA 状态
2. 记录是否启用 trusted publishing
3. 确认是否迁移到 npm stage publish
4. 盘点安装来源 allow 策略
5. 每次发布后核对版本、下载包和 changelog
6. 每月抽查权限和安装来源配置

可复制模板

包名：
发布仓库：
CI：
Trusted publishing：
Stage 审批人：
安装来源策略：
月度复查人：

验收清单

• 发布链路入表
• 审批人明确
• 安装来源受控
• 发布后核对
• 月度复查固定

常见错误

• 只收藏产品更新，没有把它改成当天能执行的工作卡。
• 只看发布标题，没有确认账号权限、适用版本、成本和数据边界。
• 把 AI 自动化结果直接当结论，没有保留人工复核和失败恢复动作。
• 外部链接散落在聊天记录里，后续复查时找不到来源和日期。

30 分钟小样本

先选一个真实但低风险的任务。前 5 分钟写清输入材料和目标产物；中间 15 分钟按本文步骤执行一次；最后 10 分钟记录输出、人工修改量、失败点和下一次复用条件。小样本通过后，再扩展到团队模板或固定 SOP。

复用方式

第一次执行时，把它当成个人操作卡；第二次执行时，把成功步骤整理成团队模板；第三次执行时，再判断是否值得升级成固定 SOP、工具页或培训材料。每次复查都要看官方页面是否改版、权限或价格是否变化、原来的示例是否还能跑通。

资料依据

• GitHub Changelog / Staged publishing and new install-time controls for npm / 2026-05-22

标签