GitHub Package Firewall 公测：你的 coding agent 装的每个包，先过一遍安检

GitHub 10 月 20 日在官方 changelog 上宣布：Package Firewall 进入公开预览（public preview）。一句话概括：它是挡在你的 Actions runner、coding agent 与上游 npm 仓库之间的一道装包安检门——每个包在下载之前，先过五道检查，政策不允许就装不了。

这件事之所以值得写，不是因为它又多了一项企业安全功能，而是因为它第一次把“装包策略”推到了 coding agent 基础设施的前台。从前 npm install 是程序员自己敲的命令，出事了人去看日志、删包、换版本；现在是 agent 替你装包，一个指令下去它可能装十几个你从没听说过的依赖，你连包名都来不及扫一眼。当装包的人从“人”变成“agent”，装包的安全策略就第一次成了 agent 基础设施的一等公民。

GitHub 的官方措辞点出了时代背景：“越来越多的恶意软件攻击利用包安装时机，在 CI/CD 主机或开发者工作站上收割凭证，甚至不需要运行这个包的代码。”（changelog 原文）供应链攻击已经从“跑起来才爆炸”，前移到了“安装时就偷凭证”。

它到底站在哪里、做些什么

位置很关键：Firewall 不是装在你电脑上的杀毒软件，也不是扫描 lockfile 的静态工具。它是一个企业专属的 npm registry 代理：管理员在企业侧配置好政策，然后把 coding agent、CI 构建机、开发机的 .npmrc 里的 registry 指向 https://package-firewall.githubapp.com/npm/enterprises/<企业名>，装包请求和元数据请求都会先经过它，再按政策放行或拦截。（官方文档）

五道检查是这么配置的（默认值来自官方文档，撰稿时亲核）：

• 冷却期（cooldown period）：新发布的版本先“晾”一段时间再允许安装。最小包龄可在 0–365 天之间配置，默认 1 天，设为 0 即关闭。这就是“给 AI 的冲动消费加个犹豫期”——大多数供应链投毒包在发布后几天内就会被社区发现并下架，24 小时的晾置能挡住其中很大一部分。
• 恶意软件 Advisory 检查：查 GitHub Advisory Database 里的活跃恶意软件告警，命中即拦截，默认开启。
• 漏洞严重度阈值：查影响所请求版本的漏洞告警，可选只拦 Critical / High 及以上 / Medium 及以上 / 任意严重度，默认只拦 Critical。
• Attestation 降级检查：对比所请求版本与更早版本的签名证明（SLSA attestation）。如果一个包以前的版本都有签名证明，新版本却没有——发布流程很可能被劫持了，直接拦截，默认开启。
• 安装脚本检查：检查包是否新增了安装时运行的脚本（preinstall / postinstall）。这类脚本可以执行任意命令，是偷凭证的重灾区，默认开启。

误拦了怎么办？GitHub 借用了 Advanced Security 里已有的申诉模式：当 Firewall 拦截一个包时，npm 输出或 CI 日志里会附带一个申诉链接，点开就是预填好的申请表单（仓库、生态、包名、版本、理由），提交后由企业管理员或安全经理审批。批过的例外会写回策略，管理员也可以随时撤销。（官方文档）官方文档举的例子很实在：一个带安全修复的新版本，正好可能被“最小包龄”政策拦住——这时候申诉流就是救命通道。

接入方式对团队也算友好：token 只需要“对公开仓库的只读访问”权限（最小权限原则的示范）；已经在用 JFrog Artifactory 的企业，可以把它配成经过 Firewall 的远程仓库（官方标注“实验性支持”），公有包和私有包继续走同一套虚拟仓库，只是公有包多了一道安检。（官方文档）

为什么这件事对 agent 时代特别重要

先看威胁模型的变化。传统供应链攻击的逻辑是“潜伏”：恶意代码藏在包里，等你的应用跑起来、等 CI 跑到某个阶段才触发。但近两年的真实攻击越来越多地利用安装时机本身——preinstall 脚本在 npm install 的瞬间就能把环境变量里的 token、CI 密钥抄走，包的代码一行都不用跑。GitHub changelog 的原文把这个判断写得很直白：“harvesting credentials on CI/CD hosts or developer workstations without even running the package's code”。

再看“谁在装包”。人类开发者装包时，至少还有几个天然刹车：你会看一眼包名、看一眼周下载量、犹豫一下要不要装一个 3 天前刚发布的 0.0.7。但 coding agent 没有这些刹车——它接到“加个日期选择器”的指令，可能在 30 秒内装 5 个它“觉得合适”的包，不会告诉你每个包的发布时间、维护者变更史，更不会等你审批。agent 的“效率”恰好放大了安装时攻击的窗口。

这就是 Package Firewall 的真正位置：它不是在修补 npm 生态，而是在给“agent 替你装包”这个新默认行为补上缺失的安全层。冷却期这个设计尤其有味道——它本质上承认了一个事实：AI 做决策太快，快到需要人为地加一个犹豫期。给新版本 24 小时的“观察期”，让社区、安全研究员和 Advisory 数据库先替你看一眼，再让 agent 装。这是对 AI 冲动消费最克制的干预：不审查内容，只延迟时间。

Attestation 降级检查同样值得单独拎出来说。npm 的 provenance（来源证明）机制这两年逐渐铺开，越来越多的包带着“这个版本确实是从某次 CI 构建产出”的签名发布。攻击者劫持发布流程后，往往发不出带同样签名的版本——于是“以前有签名、这次没有”就成了一个极强的异常信号。Firewall 把这个信号产品化、默认开启，等于把 npm 生态这两年的信任基础设施建设直接变成了默认安全策略。这是平台级玩家才能做的事：单点工具很难拿到全生态的签名历史，GitHub 可以。

四个诚实提醒

第一，只支持 npm。这是 changelog 原文的最后一句，也是全文最短的一句：“Currently the package firewall only supports npm packages.” Python 的 PyPI、Rust 的 crates.io、Go modules 都不在覆盖范围——而 vibe coder 的技术栈早就不限于 JS。GitHub 说会“根据客户需求继续加功能”，但在那之前，它只解决你依赖树的一部分。

第二，Enterprise Cloud 门槛。公开预览只面向 GitHub Enterprise Cloud 客户（含数据驻留版），个人开发者、小团队、开源项目用不上。这是企业安全产品的标准打法，但也意味着：最需要被保护的恰恰是那些“agent 随便装包”的个人 vibe coder——他们不在门内。

第三，冷却期是有代价的。默认 1 天听起来不痛不痒，但对“今天发现 0day、今晚就要打补丁”的场景，每一次紧急升级都可能触发申诉流。虽然申诉链路设计得不错，但它本质上把“安全延迟”转化成了“流程延迟”——团队得想清楚，哪些包值得走例外、谁来批、多久能批下来。否则安全策略会变成开发速度的隐形税。

第四，它只管“下载时”，不管“运行时”。Firewall 的检查发生在包下载的那一刻：它能拦下已知恶意包、拦下可疑的新版本，但拦不住一个“干净但有漏洞”的包在运行时被 exploit，也替代不了 Dependabot、code scanning 这些持续治理工具。它是纵深防御里新加的一层，不是终点。

另外计费口径需要透明度标注：GitHub 官方说法是预览期免费，GA 后按量计费，计费方式“类似 Actions billing”。（changelog 原文）具体是按请求数、按流量还是按分钟，目前没有更细的数字——这是厂商口径，企业做预算时要留余量。

“安装时攻击”到底是怎么偷凭证的

为了理解 Firewall 为什么把检查点放在“下载时”，有必要把攻击链拆开看。一个典型的 npm 供应链投毒包长这样：攻击者先通过钓鱼、凭证复用或维护者账号劫持拿到某个流行包的发布权限，然后发布一个补丁版本号的新版本（比如从 4.2.1 到 4.2.2——看起来人畜无害）。新版本的 package.json 里藏着一个 postinstall 脚本，内容可能只有几行：读取 process.env 里的 NPM_TOKEN、AWS_SECRET_KEY、CI 环境变量，把它们 POST 到攻击者的服务器。整个过程发生在 npm install 的几秒钟之内，包的“正常代码”甚至可以是完全干净的——因为它根本不需要运行。

这就是为什么传统的“跑起来再检测”思路在这里失效：恶意行为发生在依赖解析和代码执行之间那个无人看管的灰色地带。代码扫描工具看的是包里的 JS/TS 有没有恶意逻辑，但 postinstall 脚本在 npm 的执行模型里是“合法功能”；lockfile 审计看的是已知漏洞，但一个刚发布 2 小时的投毒包，Advisory 数据库里还没有它的记录。Firewall 的五道检查，本质上是给这个灰色地带逐一上锁：安装脚本检查管“行为”，冷却期管“时间窗口”，恶意软件 Advisory 管“已知坏人”，attestation 降级管“发布流程是否被劫持”，漏洞阈值管“已知风险”。

值得注意的是，GitHub 把“元数据请求”也纳入了检查范围（changelog 原文：“inspecting both metadata requests and package downloads”）。这意味着攻击者连“试探哪些包存在、哪些版本可装”这种侦察行为，理论上也会经过策略评估——虽然官方没有展开说元数据检查具体拦什么，但把检查前移到“你连包列表都还没拿到”的位置，思路是对的：供应链防御越早介入，成本越低。

它和你已有的工具是什么关系

看到“装包安检”，很多人第一反应是：这不就是 npm audit / Socket.dev / Dependabot 吗？有重叠，但位置完全不同：

• npm audit / Dependabot：事后诸葛亮。它们扫描的是已经写进 lockfile 的依赖，告诉你“这个版本有已知漏洞，升到 X.Y.Z”。而 Firewall 是事前门卫——包还没下载就先拦，拦的是“未知恶意”和“可疑新版本”，不只是“已知漏洞”。
• Socket.dev 这类第三方防火墙：理念最接近（Socket 也有安装时行为分析），但它们是外部服务，要单独采购、单独集成。GitHub 的优势是原生位置：registry 本来就是它的（npm 注册表 2020 年起归微软/GitHub 运营），Advisory 数据库也是它的，Actions runner 也是它的——检查、数据、执行端点三者同属一个平台，策略可以下沉到“换一行 .npmrc 就生效”的程度，这是第三方做不到的接入成本。
• 代码扫描（code scanning）/ secret scanning：管的是“你的代码写得安不安全”“密钥有没有提交进仓库”，不管“你装的包安不安全”。Firewall 补的是依赖引入这一环。

所以准确的定位是：纵深防御里新增的一层，专门负责“依赖进入组织的那一瞬间”。它不替代任何现有工具，而是把原来靠“开发者自觉 + 事后审计”覆盖的环节，变成了强制执行的网关策略。对安全团队来说，最大的价值可能不是拦下了多少恶意包，而是第一次有了一个可审计、可回滚、可申诉的装包政策面：谁在什么时候因为什么政策装了什么版本，全部有记录；误拦有申诉流，不再是安全团队在 Slack 里口头说“别装那个包”。

企业落地：三步走，但有三处坑

官方文档给出的接入路径很直白：① 企业管理员在 Policies → Package firewall 里配好五道检查；② 把各端点的 registry 指向 Firewall 的企业专属 URL，token 只给“只读公开仓库”权限；③ 有 Artifactory 的企业可以把它配成远程仓库（实验性）。（官方文档）但真要落地，有三处坑值得提前想：

• 坑一：冷却期默认 1 天，对“热修复”不友好。安全团队自己打补丁时，最需要的就是“立刻装上带修复的新版本”——而这恰恰是冷却期最可能拦截的场景。官方文档自己也承认了这一点，并把它作为申诉流的典型用例。建议：上线第一周就把“安全修复版本走快速申诉通道”的流程定下来，明确谁有审批权、SLA 是多久，否则第一次 0day 就会让大家想关掉整个 Firewall。
• 坑二：attestation 降级检查可能误伤“老实但不签名”的包。npm 生态里带 provenance 签名的包比例还在爬坡中，一个包“以前没签名、现在也没签名”不会触发（比较的是“以前有、现在没有”），但那些“偶尔签名、偶尔不签名”的包会被拦。建议：先用审计模式（如果后续版本提供）跑两周，看拦截清单里有多少是误伤，再决定默认开启还是收紧。
• 坑三：只覆盖 npm 的依赖树是“半扇门”。一个典型 monorepo 里可能同时有 npm、pip、cargo、Go modules。只给 npm 上锁，攻击者（或犯迷糊的 agent）换一条生态照样畅通。落地时要诚实地向管理层说明覆盖边界，避免“我们上了 Firewall 所以供应链安全了”的错觉。

另外，预览期的“免费”是真实福利，但 GA 后的“按量计费（类似 Actions billing）”目前没有任何数字。企业现在就可以做的，是先统计自己每月的装包请求量级——CI 跑了多少次 npm ci、agent 会话装了多少包——等 GA 定价一出，立刻能算出账单量级，而不是被动接受。

vibe coder 现在能做什么

你大概率不是 Enterprise Cloud 客户，用不上 Firewall 本体。但它的五道检查，恰好是一份“个人装包安全清单”——每一道都有你今天就能做的平替：

• 给自己设一个“土制冷却期”：让 agent 装包前先报包名和版本号，你扫一眼发布时间——npm 页面和 npm view <pkg> time 都能看到。刚发布几小时的版本，先别装。把这条写进你的 agent 指令（AGENTS.md / CLAUDE.md）里：“安装任何新依赖前，先向我报告包名、版本和发布时间，等待确认。”
• 锁死 lockfile 并审查安装脚本：package-lock.json 提交进仓库是底线；npm install --ignore-scripts 可以先装完再逐个审查 preinstall 脚本——这正是 Firewall 默认开启的那道检查的人工版。
• 认准带 provenance 的包：优先选带 npm provenance（SLSA 签名）的包，npm audit signatures 可以验证。对应 Firewall 的 attestation 降级检查——签名历史断裂就是红旗。
• 给 agent 的 token 最小权限：Firewall 官方文档示范了“只读公开仓库”就够装包；同理，你给 coding agent 配的 token、CI secret，也只给它完成任务所需的最小权限。被偷走的凭证如果本身权限就很小，损失面也小。
• 定期跑 npm audit：对应 Firewall 的漏洞严重度检查。它的默认值是“只拦 Critical”——个人项目也可以先从这个阈值开始，不必一上来就追求零漏洞。

和站内已有的 《Vibe 项目依赖供应链安全指南》划个界：那篇是方法论——教你作为独立开发者如何系统性地防护依赖供应链；这篇是产品新闻——GitHub 把其中几道检查做成了企业级基础设施。两篇互补，不重复。

接下来看什么

三个值得跟踪的信号：一是 GA 定价——按量计费的具体口径（按请求数还是按流量）将直接决定中小企业愿不愿意长期用，这也是 GitHub 在预览期“根据客户需求加功能”之外最需要给出的答案；二是生态扩展——PyPI 会不会是下一个，官方文档里“currently, only npm is supported”的措辞留了明确的口子；三是社区讨论——GitHub 在 changelog 里附了社区讨论帖，第一批吃螃蟹的企业会在那里留下真实的误拦率和申诉体验，比官方文档更值得看。

最后说一句判断：Package Firewall 的象征意义大于它的功能列表。它标志着平台方终于承认——当 AI 开始替人类执行 npm install 时，“谁来决定装什么”本身成了一个需要被产品化的安全问题。冷却期、申诉流、按量计费，这些设计都是在回答同一个问题：如何给一个比你快得多的执行者，加上恰到好处的刹车。npm 只是第一站，PyPI 和 crates.io 的版本不会太远——而个人开发者的“土制冷却期”，现在就可以开始。