增加 CVE/GHSA RAG 知识库以支持 Variant Analysis

[Kherrisan]

背景

当前 Scan 主要依据目标仓库代码和 Agent 自身知识进行漏洞挖掘，无法系统利用已有 CVE、GHSA 和公开漏洞模式。对于历史漏洞的变体、相同根因在其他模块中的复制实现、修复不完整或绕过场景，缺少统一的知识检索能力。

需要增加独立的 RAG 组件，保存和索引已有 CVE/GHSA advisory，并向 Scan 提供可追溯、受 token budget 限制的检索结果，用于 Variant Analysis。

本 issue 与 #4 的扫描流水线优化相关，但 RAG 应作为可复用的知识服务实现，不与某个具体 stage 强耦合。

目标

• 保存 CVE、GHSA 及其原始 advisory 数据
• 归一化同一漏洞的 CVE/GHSA alias，避免重复入库
• 支持定期增量同步、手工导入和数据版本更新
• 为 Scan 提供关键词、结构化条件和语义向量的混合检索
• 根据项目语言、依赖、模块、CWE、source/sink、根因和代码特征召回相关历史漏洞
• 将检索结果用于 Variant Analysis，并保留 advisory 来源和引用
• RAG 不直接把“相似”判断为真实漏洞，最终结论仍需代码证据、analysis 和 verification

建议数据模型

Advisory 主记录

vulnerability_advisories
- advisoryId
- canonicalId              // 优先 CVE，否则 GHSA
- source                    // cve | ghsa | manual
- title
- summary
- details
- publishedAt
- modifiedAt
- withdrawnAt
- severity/CVSS
- CWE
- rawDocument
- contentHash
- sourceVersion
- createdAt/updatedAt

Alias 与受影响范围

advisory_aliases
- advisoryId
- aliasType                 // cve | ghsa
- alias

advisory_affected_packages
- advisoryId
- ecosystem
- packageName
- vulnerableRange
- patchedVersion

可检索内容

advisory_chunks
- chunkId
- advisoryId
- chunkType                 // summary | root_cause | affected_code | fix | references
- content
- embedding
- metadata
- embeddingModel
- contentHash

参考链接、补丁/commit、受影响文件/符号和利用条件应结构化保存，不要只塞入一个大 JSON。原始 source document 保留用于重新解析和审计。

数据导入与同步

• 支持从官方 CVE/GHSA 数据源按更新时间游标增量同步
• 支持管理员导入 JSON/JSONL advisory 数据集
• 以 source ID、alias 和 content hash 保证幂等
• 同一 GHSA 含 CVE alias 时合并为一个 canonical advisory
• advisory 更新后只重新生成发生变化的 chunk/embedding
• 保存同步任务状态、游标、成功/失败数量和错误原因
• 下载失败可重试，但不能删除上一版本的有效索引

检索接口

提供独立服务接口，例如：

retrieveVulnerabilityKnowledge({
  query,
  languages,
  ecosystems,
  packages,
  cwes,
  filePaths,
  symbols,
  vulnerabilityClasses,
  limit,
  tokenBudget,
})

采用混合检索：

1. alias/package/CWE/路径/符号等结构化过滤
2. PostgreSQL 全文或关键词召回
3. embedding 相似度召回
4. 综合相关性、数据新鲜度和证据完整度重排
5. 对同一 canonical advisory 去重后返回

每条结果必须携带 advisory ID、来源、相关 chunk、score、受影响范围和引用 URL。检索结果数量和最终注入 prompt 的字符/token 数量必须有硬上限。

Scan / Variant Analysis 接入

• 在 repository profile/attack surface 信息可用后，根据语言、依赖、模块和漏洞类别检索 advisory
• Variant Analysis 只接收与当前扫描上下文相关的 advisory chunk，不加载完整知识库
• Prompt 明确区分“外部 advisory 声明”和“目标仓库代码证据”
• Agent 需要回答：历史漏洞的根因、当前仓库是否存在同构实现、关键差异、触发路径和修复绕过可能性
• 发现的 variant 继续生成正常 Candidate，进入现有 analysis、verification、triage 和去重流程
• Candidate 保存关联的 advisory ID/chunk ID、检索分数和引用，保证结果可追溯
• 没有相关 advisory 时正常继续扫描，不把 RAG 设为 pipeline 必需条件

管理与可观测性

• 管理页面展示 advisory 数量、alias 数量、chunk 数量、最近同步时间和失败状态
• 支持按 CVE/GHSA/package/CWE 搜索和查看原始来源
• 支持手工触发增量同步、重新解析和重新生成 embedding
• 记录每个 Scan 的检索 query、命中 advisory、耗时和注入 token 数
• 统计 RAG Candidate 的验证通过率，评估召回质量和噪声

安全与可靠性

• Advisory 文本视为不可信外部输入，注入 prompt 时使用固定边界，禁止其中的指令覆盖系统/stage prompt
• 外部 URL 不由 Agent 自动执行；补丁和仓库引用需要经过现有网络与权限策略
• 数据源 token 使用服务端 secret，不写入 advisory 或 task output
• embedding 模型/维度变更时保留版本，支持后台重建索引
• 同步和检索失败不能阻塞不依赖 RAG 的现有 Scan

验收标准

• 能幂等导入并更新 CVE/GHSA advisory
• CVE 与对应 GHSA 被归并为一个 canonical advisory，并保留全部 alias
• 支持结构化、全文和向量混合检索
• 检索结果包含来源、引用、相关性和稳定 ID
• Scan 能基于检索结果执行 Variant Analysis 并生成可追溯 Candidate
• Candidate 能查询到触发它的 advisory/chunk
• Prompt 注入有明确 token budget，且外部 advisory 无法改变 stage 指令
• 无命中、同步失败或向量服务不可用时，普通 Scan 仍可继续
• 覆盖重复导入、advisory 更新、alias 合并、检索去重、token 截断和 prompt injection 测试