安全团队建设知识库，通常不是为了“让模型读更多文档”，而是为了在有限时间内回答更接近处置的问题：某个 CVE 是否影响当前资产；一个告警是否属于已知攻击链的一部分；一台服务器上出现的进程、网络连接和账号行为能否形成足够证据；某条补丁建议是否适用于当前业务系统。普通 RAG 能把文档片段召回给大模型，但安全知识的核心往往不在单个片段里，而在实体之间的约束、依赖、继承、时间顺序和证据强度中。GraphRAG 的价值正在于把“相似内容检索”扩展为“关系化检索与可解释推理”。
普通 RAG 适合回答文档型问题，例如“某产品漏洞公告怎么说”“某检测规则字段含义是什么”。但当问题涉及 CVE、CWE、CPE、CAPEC、ATT&CK、资产清单、日志、告警、工单和事件报告之间的多跳关系时，向量相似度很容易失去结构信息。一个漏洞描述与某个资产服务名称可能语义相近，却不能证明该资产运行了受影响版本；一个 ATT&CK 技术与日志片段可能相似，也不能证明攻击链已经成立。安全场景需要把“可能相关”进一步收敛为“有证据支撑、可审计、可处置”的结论。
普通 RAG 的边界
安全知识库面对的对象高度异构。漏洞库中的 CVE 记录描述具体缺陷，CWE 描述缺陷类型，CPE 指向受影响产品与版本，CAPEC 描述攻击模式，MITRE ATT&CK 则组织战术、技术和过程。企业内部还有 CMDB、云资产、容器镜像、SBOM、EDR 日志、SIEM 告警、漏洞扫描结果、变更记录和历史事件。这些数据不是一组松散段落，而是一张持续变化的组织安全状态图。
普通 RAG 通常把资料切块、向量化、召回、重排，再交给 LLM 生成答案。这个流程有三个常见问题。第一，切块会切断关系。一段 CVE 描述可能与受影响 CPE 列表分离，资产版本信息又在另一套系统里，模型只能依据相似片段猜测。第二，召回强调语义相似，不强调事实约束。例如“远程代码执行”“身份绕过”“Apache”这样的词会召回大量相似内容，但无法自然表达“资产 A 运行产品 P 的版本 V，V 落在 CVE 的受影响区间内”。第三，答案难以审计。安全结论不能只说“看起来相关”，而要说明依据来自哪个漏洞源、哪个资产记录、哪条日志、哪条检测规则以及它们之间如何连接。
因此，普通 RAG 在安全知识库中可以作为入口，但不应成为唯一的知识组织方式。它回答“有哪些文本可能相关”较好；回答“哪些实体构成了可验证事实链”则不足。
GraphRAG 的基本思路
GraphRAG 将知识图谱与向量检索结合起来：图谱保存实体、关系、属性、时间和来源；向量索引保存描述性文本、报告段落、规则说明和处置手册的语义表示。查询时，系统先用向量检索找到候选实体或文档片段，再沿图谱进行受控遍历；也可以先根据实体约束定位子图，再用向量检索补充解释性上下文。最终交给 LLM 的不是一堆孤立文本，而是带有关系、路径和来源的证据包。
这里的关键不是把所有内容都“图谱化”。图谱应该承载安全判断中必须稳定、可连接、可审计的部分；向量索引则承载自然语言解释、长文档上下文和模糊查询能力。二者结合后，系统既能处理“Log4Shell 是否影响我的生产网关”这样的实体约束问题，也能处理“这个攻击者行为像不像某类初始访问模式”这样的语义问题。
安全图谱应该如何建模
安全知识图谱的建模应从问题反推，而不是从资料全集开始堆实体。一个可用的最小模型通常包含五类节点：标准化威胁知识、组织资产状态、观测证据、检测与控制、处置过程。
标准化威胁知识包括 CVE、CWE、CPE、CAPEC、ATT&CK Technique、Tactic、Malware、Tool、Threat Actor 等。关系包括 CVE_HAS_WEAKNESS_CWE、CVE_AFFECTS_CPE、CAPEC_EXPLOITS_CWE、TECHNIQUE_USES_TOOL、TECHNIQUE_BELONGS_TO_TACTIC。这些关系帮助系统从“漏洞”走向“可利用方式”和“攻击行为”。例如某 CVE 对应 CWE-79，并被某类 Web 攻击模式利用，再映射到应用层初始访问或执行技术。
组织资产状态包括 Asset、Service、Package、ContainerImage、CloudResource、Identity、NetworkZone、BusinessApplication。关系包括 ASSET_RUNS_SERVICE、SERVICE_USES_PACKAGE、IMAGE_CONTAINS_PACKAGE、ASSET_IN_ZONE、IDENTITY_CAN_ACCESS_ASSET、APPLICATION_DEPENDS_ON_ASSET。这部分决定“外部漏洞知识是否与本组织有关”。同一个 CVE 对互联网暴露资产、测试环境资产和离线批处理节点的风险不同，差异来自资产上下文，而不是 CVE 文本本身。
观测证据包括 LogEvent、Alert、Process、File、IP、Domain、URL、UserSession、Incident。关系包括 ALERT_OBSERVED_EVENT、EVENT_ON_ASSET、PROCESS_SPAWNED_PROCESS、SESSION_USED_IDENTITY、IP_CONNECTED_TO_ASSET、EVENT_MATCHES_TECHNIQUE、ALERT_PART_OF_INCIDENT。这部分决定“是否发生了攻击行为”以及“证据是否连续”。
检测与控制包括 Rule、SigmaRule、YaraRule、EDRPolicy、FirewallRule、Patch、Mitigation、CompensatingControl。关系包括 RULE_DETECTS_TECHNIQUE、PATCH_REMEDIATES_CVE、CONTROL_MITIGATES_TECHNIQUE、ASSET_HAS_CONTROL、ASSET_MISSING_PATCH。处置过程则记录 Case、Task、Decision、Exception、Approval 和 Postmortem，用于保留人的判断与例外。
建模时要避免两个极端。一是只保存“实体共现”，把所有提到同一个词的对象连起来，这会制造大量弱关系；二是追求一次性完备本体，导致工程不可落地。实践中更合适的是分层建模：核心事实关系严格校验，分析性关系带置信度，LLM 抽取关系必须保留原文证据和抽取版本。关系可以有属性，例如 confidence、valid_from、valid_to、source_doc、extractor、review_status。安全图谱不是静态百科，而是带来源和生命周期的证据系统。
向量检索与图遍历的协同
GraphRAG 在查询流程上通常有三种模式。
第一种是语义检索驱动。用户问“最近提到的某类边界设备漏洞是否可能被用于初始访问”，系统先向量召回漏洞公告、威胁情报和内部事件复盘，再从召回片段中识别 CVE、产品、技术和攻击模式，进入图谱查找本组织是否有匹配资产、暴露面和历史告警。这适合问题表述模糊、实体不完整的场景。
第二种是图约束驱动。用户问“列出所有影响互联网暴露 Java 服务且存在公开利用的高危 CVE”，系统先从资产、服务、CPE、暴露面和 CVE 属性构造图查询，再用向量索引补充每个漏洞的利用条件、缓解建议和厂商说明。这适合资产治理、漏洞优先级和合规报告。
第三种是混合迭代。模型先根据问题生成查询计划，执行一次向量召回和一次图遍历后，发现证据不足，再追加查询。例如初始结果显示某资产版本命中 CVE，但缺少网络可达性证据；系统继续查询网络区域、WAF 策略、近期访问日志和补丁工单，最后给出“高风险”“中风险”或“证据不足”的分层结论。
这类流程的工程重点是限制遍历范围。安全图谱很容易变成高连接图：一个 ATT&CK 技术连接大量规则，一个 IP 连接大量事件，一个共享组件连接大量资产。系统需要按时间窗口、资产范围、关系类型、置信度、租户权限和最大跳数剪枝。GraphRAG 不是让模型在整张图上自由漫游，而是让查询规划在明确边界内构造可解释子图。
证据链比答案更重要
安全场景中，答案的价值取决于证据链。一个 GraphRAG 系统回答“资产 X 受 CVE-2024-XXXX 影响”时，至少应能返回如下路径：CVE 影响 CPE；CPE 匹配资产上运行的产品与版本；该资产属于生产业务且对互联网暴露；扫描或 SBOM 数据在某时间点确认该版本存在；补丁工单未关闭或控制措施未覆盖。每一步都应有来源、时间和置信度。
同理，判断“某告警属于攻击链”也不能只看单条规则命中。合理路径可能是：外部 IP 对 Web 服务出现异常请求；随后 Web 进程创建 shell；shell 下载可疑文件；同一主机上出现凭据访问行为；凭据被用于横向访问另一台服务器；这些事件分别映射到 ATT&CK 的 Initial Access、Execution、Credential Access 和 Lateral Movement。GraphRAG 的输出应呈现路径，而不是把所有事件压缩成一句“疑似入侵”。
这里需要明确 LLM 的角色。LLM 适合进行查询改写、实体消歧、证据摘要、假设生成和处置建议编排，但不应成为事实存储本身。事实应落在图数据库、搜索索引、对象存储和审计日志里。生成答案时，系统应要求模型引用证据 ID，标注不确定性，并区分“已验证事实”“推断关系”和“建议动作”。
权限、隔离与审计
安全知识库天然包含敏感信息：资产清单、漏洞暴露面、攻击事件、账号权限、内部网络结构和处置过程。GraphRAG 的权限模型不能只停留在文档级 ACL。因为图遍历可能通过关系泄露信息：即使用户看不到某台核心资产的详情，也可能通过“某漏洞影响高价值资产”的聚合答案推断其存在。
工程上应至少考虑四层控制。第一，实体级权限。不同团队只能访问其负责资产、事件和工单。第二，关系级权限。某些关系如 IDENTITY_CAN_ACCESS_ASSET、ASSET_IN_ZONE、INCIDENT_IMPACTED_ASSET 比节点名称更敏感，需要单独控制。第三，查询级约束。遍历深度、可访问关系类型、可返回字段应随角色变化。第四，生成级审计。LLM 输入的证据包、输出答案、被过滤的字段和用户身份都应记录，以便事后复盘。
多租户或大型组织中，建议把权限前置到检索层，而不是在答案生成后再删除敏感内容。向量索引也需要同样的 ACL，否则模型可能通过召回片段绕过图数据库权限。对于跨团队事件协同，可以使用受控的“事件视图”或“证据摘要节点”，只暴露必要事实和脱敏标识。
更新机制与知识新鲜度
安全知识变化极快。CVE 评分会更新，CPE 匹配会修正，利用代码会公开，资产版本会变更，云资源会创建或销毁，检测规则会调整。GraphRAG 的更新机制必须支持增量、可追溯和可回滚。
外部知识更新可按源头建立管道：NVD、厂商公告、CISA KEV、ATT&CK、CAPEC、CWE、威胁情报源。内部状态更新则来自 CMDB、云 API、SBOM、漏洞扫描器、EDR、SIEM、工单系统。每次写入图谱时应保留来源版本与时间戳，避免“最新值覆盖历史事实”。例如某资产今天已打补丁，不代表昨天事件分析时它也已打补丁；事件推理需要时间一致性。
LLM 参与抽取时，更应采用可复核流程。模型可以从厂商公告中抽取受影响产品、前置条件、缓解措施和利用迹象，但抽取结果应带原文 span、模型版本、提示版本和校验状态。对关键关系，如“CVE 影响某产品版本范围”“补丁修复某 CVE”，最好引入规则校验或人工审核。GraphRAG 的可靠性不来自模型自信，而来自数据血缘、校验和反馈闭环。
评估：不仅评估问答，还要评估路径
评估安全 GraphRAG 系统时，不能只看回答是否流畅。至少应评估五类指标。
一是实体识别与链接准确率。CVE、CPE、产品名、版本号、主机名、云资源 ID 和 ATT&CK 技术必须能正确归一。安全文本中别名、缩写和版本表达复杂，这一步错误会传导到后续推理。
二是关系正确性。系统是否把“提到某 CVE”误判为“受影响”；是否把“检测规则覆盖某技术”误判为“事件已发生”；是否把“存在补丁”误判为“资产已修复”。关系类型的精确性比召回更多节点更重要。
三是证据路径质量。对每个结论，应检查路径是否完整、来源是否可信、时间是否一致、是否存在断点。高质量答案应该能明确指出缺失证据，例如“发现受影响版本，但没有互联网暴露证据”“检测到执行行为，但缺少初始访问事件”。
四是处置有效性。系统推荐的优先级是否帮助团队减少平均修复时间、降低误报、提升事件分流效率。离线问答准确率不能替代真实工作流指标。
五是安全与权限评估。测试用户能否通过模糊问题、聚合查询或多轮对话推断无权访问的资产与事件。GraphRAG 引入了更多连接能力，也扩大了推断攻击面。
落地建议
落地 GraphRAG 不必从“大一统安全大脑”开始。更现实的路线是选择一个高价值闭环，例如漏洞优先级、告警调查或威胁情报匹配。以漏洞优先级为例，第一阶段只建 CVE、CPE、资产、业务重要性、暴露面、补丁状态之间的图；向量索引用于召回公告、厂商说明和缓解建议。第二阶段再加入 EPSS、KEV、公开利用、历史扫描结果和例外审批。第三阶段接入告警与事件，把“有漏洞”与“有利用迹象”连接起来。
数据建模上，应优先定义稳定 ID 和关系语义。CVE ID、CWE ID、ATT&CK ID、资产 ID、云资源 ARN、包 URL、镜像 digest 等都应标准化。没有稳定 ID 的实体可以先作为观测节点存在，不要过早合并。关系抽取要分级：确定性关系来自 API 或结构化数据；半确定性关系来自规则解析；推断关系来自模型或分析员判断，并保留置信度。
系统架构上，图数据库、向量数据库、搜索引擎和对象存储各有位置。图数据库负责多跳关系和路径查询；向量数据库负责语义召回；搜索引擎负责精确过滤和日志检索；对象存储保存原始文档、报告和证据附件。LLM 编排层负责查询规划、证据摘要和生成，但应受到权限、预算、最大跳数和证据引用规则约束。
最终，安全知识库需要 GraphRAG，不是因为图谱比向量更“高级”，也不是因为 LLM 需要更多上下文，而是因为安全判断依赖关系。漏洞是否影响资产，告警是否构成攻击链，建议是否可执行，答案都必须穿过一组实体、关系、时间和证据。普通 RAG 把知识看作可召回文本；GraphRAG 把知识看作可验证状态。对安全团队而言，这一区别决定了系统是一个更会搜索的聊天框，还是一个能支撑调查、优先级排序和审计的工程基础设施。
