在 GitHub 上发现超过 10 万个被感染的仓库
恶意行为者在 GitHub 上植入了超过 10 万个被感染的仓库，利用轻松创建账号和自动化手段，将供应链攻击隐藏在合法开源项目之间。评论者讨论平台和包管理器应承担多大责任，以及单个开发者该负起多少责任，并描述了从严格的环境隔离与沙箱化（VM、Qubes、容器）到依赖审计工具和信誉系统等各种防御做法。许多人认为，这反映出更深层的问题：现代软件对庞大、晦涩的依赖树以及对第三方代码的盲目信任依赖过重，而现有安全工具只能部分缓解。
开发者隔离与沙箱化
- 许多评论者现在把任何第三方代码都视为不可信，即使来自“正规”的仓库也是如此。
- 常见策略：工作、个人和业余项目分别使用不同的机器/VM，使用用后即毁的临时云 VM（例如 EC2），容器/devcontainers、Codespaces，以及类似 Qubes OS 的按活动划分的 VM。
- 有些人几乎所有开发都在远程进行；另一些人仍然更偏好本地开发，以获得控制力和性能。
远程开发与延迟
- 有些人认为远程桌面（Citrix、Guacamole、SSH + VNC/RDP）是不可避免的未来，而且在企业中已经很常见。
- 也有人表示，交互式工作（编码、窗口切换、游戏）会受到严重延迟和疲劳影响，即使是在同一国家内的企业环境中也是如此。
- 游戏和富媒体被认为对延迟的容忍度远低于“办公”或编码工作负载。
GitHub 的角色与感染规模
- 争论焦点在于：在一个拥有数亿仓库的平台上，约 10 万个恶意仓库究竟意味着“失败”，还是一个相对较小、可管理的问题。
- 据称 GitHub 会删除许多明显自动化生成的 fork；更隐蔽的恶意仓库则会存活下来。
- 较小的托管平台（例如 Codeberg）可能因为攻击者投入产出比太低而受到保护，但如果成为目标，也可能被压垮。
工具与缓解措施
- 做法包括：优先使用带代理/防火墙的包注册表（例如 Sonatype）、自托管 GitLab、通过 socket.dev 之类的服务审查包、使用 npm
--ignore-scripts、devcontainers，以及网络受限的构建服务器。 - 提到的工具：Trivy、Semgrep Supply Chain、Packj、LavaMoat、container-shell、cargo-audit/deny、npm audit。
- 一些评论强调，大多数工具发现的是已知漏洞，而不是新型恶意软件或后门。
依赖文化与供应链风险
- 对庞大、深层的依赖树提出强烈批评，尤其是在 JavaScript 中。传递依赖会大幅扩大爆炸半径。
- 有人认为团队应该编写更多自己的库，接受前期成本，并在关键系统中避免使用包管理器。
- 也有人建议在受控命名空间下对所有依赖做快照，从而“拥有”供应链。
信任、验证与责任
- 建议包括：更好地标识“官方”仓库、将组织验证与域名绑定、在包管理器层面建立信誉系统。
- 对于 GitHub 是否应该对代码进行筛选/信任评级，还是应作为中立托管方，存在分歧。
- 讨论还提到了国家安全机构（例如 CISA）是否应介入，以及归因有多困难。
LLM 与恶意软件
- 有人担心公共仓库中广泛存在的恶意软件会污染 LLM 训练，导致模型给出易受攻击甚至恶意的代码建议。
- 一些人认为这是危言耸听；另一些人指出，LLM უკვე 已经会输出不安全模式，因此人工审查必不可少。
- 相关想法包括：经过筛选的训练数据集，以及在训练和输出阶段使用恶意软件扫描或基于 AI 的过滤器。