# AI 安全数据源与处理基线

[English](01-Data-Sources-and-Processing.en.md) | 中文

本文固定 SecFusionAgent 在需求阶段的数据源分类、来源权威、本地持久化、索引、更新、检索与跨源关联策略，并记录当前已经完成的风险分类导向数据源补充。M1 情报监测、M2 证据留存与规范化、M3 情报富化共享这套基线。数据库产品、消息系统、向量检索实现、调度器、抓取框架和 Agent orchestration 由 Technical Design 决定。

赛题给出的 AI 安全风险参考分为四类：AI 基础设施 / 推理框架、模型与数据层、AI 应用与智能体、供应链。四类在需求层保持并列。本文固定通用数据处理策略和 AI 基础设施监测对象；模型/数据与 Agent/Application 专项语义见 [04-AI-Model-Data-and-Agent-Application-Security](04-AI-Model-Data-and-Agent-Application-Security)，供应链 relation 与复用边界见 [02-CTI-Baseline-Reuse-and-Ownership](02-CTI-Baseline-Reuse-and-Ownership)。

## 通用数据源

赛题要求持续监测 CVE/NVD、安全社区、厂商公告、安全博客，并同步采集 AI 安全论文、技术标准与政策法规；富化阶段继续关联论文、受影响互联网资产、PoC、CVSS 与影响评估。不同来源持有的事实和更新机制不同，系统按来源能力分配本地责任。


### 产品数据源 taxonomy 与处理路径是两个轴

当前产品 source taxonomy 固定为八类，并与 Website / source inventory 使用同一顺序：

1. `vulnerability`：漏洞数据库；
2. `development`：代码与开发平台；
3. `academic`：学术研究；
4. `vendor`：厂商技术材料与项目公告；
5. `independent`：独立安全研究与安全社区；
6. `normative`：法规、标准与治理框架；
7. `assets`：互联网资产情报；
8. `incidents`：事件与新闻信号。

八类描述产品需要覆盖的外部信息空间和 fact ownership，是 source inventory 的 coverage taxonomy，不等同于 `SourceDefinition.source_class` 的 runtime 细分类，也不要求 provider/source_id 一一互斥。一个 provider 可以产生多个 source stream；同一可执行 source stream 在确实承担多类信息职责时也可以支撑多个 coverage category。分类判断使用四项：**事实归属、变化频率、重取成本、本地长期价值**。例如 GitHub Global Advisory 支撑漏洞更新，而 target repo / PR / commit / release 支撑开发关系；Unit 42 一类独立研究源既可承担 `independent` research coverage，也可为 `incidents` 提供 forensic material。

source taxonomy 与 processing path 正交。M1–M3 的外部数据进入四条主处理路径：Bug Stream、Structured Development Index、Insight Corpus、Incident Watch；互联网资产走 M3 on-demand side path。processing path 决定发现、版本、retention、promotion 和 rebuild 机制，不改变 source authority。多个 source stream 共享处理机制时，source role、upstream source、authority、evidence maturity、applicability 与 provenance 仍逐条保留。

`access mode` 还是第三个独立属性，只描述 API/Git/RSS/Web/search/query 等“怎样拿到外部数据”。它不定义 source taxonomy，也不等同 processing path。Incident Watch 可以通过 RSS、Web、API 或 telemetry 接入；GitHub 的不同 source stream 可以共享 API access，却进入不同 processing path。

因此 `assets` 同时满足两个描述：它是正式的第七类产品数据源；它的处理路径是 `time_bounded` 的 M3 on-demand side path。赛题要求覆盖 `≥7` 类来源，产品实际冻结八类。

| Product category | 典型来源 / 对象 | 外部持有的主要事实 | SecFusionAgent 的责任 |
|---|---|---|---|
| `vulnerability` | CVE `cvelistV5`、NVD、OSV、CISA KEV、CNNVD/CNVD | 漏洞身份、评分、弱点、受影响 package/version、已利用状态 | 维护 provider identity、被消费的证据版本与 canonical/source-specific enrichment |
| `development` | GitHub advisory、repo、issue、PR、commit、release、package registry | repo、版本、变更、advisory、开发历史、发布 | 建立稳定对象与开发关系，追踪新增、修改与 fix boundary |
| `academic` | arXiv、Crossref、OpenAlex、OpenReview、Semantic Scholar、正式 proceedings | paper identity、版本、发表状态、实验与评测 | 低成本 discovery + publication resolution；实际消费版本进入 durable evidence |
| `vendor` | frontier lab / vendor research、PSIRT、security bulletin、system/model card | 厂商观察、产品/模型版本、安全评测、patch/workaround | 保留 first-party authority 与版本，抽取证据支持的 claim/control |
| `independent` | Trail of Bits、Wiz、Unit 42、Talos、CERT/CC、oss-security、OWASP、MITRE ATLAS 等 | 独立复现、telemetry、漏洞研究、分类体系与跨厂商观察 | 保留独立来源链路，用于 corroboration、conflict 与新 relation/Insight |
| `normative` | 国家网信办、国家标准平台、TC260、NIST、ISO、EUR-Lex 等 | 法规、标准、requirement、control、适用条件与状态 | 保存官方版本，抽取 requirement/control 并维护 jurisdiction/binding/version |
| `assets` | Censys、Shodan、FOFA、ZoomEye | 公网 host/service、端口、banner、证书、软件指纹与观测时间 | 以 query-bound `AssetObservation` 支撑受影响资产判断，保留 query 与 observed_at |
| `incidents` | breaking news、telemetry、primary/forensic/authority source | 现实事件信号、时间线、直接证据、处置与后续变化 | 建立 Signal→Candidate→durable Incident 生命周期，保留 source independence 与 material update |

同一事件可以同时出现在多类来源。CVE 提供统一漏洞身份；NVD 在 CVE 基础上补充 CVSS、CWE、CPE 等信息；OSV 更接近 package/version/commit；CISA KEV 提供已知现实利用状态。GHSA、repo issue、PR 与 fix commit 补充受影响版本、真实修改边界和项目上下文。Vendor PSIRT 对自身产品版本与 patch 的判断通常具有更直接的权威；论文与研究博客覆盖 prompt injection、memory poisoning、RAG poisoning、Agent tool misuse 等不一定进入 CVE 的风险。

来源事实保留来源链路。后出现的评分、分析或修复信息形成新的观测，不覆盖首次披露和历史证据。

## Source definition 与 runtime state

M1 把来源的静态能力定义与运行状态分开。source registry 持有“这个 source stream 是什么、怎样访问、怎样解释来源与时间”；cursor、next-due、failure/backoff 和 AcquisitionRun 属于 monitoring runtime state。

| Definition 字段 | 语义 |
|---|---|
| `source_id` / `adapter_type` | 稳定来源身份与 provider adapter 类型 |
| `source_class` | runtime 细分类；不等同于八类 product coverage taxonomy |
| `source_role` / `source_family` / `upstream_source` | primary/signal/forensic/authority 等作用、来源族与转载依赖 |
| `access_mode` | API、Git、RSS/feed、Web、search/query 等访问方式 |
| update / identity / time semantics | 如何发现变化、如何识别外部对象、如何解释 published/updated/observed/fetched time |
| auth / rate limit / access rights | 凭据、限流与内容访问许可 |
| `retention_mode` | 选择 `hot_window / selective_index / durable_managed / incident_signal / time_bounded` processing path |
| `schedule_policy` | 是否进入周期调度及其 cadence；可 query 不等于必须 schedule |

运行状态单独保存 cursor、last attempt/success/change、`next_due_at`、failure/backoff/rate-limit state 和 durable `AcquisitionRun`。因此 live reachability、调度失败和 source taxonomy 不会混成同一个字段；禁用 scheduler 也不会取消 source 的 query capability。

调度频率依据 update semantics 单独配置。成熟数据库优先使用 delta、API 或 Git 增量；GitHub 按 repo/advisory/release/issue/PR/commit 的变化同步；博客、厂商公告和社区使用 RSS、API、页面更新时间或条件请求；论文平台按发布日期和索引增量更新。统一固定轮询周期无法表达这些来源的更新语义。

## Processing path 与 access strategy

`access_mode` 描述如何取得外部数据；`retention_mode` 决定取得后进入哪条生命周期。最终 M1–M3 固定五种 processing path：

### Hot Bug / `hot_window`

CVE/NVD 等高频 current vulnerability feed/query 进入可驱逐 working set。外部 canonical source 继续持有完整历史；被调查、引用、评测或形成长期 relation 的记录显式 promotion 到 durable Evidence/Knowledge。

### Structured Development Index / `selective_index`

GitHub repo、issue、PR、commit、release 等稳定对象持续同步结构化身份与关系，正文/附件按需要固定。该路径承担 repo graph、fix boundary 和 release containment 等确定性关系。

### Insight Corpus / `durable_managed`

厂商报告、博客、邮件列表、论文、规范文档和 forensic report 保存可复核原文/快照、元信息、content hash、解析结果与索引状态。正文语义变化产生新 revision；派生 chunk/embedding/semantic output 可以从固定版本重建。

### Incident Watch / `incident_signal`

breaking/telemetry/researcher signal 先进入短生命周期 Signal/IncidentCandidate；达到 promotion 条件后形成 durable Incident。转载依赖通过 `upstream_source` 折叠，后续 material signal 追加 revision/timeline/evidence。

### On-demand Observation / `time_bounded`

Internet asset intelligence、部分高成本 provider query 按漏洞或调查需要触发。结果保存 query、provider、filter、`observed_at` 与返回对象；只有被引用、评测或形成长期关系的 observation 再显式 promotion。

同一 provider 可以产生不同 source stream 并进入不同 path；单个 `SourceDefinition.retention_mode` 只选择一个 path，需要另一种生命周期时建立另一 source stream 或通过 promotion 转换状态。

## 本地数据层

本地状态按照 authority 与可重建关系分层；数据库产品只是实现选择。

| 数据层 | 保存内容 | Authority / rebuild 语义 |
|---|---|---|
| Source Definition + runtime state | source capability、访问/时间/retention semantics；cursor、AcquisitionRun、health/backoff | M1 runtime authority；不承载安全事实 |
| Observation / Evidence Artifact | 外部来源在某 revision 实际提供的字段、页面、文档或原始 bytes | 外部证据固定层；immutable after acceptance |
| Canonical Knowledge | `Object / ExternalIdentifier / Claim / Relation` 与 Knowledge revision/change | 系统规范化事实与关系；每条 accepted assertion 回链 Evidence |
| Specialized durable state | Managed Document、Normative Document/Requirement/Control、SecurityIncident/timeline 等 | 生命周期专用 durable state；不强塞进一个通用 object 表 |
| Current Projection | current vulnerability/fix/repo/incident 等 read model | 从 durable state 可重建，不是 evidence authority |
| Retrieval Index | full-text、dense vector、metadata/filter/index revision | 从 document/knowledge state 可重建 |
| Insight / analysis | 主题、机制、攻击链、关联解释与 evidence-backed candidate | 派生结果，引用固定证据和输入 revision |

新外部读取无论由 M1 scheduler 还是 M3/M5 follow-up 触发，都重新进入 Acquisition + M2 Evidence boundary；M3/M5 不直接把 HTTP/tool output 写成事实。模型输出也不提升来源权威。

## 证据版本管理

一条被系统消费的证据需要恢复来源、外部对象 ID、原始 URL、来源发布时间、来源更新时间、抓取时间、外部版本或等价版本信息、content hash、被使用的原始字段或快照，以及从它抽取出的 normalized facts。

外部 mutable record 每次有语义变化时产生新观测。系统通过外部版本、ETag/Last-Modified、content hash 或 provider 自带更新时间判断变化。抓取失败和“内容没有变化”分别记录，避免把 source outage 解释成没有新情报。

同一来源重复抓取保持幂等。同一外部版本不产生重复观测；页面内容改变而外部版本未变化时，以 content hash 保留新的观测版本并记录异常。

## Identity、去重与冲突

M2 使用强 identifier 和可复现 deterministic cross-reference 建立跨源稳定身份。CVE/GHSA/OSV/CNVD/CNNVD ID、repo full name、package PURL 或 ecosystem+name、commit SHA、DOI/arXiv ID 等原样保留为 `ExternalIdentifier`；不同 namespace 只有在来源明确 cross-reference 或 deterministic mapping 能证明同一对象时才自动归并。

名称/标题相似或 embedding proximity 只能形成 candidate，不能直接 merge durable object。无法确定同一性的记录保持分离，后续调查可以补证据再合并。

来源冲突保留平行 assertion。CVSS、applicability、fix status 等字段可以同时存在多个 source value；Current Projection 可以根据 authority/time 选择展示值，但不会删除或改写原 assertion。高权威来源更新后触发 projection、relation 与 derived index 重算。

## 检索与路由

查询层先判断用户或内部任务需要的对象类型，再选择数据路径。精确 ID、repo、package、version 和发布查询优先使用结构化对象与外部 query；跨对象依赖和修复传播使用 canonical Knowledge relation / structured graph state；博客、论文和长文中的机制解释使用全文与向量检索；需要最新外部状态或资产观测时触发 provider query。

一次查询可以合并多条路径。结构化结果负责确定对象和版本，文档检索补充解释与证据，canonical/structured relation 连接上下游，外部 query 刷新高时效字段。最终回答引用证据观测，retrieval index 的命中结果本身不作为事实来源。

检索索引持有 `source_id`、object/relation ID、证据版本与 index version。embedding model、chunking 或 ranking 逻辑改变时可以重建索引，并保留评测集所需的 index version。

## 数据生命周期

| 阶段 | 系统行为 | 产物 |
|---|---|---|
| discover | 发现来源新增、修改或 query target | source ref / AcquisitionRun |
| acquire | 获取外部 payload 并保留 source/object/revision identity | `IngestEnvelope` |
| evidence | 固定 Observation / Artifact / locator | M2 Evidence |
| normalize | 建立稳定 object/identifier 与 source-specific projection | canonical/specialized state |
| link / enrich | 建立 evidence-backed claim/relation、applicability、fix、PoC、asset 等 | versioned Knowledge / specialized relation |
| project / index | 构建 Current Projection、full-text/dense index | rebuildable read/index state |
| analyze | 形成 evidence-backed Insight/cluster/机制解释 | derived analysis |
| serve | 向 M4/M5/M6 暴露可追溯 current state、conflict、unknown 和 evidence | investigation / decision input |

任何派生层更新失败时，证据与 normalized object 保持可用；索引和洞察可以从上游状态重建。该约束防止检索实现反向成为知识的 source of truth。

## 风险分类导向的数据源补充

通用数据源解决“从哪里持续发现和获取材料”。四类 AI 安全风险定义各自的 anchor object、专项 relation、风险分类体系与评测集入口；各类共享 source registry、证据、object/relation 和 retrieval kernel。

### AI 基础设施 / 推理框架

AI 基础设施风险目前具有最清晰的结构化对象体系：公开 repo、发布、advisory、issue、PR、commit、package、container 与 integration 可以围绕 repo 建立稳定 graph。本篇固定该类第一批监测对象和漏洞功能层。

以下数据为 `2026-09-24` 的调研快照。Stars 反映社区规模，repo-native advisory 表示仓库自身公开的 GitHub Security Advisory 数量；该数字不代表完整漏洞数量，NVIDIA PSIRT、GitHub Advisory Database、CVE 和公开 security issue 仍需要共同查询。

| Repo | Stars | 功能位置 | repo-native advisory | 当前重点风险面 | 监测集合 |
|---|---:|---|---:|---|---|
| `vllm-project/vllm` | 92.6k | LLM inference engine / server | 83 | 资源耗尽、输入校验、反序列化、SSRF、cache、multimodal、distributed serving | Core |
| `sgl-project/sglang` | 36.4k | LLM/VLM serving framework | 0 | API/control plane、pickle/RCE、auth、cache、PD/KV、profiling | Core |
| `ggml-org/llama.cpp` | 129.4k | native inference runtime / GGUF | 13 | parser、memory corruption、GGUF、RPC、model loading | Core |
| `ollama/ollama` | 181.6k | local model runtime / serving | 0 | model pull/create、SSRF、model 产物、API exposure | Core |
| `BerriAI/litellm` | 59.5k | LLM gateway / proxy | 14 | auth、SSRF、credential、MCP、SQLi、sandbox、command execution | Core |
| `huggingface/transformers` | 166.6k | model loader / runtime interface | 0 | malicious model/config、remote code、检查点、path | Core |
| `triton-inference-server/server` | 11.0k | production model server | 0 | backend/plugin、model repository、network API、native runtime | Core |
| `NVIDIA/TensorRT-LLM` | 14.7k | NVIDIA optimized LLM runtime | 0 | native/runtime、container、dependency、distributed serving | Core |
| `ray-project/ray` | 43.9k | distributed runtime / Ray Serve | 4 | deserialization RCE、dashboard/auth、distributed control plane | Extended |
| `bentoml/BentoML` | 8.9k | packaging / serving / deployment | 11 | build 流水线、Dockerfile、archive、path、deserialization | Extended |
| `LMCache/LMCache` | 11.9k | KV cache layer | 0 | cache integrity/isolation、hash、connector | Extended |
| `kvcache-ai/Mooncake` | 6.7k | distributed KV / transfer engine | 0 | network transport、KV state、RDMA/disaggregation、dependency | Extended |
| `ai-dynamo/dynamo` | 8.2k | datacenter distributed inference | 0 | routing、distributed execution、multimodal、control plane | Extended |
| `kserve/kserve` | 6.0k | Kubernetes inference control plane | 0 | RBAC、准入、routing、deployment config | Extended |
| `safetensors/safetensors` | 3.9k | model 产物 format | 0 | parser / format 边界 | Extended |

Hugging Face TGI 保留历史漏洞和上下游关系；其 repo 已进入 archive 状态，不进入当前 Core 监测集合。

#### 功能层

| 层 | 对象 | 主要边界 | 典型风险 |
|---|---|---|---|
| L0 model 产物 / loading | Transformers、safetensors、GGUF、tokenizer、检查点、LoRA | 不可信模型制品进入 runtime | unsafe deserialization、remote code、path、恶意 config/model |
| L1 native runtime / parser | llama.cpp、TensorRT-LLM、CUDA kernel、custom op | 文件/张量进入 native memory 与计算 | OOB、heap overflow、integer overflow、RPC memory corruption |
| L2 inference / serving | vLLM、SGLang、Ollama、Triton | 网络请求进入调度器、loader、backend | resource exhaustion、SSRF、parser、debug/admin endpoint、multimodal、LoRA |
| L3 distributed serving / KV | Ray、LMCache、Mooncake、Dynamo、PD/KV connector | cache 与状态跨进程、节点和网络传输 | cache poisoning、cross-request isolation、timing side channel、unsafe serialization、transport integrity |
| L4 gateway / routing / auth | LiteLLM 与 inference gateway | 用户、provider、credential、tool/MCP 之间的控制面 | auth bypass、privilege escalation、SSRF、credential exposure、SQLi/SSTI、sandbox escape |
| L5 build / packaging / deployment | BentoML、KServe 及相关 build/deploy component | source/config 进入可执行部署状态 | command/template injection、archive/path traversal、deserialization、RBAC/configuration |

vLLM 当前 repo-native advisories 中，资源消耗、无限制资源分配、输入校验、不可信反序列化和 SSRF 占主要位置，风险集中在 request、media/model loader、调度器、cache、backend 与 native runtime 的转换边界。llama.cpp 公开记录集中在 heap/OOB、整数溢出和 RPC memory safety。LiteLLM 暴露 auth、SSRF、credential、SQLi、SSTI、MCP 与 sandbox 问题；BentoML 集中在 build、Dockerfile、archive/path 与 deserialization。

这组分布支持后续把 glue/control plane 接缝作为重点观察对象：OpenAI-compatible API 与 request parsing、model/media loader、serializer/deserializer、调度器/cache、optional backend、distributed connector、native runtime 之间的转换，以及 config/archive 到 build/runtime 的转换。该观察描述公开漏洞的聚集位置，不将开发方式写成漏洞因果。

SGLang 的 profiling、server information、LoRA loading、weight update、debug/test 等高权限接口进入同类入口检查。公开材料中 `/start_profile` 存在 server crash bug，当前证据不足以单独定性为安全漏洞；同一服务周边已有反序列化 RCE、secret exposure 和上传路径问题。关联时继续检查 endpoint、认证条件、request-controlled path、serialization 与 privileged 工作进程。

#### Repo graph

AI Infra 以 repo 为 anchor 建立以下关系：

| 关系 | 对象 |
|---|---|
| vulnerability | GHSA、CVE、公开 security issue、vendor PSIRT |
| implementation | affected file/function、issue、fix PR、fix commit、sibling path、fix bypass/regression |
| 发布 | affected version、patched version、package、container digest |
| upstream | dependency、parser/runtime、model format、集成进来的 component |
| downstream | framework integration、connector、gateway、image、deployment project |

一条 CVE/GHSA 继续关联 fix PR、commit、发布和 sibling code path。相同 serializer、auth decorator、URL parser、path handling、backend 或 privileged function 的其他 caller 用于发现同类问题。发布 relation 把代码修复映射到用户实际消费的 package/container；integration relation 用于判断同一组件问题是否传播到 vLLM、SGLang、TensorRT-LLM、LMCache、Mooncake 等多个项目。

### 模型与数据层

该类覆盖 prompt injection、system prompt leakage、data poisoning、model poisoning/backdoor、model extraction、privacy leakage 等对象和攻击方式。通用来源中的论文、研究博客、模型/数据平台、标准与安全社区已经进入 source registry；专项分类体系、文献证据链、评测集与研究监测对象见 [04-AI-Model-Data-and-Agent-Application-Security](04-AI-Model-Data-and-Agent-Application-Security)。

### AI 应用与智能体

该类覆盖 Agent tool use、permission、secret、memory/state、sandbox、browser/computer use、MCP/skill、多 Agent interaction 等风险。GitHub、厂商研究、论文、红队报告和应用安全材料继续复用通用数据层；专项 trust 边界、代表案例、事件 schema、安全测试对象和 runtime security requirements 见 [04-AI-Model-Data-and-Agent-Application-Security](04-AI-Model-Data-and-Agent-Application-Security)。

### 供应链

供应链与前三类保持并列，关注 source、dependency、package、container、model/data 产物、plugin/skill、deployment 产物及其构建和分发关系。通用 object/relation 层表达 repo、commit、package、产物、dependency 和发布；当前范围覆盖 dependency、package、container image、model/data 产物、plugin/skill、build 与 deployment/distribution channel，传播 relation 与复用边界由 [02-CTI-Baseline-Reuse-and-Ownership](02-CTI-Baseline-Reuse-and-Ownership) 持有。

AI Infra repo 的 package、container 和 dependency relation 继续记录，因为它们描述该 repo 的真实发布和影响传播；供应链传播判断继续遵守 02 固定的归属。

## 受影响互联网资产

赛题把受影响互联网资产列为 M3 富化维度。这里的资产指公网可观测的 host、service、Web application 或其他暴露端点。已知漏洞先解析受影响 product/version 与可识别 fingerprint，再通过 Internet asset intelligence 查找候选实例；结果记录观测时间、IP/domain、port、service、software/version、ASN/organization、region 与匹配依据。

资产测绘结果属于时间相关观测。banner 缺失、版本隐藏、服务升级和 fingerprint 误判会降低确定性，因此 candidate affected asset 与经额外证据确认的 affected asset 分开记录。具体平台、查询语法、地域范围和验证方法进入后续调研与探针。

## 需求阶段固定项

本报告固定以下 contract：产品 source coverage 使用八类 taxonomy；runtime `source_class`、access mode 与 processing path 独立；每个 `SourceDefinition` 选择单一 `retention_mode`，processing path 固定为 `hot_window / selective_index / durable_managed / incident_signal / time_bounded`；Source Definition 与 monitoring runtime state 分离；任何外部读取进入 Acquisition + Evidence boundary；Evidence、Canonical Knowledge、specialized durable state、Current Projection 与 Retrieval Index 分层；索引/投影可重建，跨源冲突和历史 assertion 保留；后续查询与调查只消费可追溯 state/evidence。

风险分类导向的数据源补充保持四类并列。AI 基础设施 / 推理框架的 Core/Extended repo、L0-L5 功能层与 repo graph 已固定；模型/数据与 Agent/Application 的分类体系、监测对象和证据 strategy 已由 04 固定；供应链对象和传播关系由 02 固定。M3 的受影响互联网资产已经固定基本对象、provider 类型和证据语义，具体 query、fingerprint 与验证策略进入 Technical Design / Probe。