过去一年，针对 npm 和 GitHub Actions 的供应链攻击越来越频繁。攻击者通过漏洞入侵一个项目的维护者账户，就能把恶意软件快速扩散到数百个依赖它的下游项目。这个攻击路径并不复杂，但防御起来一直很困难。
一个典型的场景是：维护者收到一封看似来自 GitHub 官方的通知邮件，点进去后在高仿的登录页面输入了凭证。几个小时后，攻击者已经拿到了项目权限，在 CI/CD 流程中植入了恶意脚本。下一次自动发布时，恶意包就出现在了 npm 仓库中。下游项目的开发者毫无察觉地 pull 了这个更新。
GitHub 在过去一年里陆续发布了几次供应链安全计划------2025年9月的 npm 安全路线图、12月的供应链安全强化方案，以及2026年3月的 GitHub Actions 安全路线图。但直到最近，这些改进才真正聚焦到一个关键环节上：切断攻击者通过维护者账户获取初始访问的路径。
攻击链中最薄弱的一环
从安全工程的角度看，供应链攻击的链条并不复杂。攻击者有几种常见入口：直接攻破维护者账户、篡改项目的工作流配置、或者利用第三方 Action 的漏洞。但无论哪种方式，初始访问都是最关键的一步------一旦攻击者拿到了项目的写入权限，后续的扩散几乎无法阻止。
GitHub 近期推出的改进措施，重点就在这个地方。根据官方公告，这些改进通过与协作安全研究社区的配合实现，目标是阻断攻击者通过"篡改项目或维护者账户获取初始访问"。在工程层面，这意味着几个具体变化：维护者账户的可疑活动会触发更严格的验证流程，项目工作流的修改需要额外的审核机制，以及 npm 包的发布环节增加了更多的校验步骤。
对企业维护者来说，这直接影响了发布流程。之前一个维护者可以直接修改工作流配置、推送代码、发布新版本。现在，涉及安全敏感的操作可能需要二次确认或等待审核。发布效率上会有一定牺牲，但对大型项目来说，这种损耗是可以接受的------相对攻击发生后的事故响应成本，多一次确认并不算高。
防护不是万能的
这里有一个不容易回答的问题：新措施能否覆盖所有攻击路径？
从已公开的资料来看，GitHub 的改进主要针对账户层和工作流层的初始访问。但攻击者还有其他方式：利用第三方 Action 中已知的漏洞、通过依赖包本身植入恶意代码、或者直接攻击 npm 镜像源的同步机制。这些路径并没有被完全封锁。
对团队来说，真正的变化不是"有了新防护就不需要担心了"，而是需要重新审视自己的发布流程和权限配置。一个值得关注的工程问题是：你的 CI/CD 流程中，有哪些操作不需要人工审核？如果攻击者攻破了一个拥有发布权限的机器人账号，你的项目能自动发现异常行为吗？
GitHub 的改进提供了一个基础层的防护，但它不能替代团队内部的安全规范。对很多中小型开源项目来说，维护者账户的安全意识和使用习惯，仍然是防御链条中最不确定的因素。双因素认证、最小权限原则、定期审计发布日志------这些老生常谈的做法在供应链攻击面前依然有效。
运维负担与安全性的平衡
每一项安全改进都有成本。对维护者来说，新增的验证步骤意味着更多的操作步骤和更长的发布周期。特别是对于那些高频发布的项目（比如安全补丁），额外的审核流程可能影响响应速度。
另一个容易被忽略的问题是：这些改进措施对不同规模的项目影响不同。大型组织有专门的安全团队来配置和监控这些防护，但个人维护者或小型团队可能连基本的账户安全设置都没做好。GitHub 需要在安全性和易用性之间找到平衡点，而这从来不是一件容易的事。
目前还没有公开信息说明这些改进的具体技术实现细节------比如可疑活动的检测阈值是多少、审核流程如何配置、是否需要手动启用。对于打算依赖这些新功能的团队来说，真正的工程判断需要在部署后根据实际使用情况做出。
真正困难的地方不在于 GitHub 增加了一个安全功能，而在于整个开源生态是否愿意为供应链安全付出额外的维护成本。一个防护方案的效果，最终取决于使用它的人是否理解它的边界和限制。
关于维基框架
维基框架关注企业应用开发中的长期维护问题。在实际项目中，业务系统往往同时涉及权限、微服务、接口协议、部署环境等复杂因素，因此我们希望提供一套更容易扩展和维护的基础框架。
官网：framewiki.com
Gitee：gitee.com/wiki-framework
GitHub：github.com/wiki-framework
示例项目：gitee.com/cdkjframework/framewiki-example
📄 许可证：MulanPSL-2.0（木兰宽松许可证，第2版）