LLM 批量挖洞，开源项目的安全成本正在提前到来

Metabase 在 5 月 14 日的工程博客里提到一个变化：发到 security@metabase.com 的安全报告，过去平均每月约 10 起。多数是扫描器误报，或者价值很低的问题。

到了 2026 年初，这个节奏变成了每周约 10 起。更麻烦的是，里面不再只是噪音。Metabase 说，不少报告确实指向真实问题，虽然多数并不严重。

这不是全行业统计，也不能拿来推算所有开源项目的漏洞增长率。它更像一个早期信号：LLM 和代码代理正在把“读代码、找可疑路径、生成报告”这件事变便宜。

我更在意的是成本位置变了。开源项目过去常把安全响应当成偶发事件，现在可能要按持续事件来准备。

漏洞报告从低质扫描，变成低成本有效发现

Metabase 看到的变化很具体：数量上去了，质量也上去了。报告常见 Markdown 格式，读起来像由 LLM 生成。但原文没有说所有报告都来自 LLM，也没有把原因归到某一家厂商或某一个模型。

更稳妥的判断是：代码代理整体更会读代码了。它们能顺着鉴权、配置、接口调用、异常处理这类路径往下走，找到传统浅层扫描不容易稳定命中的问题。

Metabase 作者提到，团队试用了几家相关安全扫描产品后，也发现了更多问题。幸好多数是小问题。

但“小问题”不等于“小成本”。每一封报告都要判断真假、复现、分级、修补、发布、沟通。对小团队来说，这些工作会吃掉正常开发时间。

原文标题里的 “strip mining” 很形象。它不是一次挖到最深处，而是把公开代码一层层刮开。以前自动化扫描多停在表层，深一点的漏洞依赖熟悉业务的人慢慢看。现在中间那一层，正在被代码代理填上。

这就是反常点：报告看起来更像批量生成，但它们不再只是批量垃圾。

开源没有因此失去价值，但短期更被动

开源安全的老话是“更多眼睛带来更少漏洞”。这句话还成立，但要加一个边界：对能被自动化发现的漏洞，更多眼睛不只包括维护者和善意研究员，也包括灰色团队、批量扫描服务，以及任何能跑代理的人。

公开源码的优势没有消失。它仍然方便审计、复现和修补。问题是节奏变了。

闭源软件并不天然更安全，只是攻击者通常不能直接拿到完整源码来反复跑代理。开源项目则不同。代码、历史提交、默认配置、调用路径都摆在那里。收到一份像样的漏洞报告时，维护者最好假设：外面也有人能找到同一个点。

这对两类人影响最大。

这里有个现实约束：很多开源项目不是公司产品，而是志愿维护。维护者没有 7×24 安全团队，也未必有足够权限推动下游升级。

所以短期压力会落在最不该被压垮的人身上：小项目维护者、单人维护者、商业公司大量使用但没有回馈的基础库作者。

Cal.com 近期宣布转向闭源，不能说是 Metabase 这篇文章直接导致的。更准确地说，这类趋势能解释商业开源公司为什么重新计算开放源码的代价。客户要安全 SLA，团队却可能被公开可发现的问题追着跑。

这不是“开源完了”。这是开源的透明性被自动化放大后，维护成本先暴露出来了。

使用 OSS 的团队，要按高频披露风险来管依赖

对企业工程和安全团队来说，最不该做的是把这件事当成“维护者那边的问题”。你用了 OSS，风险也在你的生产系统里。

动作可以很朴素，但要落地。

• 固定依赖版本，不要让生产环境长期处在“没人知道跑了什么”的状态。
• 监控关键依赖的安全公告和发布记录，尤其是认证、权限、数据导出、管理后台相关组件。
• 给高危补丁单独开快速通道，不要全部等季度窗口。
• 做纵深防御，不把单个开源组件当成可信边界。
• 日志和可观测性要有人看，至少能发现异常访问、权限绕过、批量导出这类信号。
• 凭据和权限按最小权限给，避免一个小漏洞串成大事故。

采购和架构决策也会受影响。安全团队可能会延后引入维护不活跃的组件，或者要求供应商说明 OSS 依赖清单、升级承诺和漏洞响应时限。开发团队也会更倾向把代码代理扫描接进 CI，而不是等外部报告先进安全邮箱。

接下来最该看两件事。

一是开发安全工具会不会把代码代理扫描变成默认动作。比如在 CI 里自动读代码、找路径、生成可复现报告。若这一步成熟，维护者收到的报告会继续增加。

二是漏洞披露生态能不能控制噪音。如果批量扫描服务只追求提交量，安全邮箱会重新被淹没。真正有价值的不是“发现疑似问题”，而是给出清楚复现、影响范围和修补线索。

回到 Metabase 这个例子，关键变化不是开源突然不安全。关键是公开源码被机器反复阅读后，安全成本从“事后偶发响应”提前到了“持续被发现、持续被修补”。

对成熟团队，这是流程问题。对志愿维护者，这是体力问题。对使用 OSS 的公司，这是迟早要还的工程债。