GitLab 安全事件：尝试利用 CVE-2026-97229

漏洞性质与供应链问题

• GitLab 的问题源于 Ruby 的 regexp 引擎中的 bug，而不是 GitLab 自己的代码。
• GitLab 的官方包会随附带一个 out-of-tree 补丁的 Ruby；Alpine 的 GitLab 镜像使用的是“正常”的 Ruby，即使升级了 GitLab 本身仍然存在漏洞。
• 由于 Ruby 没有为其修复申请 CVE，按 GitLab 版本（或 Ruby CVE）来判断的漏洞扫描器会错误地把某些镜像视为安全。

升级、依赖与构建实践

• 自行构建镜像并固定依赖会创建“本地缓存”，需要主动维护；否则就会错过关键修复。
• 许多生态系统（Ruby、PHP、Python、JS、Lua 等）中，运行时升级都很慢，因为版本在应用中被强行固定。
• 评论者认为，几乎持续进行的自动化重建、依赖追踪和滚动升级正变得不可避免。

暴露面：VPN、零信任与公共服务

• 一些人认为，自托管工具应该放在 VPN 或具备身份感知的代理后面；只有真正有安全团队的组织才应该把它们公开暴露。
• 其他人指出，“零信任”并不意味着“公开可访问”，而是意味着在应用边缘实施强访问控制。
• 有人提出这种利用是否也可能在 VPN 内发生；含义是，只要易受攻击的服务可达，答案就是会。

SaaS 与自托管，以及欧盟数据问题

• 争论焦点在于，欧盟公司是否能合法地把敏感数据托管给非欧盟 SaaS 提供商（例如由于 GDPR 和 CLOUD Act）。
• 一些人表示 SaaS 厂商提供欧盟数据驻留选项；另一些人则不信任关于数据主权以及客户数据被用于 AI 训练的说法。
• 用“vibe-coding”在内部替代 SaaS 从成本上看很有吸引力，但如果没人长期负责安全和维护，就会很有风险。

语言、内存安全与来自不可信输入的 Regex

• 人们对反复出现的 C 库 bug（整数溢出、双重释放）感到沮丧，并呼吁把面向网络的代码从 C 迁走。
• 反方观点是：重写一切并不现实；即便是 Rust 重写（例如 sudo/coreutils 类似项目）也会有 bug。
• Rust 这类内存安全语言无法阻止所有逻辑 bug（例如 regex 爆炸、整数回绕），但有助于防止常见的 RCE 向量。
• 有些人坚持认为，从不可信输入编译 regex 本身就很危险；另一些人则质疑这种说法应该延伸到什么程度。

容器、标签与扫描

• Alpine 重新发布了 19.3.6 镜像并更新了 Ruby；有人认为他们应该更改标签，也有人说标签表示的是应用版本，而不是镜像不可变性。
• 建议是按 digest（SHA）固定镜像，并使用诸如 Renovate 之类的工具跟踪变化。
• 一个“棘手”之处在于：基于版本的扫描器会把这个有漏洞的镜像误判为已修复，因为 GitLab 版本已经超过了补丁阈值，而 Ruby 隐藏的补丁又没有 CVE。

GitLab 的替代方案与事件响应

• 有人建议改用更简单的 forge，例如 Forgejo 或 Gitea，以减少攻击面；也有人指出这些项目同样会积累 CVE，只是到目前为止比 GitLab 少。
• 一些人认为，只要有足够的资金和先进工具（包括 AI），大型、广泛使用的开源栈可以被系统性加固。
• Alpine 透明的事后分析和保守的响应方式（把“没有证据”视为不足以证明安全）被赞为负责任的做法。