一条 AI 垃圾 CVE 可以具备完整外观：编号、受影响版本、技术描述、PoC 和严重度评分。这些字段都无法单独证明漏洞存在。Security Agent 修改代码或升级生产依赖前，需要一份复现合同，把漏洞声明绑定到真实源码、可达路径、隔离环境里的确定性失败，以及可验证的上游修复。
SQLite 事件暴露的是流水线问题
2026 年 7 月 30 日，JFrog 发布了六条 SQLite CVE 的逐项审计。这些记录已经进入公开漏洞数据链，并一度带有 High 或 Critical 元数据。JFrog 随后核对目标版本、函数、行号、补丁和 PoC，发现声明经不起源码检查。
问题非常具体：有的函数在所称版本中根本不存在，有的所谓修复版本没有修改相关源文件，有的引用行号超过文件总长度，有的 PoC 在解析阶段就失败，还有一条使用了源码里不存在的函数签名。
JFrog 检出指定 SQLite tag，在 Docker 中干净构建，并在 AddressSanitizer 下原样运行 PoC，同时核对 NVD、CPE 和 GHSA 元数据。SQLite 官方 CVE 页面随后把这六条记录列为并非 SQLite bug，说明它们不可复现，疑似 AI 幻觉。
JFrog 还审计了同一 GitHub 账号更广泛的 55 条通告，分类结果是 54 条完全捏造，另 1 条包含真实 bug，但套用了未经验证的 CVE 元数据。54 比 1 是 JFrog 的研究结论，不是 CVE Program 的官方分类。
状态在文章发布后继续变化。7 月 31 日，官方 CVE API 已把这 55 个 ID 全部标为 REJECTED。拒绝状态也不代表底层每个普通软件 bug 都不存在。它表示这些记录已经不能支撑把所述问题当作有效 CVE 处理。
CVE 记录包含多个证据层级
安全自动化最常见的错误，是把数据库里存在一行记录当成漏洞已经验证。
| 证据层级 | 能证明什么 | 仍不能证明什么 |
|---|---|---|
| CVE ID 已分配 | CNA 创建了记录编号 | 已完成独立复现 |
| 记录已发布 | 必填字段与公开引用进入系统 | 厂商确认或真实可利用性 |
| NVD 或 ADP 富化 | 增加 CPE、CWE、CVSS 等元数据 | PoC 能到达漏洞代码 |
| 维护者确认 | 上游项目认可问题 | 当前部署配置暴露 |
| 隔离复现 | 指定版本在记录条件下失败 | 提议补丁正确 |
| 修复验证 | 同一复现由失败变为安全 | 保护版本已覆盖生产资产 |
六条 SQLite 记录说明了为什么这些层级必须分开。严重度元数据早于源码和 PoC 核验出现。扫描器因此可能自动创建紧急工单，修复 Agent 甚至会尝试修改一个不存在的函数。
CVE CNA 规则要求 CNA 做漏洞判定并提供公开引用，但发布记录不等于独立复现。可工作的 PoC 是强证据，却不是所有 CVE 的统一发布前提。
六道复现门
原始漏洞 Feed 应先进入隔离区。只有每一道门都有明确证据，记录才可以晋升到自动修复。
第一门：来源与当前状态
记录分配 CNA、发布时间线、引用和最新状态，并在执行前刷新。状态变为 REJECTED、DISPUTED 或内容发生实质修改时，旧修复计划立即失效。
维护者官网没有记录只能算红旗，不能单独作为伪造证明。来源陌生、版本范围冲突、产品字段缺失和严重度频繁变化，都应提高审核等级。
第二门：源码身份
冻结上游仓库、tag 或 commit、构建配置、文件、函数和声明行号，确认所有符号在该版本真实存在。
这一门无需运行 PoC，就能挡住多条 SQLite 通告。比目标版本晚几年才引入的函数，不可能支撑所述调用路径。超过文件末尾的行号，也不只是普通引用误差。
第三门：可达性与威胁模型
普通 bug 只有在相关攻击能力和部署条件成立时，才构成安全漏洞。需要确认不可信输入能到达目标位置、相关功能确实启用，以及所述影响给攻击者带来了原本没有的能力。
SQLite 官方漏洞说明长期强调这一点。许多 SQLite 崩溃报告默认攻击者已经能执行任意 SQL 或提交恶意数据库，而普通应用通常没有这个暴露面。前置能力不同，安全影响也会变化。
第四门：隔离复现
从干净源码构建精确版本，在受限环境中启用 Sanitizer 和日志，先原样运行 PoC，再考虑修复。至少保留：
- 源码与构建哈希；
- 编译器、参数、依赖和平台；
- PoC 哈希与执行命令；
- 退出码、stdout、stderr、Sanitizer 输出和堆栈；
- 重复结果与一个负向对照。
PoC 缺失或失败不一定证明漏洞为假，环境假设可能没有写全。它至少说明证据还不足以触发自动改代码。系统应把记录转入人工调查，并明确缺少什么。
第五门：补丁真实性与因果性
核验修复 commit 或 PR 真实存在，修改了所称路径，并进入声明的修复版本。通告里的一句 fixed in 某版本不足以证明补丁存在。
最强回归具有两面：冻结的旧版本在复现器下失败，新版本在同一测试下通过。还要增加边界输入，避免补丁只过滤现有 PoC，同时检查无关功能和安全不变量。
第六门：执行策略与部署证据
只有证据合同完整、变更可逆、补丁来源可信、灰度范围可控时，才允许自动修复。其余情况进入隔离、补证据或人工批准之一。
部署后继续核对运行版本、重新扫描资产，在安全条件下重复负向测试，并监控回滚阈值。生成补丁只是提议，受保护版本覆盖目标资产才算完成。
把复现门写成机器合同
一条短小结构化记录，比一段 Agent 自述更适合执行器检查。
vulnerability_gate:
cve: CVE-YYYY-NNNNN
state: PUBLISHED
checked_at: 2026-08-04T08:00:00Z
source:
repository: https://example.org/upstream/repo
commit: 4d3c2b1
function_present: true
exposure:
feature_enabled: true
untrusted_input_reachable: true
reproduction:
environment_sha256: a921...
poc_sha256: 88c4...
attempts: 3
sanitizer_failure: true
fix:
upstream_commit: 771e...
vulnerable_fails: true
fixed_passes: true
decision: allow_canary
执行器应拒绝缺失、过期或互相矛盾的字段，并把批准绑定到具体软件包、版本、目标资产和补丁哈希。所有被拒候选都可以沉淀为 Eval 数据，让同类垃圾通告下一次更早被拦截。
这套准入门与Chrome 的 AI 漏洞流水线属于两个相邻控制面。旧文衡量漏洞从发现到用户真正获得保护的全过程。本文的复现合同决定一条外部声明是否有资格进入这条流水线。
避免 AI 检测器捷径
JFrog 使用 GPTZero 作为通告文本可能由 AI 生成的一条信号。这个信号不能支撑漏洞拒绝。文本检测器可能误判人工或机器文本，人工写作也完全可能包含技术错误。
真正的问题是：所称代码是否存在、路径是否可达、输入能否复现失败、影响是否符合威胁模型、修复是否改变结果。这些检查与作者身份无关。
常见问题
什么是 AI 垃圾 CVE？
它是对低质量或伪造漏洞通告的非正式称呼，其技术细节可能由 LLM 生成或放大。这个标签只能描述质量风险，不能代替技术核验。
有 CVE 编号是否代表已经独立复现？
编号表示 CNA 按 CVE 流程分配并发布了记录。独立复现、厂商确认、环境暴露与补丁验证属于额外证据。
六条 SQLite CVE 是真的吗？
JFrog 无法复现，并在源码、PoC 与所谓补丁中发现直接矛盾。SQLite 官方把它们列为并非 SQLite bug，相关 CVE 记录随后被拒绝。
PoC 失败后应该怎么做？
保存环境和输出，复核版本与配置假设，并请求缺失证据。在得到可复现结果前，保持隔离，停止自动修复。
被拒 CVE 是否仍可能指向真实 bug？
可能。记录可能因为所述问题不构成安全漏洞、重复、产品归属错误或元数据无效而被拒绝。普通 bug 是否存在与 CVE 是否有效是两个相邻问题。