GitHub 加固默认安全策略，延时防护与软件包签名之争引热议

GitHub 汇总了其在 2026 年 3 月至 7 月期间针对 npm 和 GitHub Actions 推出的各项变更 ，以打击供应链攻击。这篇文章中没有任何新内容，因为每一项变更都已通过更新日志发布；不过，文章清楚地表明了这些变更有多少是修改默认设置，而非新增选项。

首席产品安全工程师 Greg Ose 和首席软件工程师 Zachary Steindler 认为，该问题不存在单一的根治方案。这些攻击将多个漏洞串联在一起，因此 GitHub 优先采取了能够切断破坏力最强的攻击链路的缓解措施。

针对初始入侵，npm 现在会在高权限账号更改邮箱地址或使用 2FA 恢复码时将其置于只读模式 72 小时。在 GitHub Actions 方面， actions/checkout 的默认行为已更改，工作流不再在常被利用的触发器下检出不受信任的分支代码，除非团队明确选择关闭该防护。该变更已回溯移植，即使流水线固定了早期版本也会生效。

另外两项控制措施用于阻止攻击者权限提升。 工作流执行策略 允许管理员控制谁可以触发工作流以及允许哪些触发类型，GitHub Actions 缓存现在对不受信任的触发器设为只读，封堵了攻击者通过污染共享缓存条目来触及特权发布工作流的路径。

针对凭证外泄问题，官方给出的建议十分直白：从流水线中移除长效凭证是效果最好的解决手段；同时 npm 可信发布 功能现已支持 CircleCI。GitHub Actions 网络防火墙目前处于技术预览阶段，该组件会记录所有出站流量，方便开发团队发现异常外联地址。

针对恶意代码扩散传播，npm 分阶段发布 功能会在版本发布前等待额外的审批和 2FA 验证，而 npm v12 默认禁用了安装脚本和通过 git 或远程 URL 拉取依赖包。 Dependabot 版本更新 现在会强制等待三天冷却期。

Hacker News 社区的反馈呈现出两极分化，争论的焦点不在于各项单独的控制措施，而在于时间延迟机制是否是正确的手段。

72 小时账户冻结机制立即引发了对该时长设定依据的争论。正如评论者 datakan 所说，维护者会出差、休假，而攻击者往往特意选择周五发动攻击，正是因为周末无人值守：

当有人生病或出差且无人打理时，3 天和 30 天之间存在巨大差异，后者更符合 99% 可能出现问题的场景。3 天是不合理的。即使是带有终止开关的密码应用，默认也是 7 天。

也有一部分人并不认同“存在某个唯一合理时长”。每一个时长都会引出更长的时长，倘若设置长达一个月的发包封禁期限，就必须配套一套临时解除限制的通道。评论者 Normal_gaussian 提出了基于经验的方案：统计被入侵仓库数量与维护者开始解决问题所需时间的对比关系，绘制出图表，然后选择一个刚好超过拐点的时长。

lrvick 提出了更尖锐的反对意见，他描述了自己如何花 8 美元购买了一个 npm 包唯一作者已经过期的邮箱域名，然后通过密码重置向大约 7 万家公司推送代码：

他进一步延伸观点，成为讨论帖主要的批评论调：行业一直在构建流程关卡，却拒绝实施 Linux 发行版自 1990 年代以来就拥有的作者端包签名机制，而 npm 十年来一直拒绝合并实现该功能的 PR，即便是做成可选开启模式。

acdha 提出了反驳观点，他认为真正让 Linux 发行版更安全的是拥有推送权限的人更少，再加上时间延迟，而非签名本身：

让 Linux 发行版更安全的是拥有推送权限的人更少，而且有时间延迟。被入侵的原因是人们利用了发布流水线，如果你的构建基础设施被入侵，这套签名系统照样会乖乖为遭篡改的恶意软件包完成签名。

评论者 summarybot 将冷却期方法视为 GitHub 承认自身防护体系已经失败，鉴于 GitHub 拥有 npm 并具备强大的代码分析能力：

引入冷却期似乎是我很久以来见过的对技术问题最低技术含量的解决方案。

insanitybit 从运维实操角度给出了相反观点：冷却期不依赖于更新检测规则或跟上混淆技术的步伐，它为扫描器争取了时间。

可信发布机制引发了最为务实的讨论，起因是有人提出疑问：当攻击者已经入侵了工作流，可信发布为何还能起到防护作用？正如评论者 pimterry 解释的那样：

可信分阶段发布机制的作用很大：你必须单独入侵工作流，然后作为维护者完成一个独立的 2FA 验证流程。工作流永远接触不到可用于独立发布包的密钥。

其他人补充说，攻击者必须触发特定的工作流，这会在 GitHub 上留下痕迹。

如果这些社区观点具备代表性，那么分歧不在于各项单独的控制措施是否有用，而在于它们替代了何种安全方案。GitHub 选择了无需维护者参与即可生效的机制，而从业者一直要求的机制——作者端签名——恰恰需要维护者亲自参与配置管理，并且十年来一直以“会吓跑贡献者”为由被拒绝。

值得留意的失衡现状是：自动生效的变更都只是强度适中的防护手段，而最强的保护——分阶段发布和可信发布——仍然是可选的，采用情况参差不齐。npm v12 中安装脚本的变更会导致那些从未审计过安装阶段执行脚本的项目出现构建失败问题。

这些变更正在逐步推出，GitHub 指引用户查看其更新日志以获取更详细的信息。

查看英文原文： https://www.infoq.com/news/2026/08/github-npm-actions-defaults/