GitHub 推出包防火墙，公开预览版上线

越来越多的恶意软件攻击在包安装阶段利用系统，甚至在包代码尚未运行时就在 CI/CD 主机或开发者工作站上窃取凭证。为了遏止这类攻击，GitHub 正在推出一项新的包防火墙能力。包防火墙位于 Actions runner 或编码代理等端点与上游包仓库之间，检查元数据请求和包下载是否存在恶意活动的迹象。包防火墙今天以公开预览形式面向所有 GitHub Enterprise Cloud 客户提供，包括数据驻留版 GitHub Enterprise Cloud。

首先，管理员为其企业设置策略控制。目前可用的控制包括可配置的冷却期、检查 GitHub Advisory Database 中的恶意软件或漏洞告警，以及诸如证明降级之类的供应链检查。然后，编码代理和 CI/CD 主机等端点需要配置为通过防火墙发送请求，而不是直接指向上游包注册表。针对包列表的元数据请求以及实际的包下载随后流经防火墙，由防火墙根据策略对其进行评估。如果某个包被错误阻止，用户可以通过与其他 GitHub Advanced Security 功能类似的工作流申请例外。

包防火墙以公开预览形式提供，我们正在扩展其背后的基础设施，并继续根据客户需求增加功能。它面向 GitHub Enterprise Cloud 客户提供，包括具有数据驻留的 GitHub Enterprise Cloud。在预览期间该服务免费。当它达到正式可用时，将按计量使用量收费，类似 Actions 计费。目前包防火墙仅支持 npm 包。有关详细设置说明，请参阅“使用包防火墙保护端点”。欢迎在 GitHub Community 参与讨论。

GitHub 发布包防火墙公开预览版：它部署在 Actions runner、编码代理等端点与上游包仓库之间，检查元数据请求与包下载中的恶意迹象；企业管理员可设置冷却期、恶意软件与漏洞告警检查、证明降级等供应链策略，目前仅支持 npm，预览期免费。

• GitHub 发布包防火墙公开预览版：它部署在 Actions runner、编码代理等端点与上游包仓库之间，检查元数据请求与包下载中的恶意迹象；企业管理员可设置冷却期、恶意软件与漏洞告警检查、证明降级等供应链策略，目前仅支持 npm，预览期免费。
• 原贴提到：An increasing number of malware attacks exploit systems at package insta
• 来源：github.blog

这是什么信号

GitHub 把安全防线从“装完之后扫描”提前到“安装那一刻拦截”。包防火墙是部署在 Actions runner、编码代理与上游 registry 之间的中间层，同时看两类流量：查询包列表的元数据请求，以及真正下载的包本体。这意味着一批传统 SCA 或依赖扫描工具看不到的攻击面——安装脚本、post-install 钩子、凭证读取——被拉进了可策略化的范围。

策略侧目前给了三类抓手：可配置的冷却期（新发布包先别急着用）、对接 GitHub Advisory Database 的恶意软件与漏洞告警、以及证明降级这类供应链完整性检查。被误拦时可以走类似 GitHub Advanced Security 的例外申请流程，说明 GitHub 把它当作既有安全治理体系的一部分，而不是独立产品。

为什么重要

攻击者的成本结构变了。过去投毒包需要诱导开发者运行代码，现在只要在安装阶段触发即可在 CI/CD 主机或开发者工作站上收割凭证——这些机器往往持有云凭证、发布令牌、仓库写权限,一次得手的影响远大于一个本地开发环境。而 AI 编码代理的普及让“自动安装依赖”变成高频、无人监督的动作，风险敞口被进一步放大。

GitHub 选择在端点侧做管控而不是只做 registry 侧的黑名单，等于承认了一件事：上游生态的清白无法被完全保证，只能在消费端加一道可审计、可回滚的闸门。

对谁有价值

• 使用 GitHub Enterprise Cloud（含数据驻留版）的平台工程与安全团队，尤其是已经跑大量 Actions 工作流、且 CI runner 持有高权限凭证的组织。
• 正在把编码代理接入真实仓库的团队——代理自动拉依赖的行为需要一条能被策略约束的通路。
• 受合规或供应链审计约束、需要“安装前有控制点”这一叙述的团队。

价值有限的情形也很清楚：只用 npm 之外生态（Python、Go、Maven 等）的团队目前拿不到直接收益；非 Enterprise Cloud 客户也不在覆盖范围内。

可以怎么行动

1. 先盘点：哪些工作流和代理会直接访问上游 registry，其中哪些持有高价值凭证。这是判断优先级的最短路径。
2. 在企业级先立策略再做接入。冷却期是最容易落地的一档，对内部快速迭代的团队需要提前沟通豁免规则，否则会变成抱怨来源。
3. 把端点改成经防火墙请求，而不是直连 registry——这一步是真正见效的前提，没有端点改造，策略只是纸面配置。
4. 设计例外通道：明确谁能申请、审批标准是什么、误拦时的兜底路径，避免安全团队成为瓶颈。
5. 关注计费拐点。预览期免费，正式可用后按计量收费、类似 Actions 计费，接入前最好预估流量规模，避免账单意外。

风险与限制

• 覆盖面窄：当前仅支持 npm。你的真实依赖面大概率不止于此，不要把它当成完整供应链防线。
• 预览期属性：基础设施仍在扩容，功能会随客户需求调整，不适合作为强承诺写进合规文档的核心控制项。
• 策略误伤：冷却期与告警检查都会产生误拦，例外流程若设计不当，会拖慢发布节奏，团队可能绕道直连。
• 单点依赖：防火墙成为端点与 registry 之间的必经之路，其可用性直接影响构建与代理运行。
• 并非零信任终局：它检查的是安装时行为线索，不等于对包内容的完整审计，绕过手法会持续演化。

这条内容的真正价值，不只是“有人发布了一个新功能”，而是它揭示了 github.blog 背后的产品方向、工作流变化或竞争信号。对 OPC 来说，这种信息可以转化成持续追踪的栏目选题。

如果把《GitHub 推出包防火墙，公开预览版上线》放到你的内容系统里，它最大的价值在于帮助读者更快看懂“为什么值得关注”，而不是只看到一条碎片化动态。

• Allison 原帖