如果你的项目在用 npm 包和 GitHub Actions过去一年你应该注意到一件事——供应链攻击越来越频繁了。攻击者不再一个个黑项目而是通过包仓库和 CI/CD 系统一次性扩散到几百个开源项目。GitHub 博客这两天发了篇文章详细讲了2025到2026年他们在供应链安全上的改进不是那种我们很重视安全的官样文章而是实实在在切断了攻击链中的关键环节。攻击的起点通常不是复杂的 0day 漏洞。大部分攻击走的是一条简单有效的路径先攻破一个维护者的账号或者控制项目的 GitHub Actions 工作流然后利用这个初始访问权限在生态中扩散。GitHub 团队观察到的攻击模式基本一致——初始访问 → 权限提升 → 分发扩散。这三步里面任何一步被切断攻击者的成本都会大幅上升。这次改进的重点有两个方向。第一个是 npm 注册表的访问控制。过去发布一个 npm 包只需要拥有 npm 账号的发布权限GitHub 账号的关联验证并不严格。攻击者拿到一个 npm token 就能发布恶意版本。GitHub 现在加强了 npm 包发布和 GitHub 账号之间的绑定关系同时引入了更细粒度的权限控制——不是谁有 token 谁就能发而是允许哪些账号在什么条件下发布。对于维护多个包的项目组来说这个改动的影响比想象中大。以前一个 token 泄漏可能导致整个组织下的包都被污染现在攻击面被限制在单个包粒度。第二个是 GitHub Actions 的安全加固。Actions 的问题在于它的 workflow 可以引用的第三方 action 太多了。一个项目可能用了几十个 action其中任何一个被篡改都会触发恶意代码。GitHub 对 actions 的加载机制做了调整重点限制 workflow 中未经验证的第三方 action 执行敏感操作的能力。具体来说在关键的安全场景比如审批、部署、secrets 访问现在要求 action 必须有更明确的来源验证。但事情没有这么简单。供应链攻击没有银弹GitHub 团队自己也承认这一点。他们采取的是打断攻击链中最关键环节的策略——不是试图堵住所有漏洞而是优先让最常用的攻击手法失效。从工程角度看这个方向是对的。安全投入永远是有限的把资源集中在阻断最常见的攻击路径上比试图覆盖所有可能的攻击面要实际得多。从开发者的角度有几个点值得关注。npm 包的发布流程会变。如果你维护着 npm 包接下来可能会遇到发布失败的情况不是因为代码有问题而是因为你的 GitHub 账号关联或 token 权限配置不满足新的要求。建议提前检查 npm 包的发布配置特别是那些用 CI/CD 自动发布的项目。第三方 action 的使用需要重新评估。项目里引用的 action如果来源不明确或者维护不活跃接下来可能在安全敏感场景中无法执行。不是不能用而是需要在 workflow 中明确声明信任关系。多因素认证不再是可选项。GitHub 一直在推 2FA但这次 npm 的权限绑定本质上是把账号安全直接和包安全绑定了。一个没有 2FA 的维护者账号其实就是整个依赖链的薄弱点。真正的问题是这些改动能在多大程度上改变攻击者的行为模式从目前的信息来看对于依赖简单 token 泄漏发起的攻击这些措施应该有明显的阻断效果。但对于更复杂的攻击——比如攻击者通过社工获取维护者信任、长期潜伏后发起攻击——这些措施的效果可能有限。这取决于类似攻击在整体供应链攻击中占多大比例。回到工程实践上对团队来说最直接的行动是检查 CI/CD 中所有 npm publish 的 token 配置确认它们使用了新的细粒度权限模型梳理 workflow 中每一个引用的 action标记来源和用途确保所有有发布权限的成员都开了 2FA。这些事看起来琐碎但供应链攻击的防御从来没有靠一个工具或一个策略就能解决的。关于维基框架维基框架关注企业应用开发中的长期维护问题。在实际项目中业务系统往往同时涉及权限、微服务、接口协议、部署环境等复杂因素因此我们希望提供一套更容易扩展和维护的基础框架。官网framewiki.comGiteegitee.com/wiki-frameworkGitHubgithub.com/wiki-framework示例项目gitee.com/cdkjframework/framewiki-example 许可证MulanPSL-2.0木兰宽松许可证第2版
npm供应链攻击 GitHub终于动手切断了关键环节
发布时间：2026/7/29 20:02:04
如果你的项目在用 npm 包和 GitHub Actions过去一年你应该注意到一件事——供应链攻击越来越频繁了。攻击者不再一个个黑项目而是通过包仓库和 CI/CD 系统一次性扩散到几百个开源项目。GitHub 博客这两天发了篇文章详细讲了2025到2026年他们在供应链安全上的改进不是那种我们很重视安全的官样文章而是实实在在切断了攻击链中的关键环节。攻击的起点通常不是复杂的 0day 漏洞。大部分攻击走的是一条简单有效的路径先攻破一个维护者的账号或者控制项目的 GitHub Actions 工作流然后利用这个初始访问权限在生态中扩散。GitHub 团队观察到的攻击模式基本一致——初始访问 → 权限提升 → 分发扩散。这三步里面任何一步被切断攻击者的成本都会大幅上升。这次改进的重点有两个方向。第一个是 npm 注册表的访问控制。过去发布一个 npm 包只需要拥有 npm 账号的发布权限GitHub 账号的关联验证并不严格。攻击者拿到一个 npm token 就能发布恶意版本。GitHub 现在加强了 npm 包发布和 GitHub 账号之间的绑定关系同时引入了更细粒度的权限控制——不是谁有 token 谁就能发而是允许哪些账号在什么条件下发布。对于维护多个包的项目组来说这个改动的影响比想象中大。以前一个 token 泄漏可能导致整个组织下的包都被污染现在攻击面被限制在单个包粒度。第二个是 GitHub Actions 的安全加固。Actions 的问题在于它的 workflow 可以引用的第三方 action 太多了。一个项目可能用了几十个 action其中任何一个被篡改都会触发恶意代码。GitHub 对 actions 的加载机制做了调整重点限制 workflow 中未经验证的第三方 action 执行敏感操作的能力。具体来说在关键的安全场景比如审批、部署、secrets 访问现在要求 action 必须有更明确的来源验证。但事情没有这么简单。供应链攻击没有银弹GitHub 团队自己也承认这一点。他们采取的是打断攻击链中最关键环节的策略——不是试图堵住所有漏洞而是优先让最常用的攻击手法失效。从工程角度看这个方向是对的。安全投入永远是有限的把资源集中在阻断最常见的攻击路径上比试图覆盖所有可能的攻击面要实际得多。从开发者的角度有几个点值得关注。npm 包的发布流程会变。如果你维护着 npm 包接下来可能会遇到发布失败的情况不是因为代码有问题而是因为你的 GitHub 账号关联或 token 权限配置不满足新的要求。建议提前检查 npm 包的发布配置特别是那些用 CI/CD 自动发布的项目。第三方 action 的使用需要重新评估。项目里引用的 action如果来源不明确或者维护不活跃接下来可能在安全敏感场景中无法执行。不是不能用而是需要在 workflow 中明确声明信任关系。多因素认证不再是可选项。GitHub 一直在推 2FA但这次 npm 的权限绑定本质上是把账号安全直接和包安全绑定了。一个没有 2FA 的维护者账号其实就是整个依赖链的薄弱点。真正的问题是这些改动能在多大程度上改变攻击者的行为模式从目前的信息来看对于依赖简单 token 泄漏发起的攻击这些措施应该有明显的阻断效果。但对于更复杂的攻击——比如攻击者通过社工获取维护者信任、长期潜伏后发起攻击——这些措施的效果可能有限。这取决于类似攻击在整体供应链攻击中占多大比例。回到工程实践上对团队来说最直接的行动是检查 CI/CD 中所有 npm publish 的 token 配置确认它们使用了新的细粒度权限模型梳理 workflow 中每一个引用的 action标记来源和用途确保所有有发布权限的成员都开了 2FA。这些事看起来琐碎但供应链攻击的防御从来没有靠一个工具或一个策略就能解决的。关于维基框架维基框架关注企业应用开发中的长期维护问题。在实际项目中业务系统往往同时涉及权限、微服务、接口协议、部署环境等复杂因素因此我们希望提供一套更容易扩展和维护的基础框架。官网framewiki.comGiteegitee.com/wiki-frameworkGitHubgithub.com/wiki-framework示例项目gitee.com/cdkjframework/framewiki-example 许可证MulanPSL-2.0木兰宽松许可证第2版
