瓦解针对NPM和GitHub Actions的供应链攻击

# 阻断针对 npm 和 GitHub Actions 的供应链攻击 来源：https://github.blog/security/supply-chain-security/disrupting-supply-chain-attacks-on-npm-and-github-actions/ 在过去一年中，出现了一种供应链攻击模式，专门针对包仓库和 CI/CD 系统中的弱点，从而快速将恶意软件传播到数百个开源项目中。这些恶意软件试图窃取凭据，一方面是为了广泛传播攻击，另一方面是为了后续利用。 我们曾多次撰文阐述强化供应链的计划：2025 年 9 月的《我们打造更安全 npm 供应链的计划》（https://github.blog/security/supply-chain-security/our-plan-for-a-more-secure-npm-supply-chain/），2025 年 12 月的《加强供应链安全：为下一波恶意软件攻击做准备》（https://github.blog/security/supply-chain-security/strengthening-supply-chain-security-preparing-for-the-next-malware-campaign/），以及 2026 年 3 月的《GitHub Actions 2026 安全路线图前瞻》（https://github.blog/news-insights/product-news/whats-coming-to-our-github-actions-2026-security-roadmap/）。本文将向大家汇报我们已实施的多项变更，这些变更直接阻断了一些最常见、影响最广泛的供应链攻击技术。 ## 供应链攻击剖析 供应链攻击将多个弱点串联在一起，没有任何单一的安全能力可以完全阻止它们。应对这类攻击需要采取整体方法，优先考虑那些能打破攻击链中最关键环节的缓解措施。我们的团队一直在研究这些攻击，并部署了多项改进来阻断它们并限制其影响。这得益于安全研究和开发者社区的协作。 这些攻击在软件生态系统中传播的方式各异。然而，大多数攻击都遵循类似的技术来获得对项目的初始访问权、提升权限，并在用户和软件之间传播。过去几个月对 npm 和 GitHub Actions 所做的改进，主要集中在切断特定的、常见的技术路径，并为客户提供识别和应对这些攻击的方法。 ## 初始入侵 攻击通常从入侵单个项目开始，往往是通过直接攻破维护者的账户，或者针对项目的 Actions 工作流。 - **npm 为高影响力账户新增预防性账户保护**（https://github.blog/changelog/2026-06-25-npm-adds-preventive-account-protection-for-high-impact-accounts/）（2026 年 6 月）：通常情况下，攻击始于针对维护者的钓鱼活动。通过此项变更，高影响力的 npm 账户在更改电子邮件或使用 2FA 恢复码时，将进入 72 小时的只读模式。这个延迟让维护者有时间在账户被用于发起攻击之前做出响应并恢复账户。 - **为 GitHub Actions checkout 设置更安全的 pull_request_target 默认值**（https://github.blog/changelog/2026-06-18-safer-pull_request_target-defaults-for-github-actions-checkout/）（2026 年 6 月）：项目 CI/CD 管道中一个常见漏洞是“pwn 请求”（https://securitylab.github.com/resources/github-actions-preventing-pwn-requests/），即工作流在收到来自 fork 的拉取请求时触发，并执行来自该 fork 的用户提交且不受信任的代码。我们更改了 `actions/checkout` 的默认行为，防止在常见利用触发器中签出来自 fork 的不受信任代码，除非你明确选择退出（并在评估风险后）。此项变更及其向后移植到旧版本的措施，切断了导致 GitHub Actions CI/CD 工作流中代码执行和初始项目入侵的最常见易受攻击代码模式之一。 - **控制触发 GitHub Actions 工作流的人员和事件**（https://github.blog/changelog/2026-06-18-control-who-and-what-triggers-github-actions-workflows/）（2026 年 6 月）：也许你更愿意完全选择退出这些有风险的 Action 触发器，或者限制谁可以触发它们。这一新控制功能允许你在企业、组织或仓库级别设置策略，规定允许谁触发工作流以及允许哪些触发器类型。这些工作流执行策略为 Action 工作流提供了一层可管控且可定制的“最小权限”保护，从而减少了 CI/CD 基础设施的攻击面。 - **针对不受信任触发器的只读 Actions 缓存**（https://github.blog/changelog/2026-06-26-read-only-actions-cache-for-untrusted-triggers/）（2026 年 6 月）：攻击者在 Actions 工作流中实现代码执行后，会试图通过污染跨工作流共享的缓存条目来提升到权限更高的工作流（从而获取更高凭据）。通过此项变更，我们限制了信任度较低的工作流修改与其他工作流共享的缓存的能力。这直接堵住了攻击者常用的一条路径，即把一个影响有限的漏洞升级为能够破坏发布和发布工作流使用的高权限凭据的漏洞。 ## 窃取凭据 一旦攻击者访问到单个包，他们就会专注于检测并窃取凭据，以便在生态系统中进行进一步访问和后续利用。 - **npm 可信发布现已支持 CircleCI**（https://github.blog/changelog/2026-04-06-npm-trusted-publishing-now-supports-circleci/）（2026 年 4 月）：阻断这些攻击最重要的一点就是从 CI/CD 管道中移除长期有效的凭据。可信发布（https://docs.npmjs.com/trusted-publishers）是一种无需长期有效凭据即可授权发布到包仓库的好方法。通过将 CircleCI 添加为可信发布提供商，我们让更多人能够移除这些攻击试图窃取的凭据。 - **Actions 网络防火墙**（https://github.com/github-early-access/actions-native-egress-firewall/）（技术预览中）：该技术预览会记录 Action 工作流运行的所有出站网络流量，以便你检测异常行为，例如拉取恶意代码或将凭据泄露到新域名。未来的工作将启用网络出站限制和策略，在攻击导致进一步升级和泄露之前将其阻断。 ## 传播攻击 利用上一步窃取的凭据，攻击者试图使用这些凭据尽快分发恶意软件，并入侵更多项目和维护者。 - **npm 分段发布**（https://github.blog/changelog/2026-05-22-staged-publishing-and-new-install-time-controls-for-npm/）（2026 年 5 月）：有了分段发布，仅凭凭据不足以在 npm 上发布新包；这些包会被暂存，直到在 npm CLI 或 npmjs.com 上提供额外批准和 2FA 身份验证。这种可选的安防控制允许维护者确保他们发布的任何版本都经过了这种额外授权。通过将 CI/CD 管道和自动化中使用的凭据与能够发布到注册表的凭据解耦，从 CI/CD 管道到恶意软件分发的攻击链就被切断了。 - **npm v12 即将推出的重大变更**（https://github.blog/changelog/2026-06-09-upcoming-breaking-changes-for-npm-v12/）（2026 年 6 月）：为了尽快传播恶意软件，攻击者利用 npm 安装时脚本窃取凭据，而不是等待包在运行时执行代码。在 npm v12 中，我们将推出一个重大变更，默认禁用这些安装脚本。由于安装脚本在几个流行包所依赖的包安装过程中有合法用途，你可以通过批准特定脚本来重新启用它们。其他安装时代码执行的向量也已被阻止，默认禁用了通过 git 或远程 URL 的依赖项。 - **Dependabot 版本更新引入默认包冷却期**（https://github.blog/changelog/2026-07-14-dependabot-version-updates-introduce-default-package-cooldown/）（2026 年 7 月）：攻击者依赖速度，希望在任何人注意到之前，恶意版本能够被尽可能多的下游项目拉取。通过 Dependabot 进行的版本更新现在会等待发布至少三天后才会打开拉取请求，这样在恶意版本到达你的项目之前，检测信号就有时间浮现。此冷却期默认开启，而安全更新仍然立即打开，因此关键修复永远不会延迟。 ## 识别和响应供应链攻击 在强化 npm 和 GitHub Actions 以阻断和限制供应链攻击影响的同时，我们也在努力为用户提供功能和工具，以识别和响应影响其项目和账户的供应链安全事件。 - **用于事件响应的自助凭据撤销**（https://github.blog/changelog/2026-06-24-self-service-credential-revocation-for-incident-response/）（2026 年 6 月）：GitHub 凭据仍然是供应链攻击中攻击者的持续目标。此功能提供了自助工具，可以立即撤销企业中某个用户的所有凭据。这建立在 2 月发布的企业级凭据管理工具（https://github.blog/changelog/2026-02-17-enterprise-wide-credential-management-tools-for-incident-response/）基础之上，允许企业管理员和成员在供应链攻击中凭据被泄露时快速响应。 - **扩展的凭据撤销 API 支持**（https://github.blog/changelog/2026-03-26-credential-revocation-api-now-supports-github-oauth-and-github-app-credentials/）（2026 年 3 月）：近期的攻击包括在公开可访问的内容中窃取凭据。为了帮助社区应对这些攻击，我们扩展了凭据撤销 API 的支持范围（最初于 2025 年 4 月为个人访问令牌推出（https://github.blog/changelog/2025-04-29-credential-revocation-api-to-revoke-exposed-pats-is-now-generally-available/）），以支持撤销 GitHub OAuth 和 App 令牌。这使得无论这些泄露的凭据在何处被发现，都能快速自助撤销，并限制其可能被滥用的生命周期。 ## 下一步计划？ 让我们的产品默认更安全是 npm 和 GitHub 的优先事项，我们正优先推进这项工作，以瞄准并阻断整个开源生态系统中的供应链攻击。我们对过去几个月为达成这一目标而交付的工作感到自豪。未来还有更多工作要做，但我们希望及时汇报已取得的进展，并让大家了解可用的新功能。请务必关注我们的更新日志（https://github.blog/changelog/?label=supply-chain-security）和博客文章，我们将继续推出改进。 开源软件是一种令人惊叹的公共产品，我们所有人都从中受益。这也是 GitHub 致力于继续支持开源社区及其依赖的企业安全性、可持续性和持续成功的多种方式之一。 ## 作者 Greg Ose 首席产品安全工程师 Zachary Steindler 首席软件工程师，GitHub ## 相关文章 ### GitHub 如何为每个仓库赋予永久所有者（https://github.blog/security/application-security/how-github-gave-every-repository-a-durable-owner/） GitHub 拥有超过 14,000 个仓库。其中不到一半有明确的所有者。以下是我们如何在 45 天内为每个活跃仓库赋予已验证的所有者，归档其余仓库，并将所有权作为后续一切工作的基础。 ## 更多来自 GitHub 的内容 文档 ### 文档 掌握 GitHub 所需的一切，尽在一处。 前往文档（https://docs.github.com/） GitHub ### GitHub 在 GitHub 上构建未来，这里是任何人从任何地方构建任何东西的地方。 开始构建（https://github.com/） 客户故事 ### 客户故事 了解使用 GitHub 构建的公司和工程团队。 了解更多（https://github.com/customer-stories） GitHub Universe 2026 ### GitHub Universe 2026 2026 年 10 月 28-29 日，让我们在旧金山或线上相聚 GitHub Universe——我们的旗舰开发者盛会，汇聚人才、代理与世界代码。 立即注册（https://githubuniverse.com/?utm_source=Blog&utm_medium=GitHub&utm_campaign=module_uni_26）