Filippo Valsorda 在 6 月 23 日发文，抛出一个不太顺耳的判断：漏洞报告可能不再天然“特殊”。
这句话容易被误读。它不是说开源项目应该关闭 security@ 邮箱，也不是说协调披露没用了。Valsorda 曾是 Go Security team 负责人，目前仍参与 Go 项目维护，但这篇文章不代表 Go Security team 或 Go 项目的官方政策。
他的重点是成本变了。
过去，外部研究者带来的价值很稀缺：发现一个真实漏洞，愿意私下告诉维护者，并给项目留出修复窗口。现在，LLM 能批量扫代码、生成潜在漏洞线索。维护者、研究者、攻击者都能用。
于是问题从“谁发现了漏洞”，变成“谁有时间判断它到底是不是漏洞”。
旧规则为什么曾经成立
传统开源安全流程里，漏洞报告通常比普通 issue 优先级更高。维护者要快速回应，私下确认，协调修复时间，发布公告，并在修复后给研究者署名。
这套规则不是凭空来的。
早年安全研究者披露问题，可能面临法律风险，也可能被项目方视为“找麻烦”。协调披露给了双方一条相对安全的路：研究者负责任地报告，维护者获得修复窗口，用户少一点暴露风险。
它大致建立在四个前提上：
| 旧流程 | 当时解决的问题 | 对维护者的要求 |
|---|---|---|
| 保密披露 | 避免漏洞在修复前扩散 | 私下沟通、控制信息范围 |
| 协调修复 | 给项目留出补丁时间 | 判断影响、安排发布时间 |
| 及时响应 | 鼓励研究者继续负责任报告 | 尽快确认、避免冷处理 |
| 署名致谢 | 承认研究者贡献 | 在公告或 changelog 中说明来源 |
这套安排的底层逻辑是：高质量漏洞线索少，值得特殊对待。
Valsorda 挑战的不是这段历史价值，而是这个前提。LLM 出现后，“潜在线索”不再那么稀缺。稀缺的是能把线索变成结论的人。
也就是 triage：分诊。
新变量：发现变便宜，验证变昂贵
LLM 不是漏洞裁判。它能扩大搜索面，也会扩大误报面。
一个模型提示“这里可能有注入风险”，不等于这里有可利用漏洞。维护者还要看代码路径、输入来源、权限边界、版本影响和复现条件。很多时候，最耗人的正是这一步。
这也是 Valsorda 文章里最关键的转折：外部报告和维护者自己跑模型得到的结果，可能都要消耗同一批人的注意力。
| 变化前 | 变化后 | 新压力点 |
|---|---|---|
| 漏洞发现相对稀缺 | 潜在线索可批量生成 | 报告数量增加 |
| 保密窗口价值高 | 攻击者也能用 LLM 找线索 | 披露窗口的相对价值下降 |
| 人工处理少量高价值输入 | 人工面对大量不稳定输入 | 分诊成为瓶颈 |
| 重点是接收外部报告 | 重点是验证、修复、预防 | 安全流程要改造 |
这不等于“漏洞报告没价值”。
更准确的说法是：报告的默认优先级不能只看它是不是走了安全邮箱。它还要看证据质量、可复现性、影响范围和修复紧迫性。
对小型开源项目来说，这一点尤其现实。最贵的不是收件箱，而是那个能看懂报告、能跑复现、能决定是否发安全公告的人。
curl 的动作提供了一个横向参照。Valsorda 在脚注中提到，几天前他还认为 curl 暂停一个月漏洞报告渠道的做法“太过”。curl 维护者 Daniel Stenberg 在 2026 年 6 月 15 日宣布相关安排，背景正是维护压力和漏洞报告处理成本。
这至少说明，争议已经落到维护现场。安全响应流程本身，也可能被低质量报告、自动化扫描和 AI 生成内容拖垮。
限制也要说清楚。
如果一个项目把外部报告降级处理，却没有更强的测试、fuzzing、静态分析、依赖审计和补丁发布能力，那不是安全升级，只是把风险从邮箱挪回代码库。
维护者该把资源投到哪里
这件事最直接影响两类人：开源项目维护者，以及安全团队和漏洞响应负责人。
对开源维护者来说，接下来要重新设计入口，而不是简单拒收报告。安全报告可以继续存在，但要提高格式和证据门槛：受影响版本、复现步骤、最小 PoC、攻击前提、预期影响，都应尽量写清楚。
这会改变维护者的日常动作：
- 把安全报告模板做细，减少“模型猜测式”报告；
- 给高风险组件设置快速修复通道，而不是所有报告同等加急；
- 在 CI 中加入 LLM 辅助分析，但要和静态分析、测试覆盖率、fuzzing 结果交叉验证；
- 把 CVE、公告和补丁发布流程拆清楚，避免分诊阶段拖成长期债务。
对企业安全团队和漏洞响应负责人来说，影响更具体。
如果企业依赖某个开源组件，不能只看项目有没有安全邮箱、有没有 CVE。更该看项目是否有清晰的响应规则、补丁速度、测试体系和维护活跃度。采购或引入关键依赖时，安全评估可能要从“能不能报漏洞”，转向“报了以后谁处理、多久修、怎么验证”。
这会带来一个现实动作：高风险依赖的引入可能延后，直到团队确认上游维护质量和内部兜底方案。已有依赖也要做分层管理，核心链路组件不能只等上游公告。
接下来更该看三件事。
| 观察点 | 为什么重要 | 判断条件 |
|---|---|---|
| 主流开源项目是否调整安全报告 SLA | 这会改变研究者和维护者的互动规则 | 是否区分高证据报告和低质量线索 |
| GitHub、GitLab 等平台是否加强 AI 分诊 | 维护者缺的不是更多入口，而是过滤能力 | 是否能结合代码路径、测试和历史 issue 判断 |
| CVE 和安全公告体系如何处理模型报告 | “疑似漏洞”不能等同于“可利用漏洞” | 是否要求复现证据和影响说明 |
我更在意的是第一项。平台工具可以帮忙，但项目自己的响应规则更关键。没有规则，AI 只会把噪声送得更快。
回到开头那句话：漏洞报告不再天然特殊，并不是安全不重要了。
它真正指向的是一条新规则：发现变便宜以后，分诊、修复和预防才是安全工作的硬成本。守城不能只靠报信的人越来越多，还要有人能辨真伪、补城墙。