GitHub 如何阻断 npm 和 GitHub Actions 供应链攻击
Disrupting supply chain attacks on NPM and GitHub Actions
过去一年，针对 npm 和 GitHub Actions 的供应链攻击频发，攻击者利用仓库和 CI/CD 系统的弱点迅速传播恶意软件并窃取凭证。我们近期推出了一系列关键更新来直接打断这些攻击链条：为高影响力 npm 账户增加预防性保护，修改 GitHub Actions 的默认行为以阻止不信任代码的执行，并引入 npm 的 staged publishing 机制。此外，通过支持 CircleCI 的 trusted publishing 和 Actions 网络防火墙预览功能，我们致力于从源头移除长期凭证并监控异常流量。这些措施旨在通过默认安全设置，切断从初始入侵到凭证窃取再到恶意软件传播的完整路径，为开源生态构建更坚固的防线。
供应链攻击将多个弱点串联在一起，没有任何单一的安全能力能够阻止它们。
HN 评论区
46- alpineman
>> 高影响力的 npm 账号在更改邮箱或使用 2FA 恢复码时，现在会被设为只读模式 72 小时。这段延迟让维护者有时间响应并恢复账号，防止其被用于发起攻击。
'时间设多久合适？'
'你喝醉后最长断片过多久？'
'那就定 72 小时吧'
- zzo38computer
我使用 GitHub Actions 的唯一场景是仅授予其向 issue 追踪器写入的权限。因此，如果它执行的程序（即 "gh" 程序）是恶意的，其造成的损害仅限于 issue 追踪器，而不会波及仓库本身（除非 GitHub Actions 自身被攻破）。此外，我没有托管任何私有文件（我不在 GitHub 等远程服务上托管私有文件），所以他们也无法窃取我的文件。
我认为一个有帮助的改进是支持双向 TLS（mTLS），使用 X.509 证书链进行身份验证。这比个人访问令牌更安全，允许你为自己和他人颁发令牌，无需先登录，并可指定所需的任何权限（作为颁发者权限的子集），同时设置过期时间。（你还可以将某个证书的私钥存储在未联网的独立计算机上，用它为自己颁发另一个证书来替代使用，也可以使用带密码的私钥（作为 2FA 的替代方案）。这样，即使你正在使用的证书被攻破，或被故意/非故意删除，你也能恢复；同时可以撤销那些已被攻破的证书。）
双向 TLS（甚至普通 TLS）并不能解决所有问题，但结合其他措施，包括限制访问仅为所需范围，以及避免依赖过多（因为依赖过多的程序 […]）
- summarybot
Github 拥有 NPM。Github 拥有前所未有的代码分析工具访问权限。Github 几乎可以对所有内容运行静态分析。引入冷却期似乎是我很久以来见过的解决技术问题最低端的技术方案。
- lrvick
真令人着迷，人们宁愿做任何其他事，也不愿让作者像 1996 年以来所有重要的 Linux 包管理器那样对软件包进行加密签名。
像 debian/apt 这样的 Linux 包管理器也分发数百个已签名的 NPM 包。换句话说，无偿的 Linux 社区再次解决了微软根本未能解决的问题。有些东西从未改变。
- skipants
有一点我不太明白：可信发布（trusted publishing）究竟如何更安全？如果攻击者攻破了你的工作流，它仍然允许发布。
难道仅仅是因为这样他们就无法窃取你的密钥再次发布？
我觉得如果你的工作流被攻破，你本来就会轮换密钥，所以我不确定这种厂商锁定是否值得。