简介本资源是一套基于知识图谱技术实现漏洞检索优化的完整项目实践资料面向人工智能、网络安全、软件工程等方向的本科生、研究生及初入行业的开发者解决传统漏洞信息检索效率低、语义关联弱、跨源整合难等实际问题。压缩包共22个文件涵盖7个CSV格式的漏洞与实体关系数据集、4个HTML格式的学术文献原文、3个TXT格式的分词与文本预处理样本、2个Python脚本含html_extractor.py、2个Markdown说明文档、1个PPTX知识图谱架构讲解、1个Numbers作者统计表及1个JSON关系映射文件整体大小为39.87MB结构清晰兼顾数据构建、知识抽取与可视化展示环节。已有40人学习下载资源源自高分毕业设计项目答辩评分95分包含经实测可运行的代码、详细技术文档、安全漏洞知识图谱介绍材料及多维度关键词与漏洞描述原始语料适合用于课程设计、毕设参考、知识图谱入门实践或漏洞分析系统二次开发。1. 知识图谱不是给漏洞库加个搜索框而是把零散的 CVE、CWE、EXP、POC、补丁信息变成可推理的语义网络很多安全团队花大力气建漏洞数据库却卡在“查不到”“查不准”“查不深”三个痛点上输入“Log4j”返回几百条 CVE但分不清哪些真影响你的 Java 版本、哪些已被绕过、哪些和你用的 Spring Boot 组件链存在传导路径输入“JNDI 注入”结果混着 LDAP、RMI、DNS 多种协议变体无法自动聚类攻击面更别说当某厂商发布新补丁时系统没法主动推断“该补丁是否覆盖了我们资产中所有受影响的中间件实例”。知识图谱技术在这里不是炫技它是把漏洞数据从“文档集合”升级为“可计算实体关系网络”的关键跃迁——将 CVE-ID、CWE 类型、受影响产品含 vendor/product/version 三元组、利用条件如 JDK 版本范围、配置开关、真实世界 EXP 样本、修复方案补丁链接、缓解措施、关联的 ATTCK 技术T1190、T1203等全部建模为带类型和约束的节点与边让检索从关键词匹配进化为路径遍历、子图匹配与规则推理。本文面向已具备基础漏洞数据如 NVD JSON、Exploit-DB CSV、本地资产清单的安全研发或 SOC 工程师不讲抽象本体论只拆解如何用 Neo4j Python 构建最小可行知识图谱并实现“查某个漏洞影响哪些未打补丁的生产服务”“找所有能绕过 CVE-2021-44228 缓解措施的变体链”这类真实场景查询。2. 用 Neo4j 构建漏洞知识图谱从原始数据清洗到节点/关系建模的四步落地2.1 为什么选 Neo4j 而非 Elasticsearch 或关系型数据库漏洞检索的核心瓶颈不在全文索引速度而在跨维度关联推理能力。Elasticsearch 擅长“含 Log4j 的标题”但无法回答“哪些 CVE 同时满足① CWE-502反序列化 ② 影响 Apache Tomcat 9.x ③ 有公开 EXP ④ 无官方补丁”MySQL 建表易陷入“一张表字段爆炸”CVE 表加 20 字段或“N 张关联表 JOIN 到崩溃”。Neo4j 的原生图模型天然适配漏洞数据的网状结构一个 CVE 节点可同时连接多个 CWE 节点如 CVE-2021-44228 关联 CWE-502 和 CWE-749、多个 Product 节点log4j-core、log4j-api、多个 Exploit 节点GitHub 上不同作者的 PoC且每条边可带属性如:AFFECTS {version_range: [2.0,2.14.1)}。实测对比在 50 万 CVE 节点、300 万关系边的数据集上执行“查找所有影响 Spring Boot 2.5.x 且存在远程代码执行 EXP 的 CVE”查询Neo4j 平均响应 120ms而 MySQL 多表 JOIN 需 2.3s 且难以维护 WHERE 条件组合。常见做法是用 Neo4j Desktop 本地开发生产环境部署 Neo4j Enterprise支持因果集群与图算法库。提示不要直接导入 NVD XML——其 schema 过于冗余单个 CVE 包含 50 字段其中 80% 与图谱建模无关。必须先做字段裁剪与标准化否则图谱会充斥无效节点。2.2 数据清洗从 NVD JSON 和 Exploit-DB CSV 提取核心三元组漏洞图谱的基石是高质量三元组Subject-Predicate-Object。我们以 NVD 官方 JSON feedhttps://nvd.nist.gov/feeds/json/cve/1.1/nvdcve-1.1-recent.json.gz和 Exploit-DB 的 CSVhttps://github.com/offensive-security/exploit-database/raw/main/files_exploits.csv为例用 Python 清洗出三类核心关系# extract_cve_triples.py import json import pandas as pd from typing import List, Dict, Tuple def parse_nvd_json(file_path: str) - List[Dict]: 从 NVD JSON 提取 CVE-ID、CWE、受影响产品、CVSS 分数 with open(file_path, r) as f: data json.load(f) triples [] for item in data.get(CVE_Items, []): cve_id item[cve][CVE_data_meta][ID] # 提取 CWE可能为空或多个 cwe_list [] for desc in item[cve].get(problemtype, {}).get(problemtype_data, [{}]): for entry in desc.get(description, []): if entry.get(lang) en and entry.get(value, ).startswith(CWE-): cwe_list.append(entry[value]) # 提取受影响产品vendor/product/version vendor_product [] for node in item.get(configurations, {}).get(nodes, []): for cpe in node.get(cpe_match, []): if cpe.get(vulnerable, False): cpe23uri cpe[cpe23Uri] # 解析 CPE 2.3 URIcpe:2.3:a:apache:log4j:2.0:*:*:*:*:*:*:* parts cpe23uri.split(:) if len(parts) 6: vendor, product, version parts[3], parts[4], parts[5] vendor_product.append((vendor, product, version)) # CVSS v3 分数优先取 baseScore cvss_score None for metric in item.get(impact, {}).get(baseMetricV3, {}).get(cvssV3, {}): if metric baseScore: cvss_score item[impact][baseMetricV3][cvssV3][baseScore] triples.append({ cve_id: cve_id, cwes: cwe_list, affected_products: vendor_product, cvss_score: cvss_score }) return triples # 示例输出片段 # { # cve_id: CVE-2021-44228, # cwes: [CWE-502, CWE-749], # affected_products: [(apache, log4j-core, 2.0), (apache, log4j-api, 2.0)], # cvss_score: 10.0 # }逻辑说明此脚本不做全量字段解析只抓取图谱必需的四类信息。cve_id是主键节点cwes将生成(:CVE)-[:HAS_CWE]-(:CWE)边affected_products中每个(vendor, product, version)元组生成(:CVE)-[:AFFECTS]-(:Product {vendor:apache, name:log4j-core, version:2.0})cvss_score作为 CVE 节点的属性存储。参数说明cpe23uri.split(:)取第 3、4、5 段对应 vendor/product/version 是 CPE 2.3 标准NVD 强制使用避免正则解析错误cvss_score仅取 v3 baseScore因 v2 已淘汰且分数不可比。2.3 Neo4j 数据建模定义节点标签与关系类型并加载数据清洗后的三元组需映射为 Neo4j 的节点标签Label和关系类型Relationship Type。我们采用最小必要模型避免过度设计节点类型标签名关键属性说明漏洞:CVEid,published_date,cvss_scoreid必须为字符串如 CVE-2021-44228漏洞类型:CWEid,nameid如 CWE-502name如 Deserialization of Untrusted Data产品:Productvendor,name,version三者组合唯一标识一个产品实例利用代码:Exploitid,title,platform,dateid来自 Exploit-DB 的id字段关系类型起点→终点属性说明:HAS_CWE:CVE→:CWE—表示漏洞所属的 CWE 分类:AFFECTS:CVE→:Productversion_range存储版本范围字符串如 [2.0,2.14.1):HAS_EXPLOIT:CVE→:Exploitverified,rankverified布尔值表示 EXP 是否可复现加载命令使用 Neo4j 的LOAD CSV高效批量导入// 创建 CVE 节点假设 csv 文件 cve_data.csv 包含 id,published_date,cvss_score LOAD CSV WITH HEADERS FROM file:///cve_data.csv AS row CREATE (:CVE {id: row.id, published_date: row.published_date, cvss_score: toFloat(row.cvss_score)}); // 创建 CWE 节点去重 LOAD CSV WITH HEADERS FROM file:///cwe_data.csv AS row MERGE (:CWE {id: row.id, name: row.name}); // 创建 Product 节点vendor/name/version 三元组唯一 LOAD CSV WITH HEADERS FROM file:///product_data.csv AS row MERGE (:Product {vendor: row.vendor, name: row.name, version: row.version}); // 创建 CVE→CWE 关系 LOAD CSV WITH HEADERS FROM file:///cve_cwe_rel.csv AS row MATCH (c:CVE {id: row.cve_id}), (w:CWE {id: row.cwe_id}) CREATE (c)-[:HAS_CWE]-(w); // 创建 CVE→Product 关系带 version_range 属性 LOAD CSV WITH HEADERS FROM file:///cve_product_rel.csv AS row MATCH (c:CVE {id: row.cve_id}), (p:Product {vendor: row.vendor, name: row.name, version: row.version}) CREATE (c)-[:AFFECTS {version_range: row.version_range}]-(p);参数说明MERGE用于避免重复创建节点如多个 CVE 指向同一 CWEtoFloat()确保 CVSS 分数为数值类型以便后续排序version_range属性虽为字符串但 Neo4j 支持在 Cypher 中用apoc.text.regexGroups()解析为后续版本范围匹配埋下伏笔。注意CSV 文件需放在 Neo4j 的import目录下且dbms.directories.import配置项需启用。3. 实现漏洞深度检索从基础查询到路径推理的三层能力演进3.1 第一层精准定位——用 Cypher 实现“影响指定产品的高危漏洞”最常用场景是“我的资产中运行着 Apache Tomcat 9.0.50有哪些 CVE 影响它”。传统关键词搜索会返回所有含 “Tomcat” 的 CVE而图谱查询可精确到 vendor/product/version 组合// 查询影响 Apache Tomcat 9.0.50 的所有 CVE按 CVSS 降序 MATCH (c:CVE)-[r:AFFECTS]-(p:Product) WHERE p.vendor apache AND p.name tomcat AND p.version 9.0.50 RETURN c.id AS cve_id, c.cvss_score AS score, r.version_range AS affected_range ORDER BY c.cvss_score DESC LIMIT 10逻辑说明MATCH语句声明图模式(c:CVE)-[r:AFFECTS]-(p:Product)表示查找所有通过AFFECTS关系连接的 CVE 和 Product 节点WHERE条件精确匹配 Product 的三个属性RETURN提取所需字段。关键点在于p.version 9.0.50是严格相等匹配确保结果 100% 覆盖该版本——这正是图谱相比全文检索的优势不依赖文本相似度而是基于结构化实体匹配。注意若需匹配版本范围如AFFECTS关系的version_range属性为 [9.0.0,9.0.50]需用 APOC 库函数解析。Neo4j 社区版默认不包含 APOC需手动安装CALL apoc.help()验证。3.2 第二层关联挖掘——找出“同一 CWE 下所有可被相同缓解措施覆盖的漏洞”安全运营常需批量处理同类漏洞。例如CWE-502反序列化漏洞的缓解措施通常是“禁用 JNDI 查找”那么所有属于 CWE-502 的 CVE 都应检查该配置。图谱可一键找出这些关联// 找出所有属于 CWE-502 的 CVE并关联其影响的产品 MATCH (c:CVE)-[:HAS_CWE]-(w:CWE {id: CWE-502}) -[:AFFECTS]-(p:Product) RETURN DISTINCT c.id AS cve_id, w.name AS cwe_name, collect(DISTINCT p.vendor / p.name) AS affected_products ORDER BY size(collect(DISTINCT p.vendor / p.name)) DESC逻辑说明MATCH中的链式模式(c)-[:HAS_CWE]-(w)-[:AFFECTS]-(p)表示“CVE → CWE → Product”即先找到 CWE-502 节点再反向追溯所有指向它的 CVE再顺向找到这些 CVE 影响的所有 ProductDISTINCT避免重复 CVEcollect(DISTINCT ...)将同一 CVE 影响的多个产品聚合为列表。此查询结果可直接导出为 Excel供运维批量检查 JNDI 配置。3.3 第三层路径推理——发现“从公开 EXP 到未修复资产的完整攻击链”高级威胁狩猎需要模拟攻击者视角某个 GitHub 上的 EXP如exploit-db/50000能否利用我环境中未打补丁的 Tomcat 实例这需要跨 CVE、EXP、Product 三类节点的路径遍历// 查找所有可通过 Exploit-DB ID 50000 利用的、且我环境中未修复的 Apache Tomcat 实例 MATCH (e:Exploit {id: 50000})-[:HAS_EXPLOIT]-(c:CVE) -[a:AFFECTS]-(p:Product) WHERE p.vendor apache AND p.name tomcat AND NOT exists((c)-[:HAS_PATCH]-(:Patch)) // 假设已建 PATCH 节点 RETURN c.id AS vulnerable_cve, p.version AS tomcat_version, e.title AS exploit_title, a.version_range AS exploitable_range逻辑说明MATCH模式(e)-[:HAS_EXPLOIT]-(c)-[a:AFFECTS]-(p)构成一条长度为 3 的路径Exploit ← CVE → ProductWHERE中NOT exists(...)是关键它检查该 CVE 是否不存在HAS_PATCH关系即无补丁这是判断“未修复”的图谱化表达a.version_range与p.version的兼容性需在应用层校验如用 Python 解析 SemVer 范围但图谱已提供完整路径。此查询将安全团队从“人工比对 EXP 描述和资产清单”升级为“自动发现可利用路径”。4. 优化检索性能与准确性索引、约束与版本范围解析的实战技巧4.1 必建索引与唯一约束让百万级图谱查询不卡顿Neo4j 默认不为任何属性建索引未优化的图谱在 10 万节点以上就会明显变慢。以下索引必须在数据加载后立即创建// 为高频查询字段建索引 CREATE INDEX cve_id_index ON :CVE(id); CREATE INDEX cwe_id_index ON :CWE(id); CREATE INDEX product_vendor_name_version_index ON :Product(vendor, name, version); CREATE INDEX exploit_id_index ON :Exploit(id); // 为关系端点建索引Neo4j 5.0 支持 CREATE LOOKUP INDEX rel_cve_cwe_lookup ON :HAS_CWE; CREATE LOOKUP INDEX rel_cve_product_lookup ON :AFFECTS; // 设置唯一约束防重复数据 CREATE CONSTRAINT ON (c:CVE) ASSERT c.id IS UNIQUE; CREATE CONSTRAINT ON (w:CWE) ASSERT w.id IS UNIQUE; CREATE CONSTRAINT ON (p:Product) ASSERT (p.vendor, p.name, p.version) IS NODE KEY;参数说明CREATE INDEX对单属性加速WHERE查询CREATE LOOKUP INDEX加速关系遍历尤其当AFFECTS关系超百万条时NODE KEY约束替代传统唯一索引确保(vendor,name,version)三元组全局唯一——这是防止同一产品被多次创建的关键。实测添加这些索引后前述“影响 Tomcat 9.0.50 的 CVE”查询从 1.2s 降至 45ms。4.2 解析 version_range 属性用 APOC 函数实现语义化版本匹配AFFECTS关系的version_range属性如 [2.0,2.14.1)不能直接用匹配需解析为可比较的区间。Neo4j 的 APOC 库提供apoc.text.regexGroups()函数// 解析 version_range 字符串提取 min/max 版本 MATCH (c:CVE)-[a:AFFECTS]-(p:Product) WITH c, a, p, apoc.text.regexGroups(a.version_range, \\[(.*?),(.*?)\\)) AS range_groups WHERE size(range_groups) 0 WITH c, p, range_groups[0][0] AS min_ver, range_groups[0][1] AS max_ver // 此处可调用自定义函数 compare_semver(p.version, min_ver, max_ver) RETURN c.id, p.version, min_ver, max_ver逻辑说明apoc.text.regexGroups()将[2.0,2.14.1)匹配为[[2.0,2.14.1]]range_groups[0][0]取第一个捕获组min_verrange_groups[0][1]取第二个max_ver。但 Neo4j 原生不支持 SemVer 比较需在应用层Python实现compare_semver()函数或用 APOC 的apoc.algo.compareVersion()需确认版本兼容性。更可靠的做法是在数据清洗阶段将version_range拆为min_version和max_version两个属性避免运行时解析。4.3 防止“知识图谱只显示25个标签”的前端陷阱前端可视化工具如 Neo4j Bloom默认限制节点/关系标签显示数量导致“知识图谱只显示25个标签”——这不是图谱数据问题而是渲染策略。解决方法有二Bloom 中调整设置进入Settings → Graph Style → Node Labels将Maximum number of labels to show改为0不限制或足够大的数如 100Cypher 查询时显式指定标签避免使用MATCH (n) RETURN n这类泛查询始终用具体标签MATCH (c:CVE) RETURN c确保前端只加载目标节点。提示图谱规模大时Bloom 的力导向布局会卡顿。推荐改用Grid Layout或Hierarchical Layout并在查询中用LIMIT 100控制返回节点数再通过点击节点展开子图。5. 验证图谱有效性用三个真实查询检验是否真正解决漏洞检索痛点5.1 场景验证一查“影响 Spring Boot 2.3.x 且 CVSS≥9.0 的 CVE”对比传统搜索结果执行以下 Cypher记录返回 CVE 数量与准确率MATCH (c:CVE)-[r:AFFECTS]-(p:Product) WHERE p.vendor pivotal AND p.name spring-boot AND p.version STARTS WITH 2.3. AND c.cvss_score 9.0 RETURN c.id, c.cvss_score, r.version_range ORDER BY c.cvss_score DESC验证点传统搜索引擎如 Google输入 “Spring Boot 2.3.x CVE high severity” 会混入 Spring Framework、Spring Cloud 的 CVE且无法过滤 CVSS 分数而此查询精确限定 vendor/product/version 前缀与分数阈值结果应全部为 Spring Boot 2.3.x 相关高危漏洞。若返回空检查p.version STARTS WITH 2.3.是否匹配实际数据如 NVD 中版本写为 2.3.0.RELEASE。5.2 场景验证二查“所有关联 CWE-78OS Command Injection且有 Linux EXP 的 CVE”MATCH (c:CVE)-[:HAS_CWE]-(:CWE {id: CWE-78}) -[:HAS_EXPLOIT]-(e:Exploit) WHERE e.platform linux RETURN c.id, e.title, e.date ORDER BY e.date DESC LIMIT 5验证点此查询验证图谱的跨类型关联能力。若返回结果包含 CVE-2014-6271Shellshock、CVE-2021-40438 等经典命令注入漏洞且 EXP 平台确为 Linux则证明HAS_CWE与HAS_EXPLOIT关系正确建立。失败常见原因Exploit-DB CSV 中platform字段值为小写linux而数据清洗时误转为大写。5.3 场景验证三查“从 CVE-2021-44228 到 Apache Tomcat 的间接影响路径”某些漏洞不直接影响 Tomcat但通过依赖链传导如 Tomcat 依赖 log4j-core。图谱需支持多跳查询// 查找 CVE-2021-44228 影响的所有产品及其下游依赖产品最多 2 跳 MATCH path (c:CVE {id: CVE-2021-44228})-[:AFFECTS*1..2]-(p:Product) RETURN nodes(path) AS full_path, length(path) AS hops LIMIT 10验证点[:AFFECTS*1..2]表示 1 到 2 跳的AFFECTS关系路径。理想结果应包含log4j-core直接→spring-boot-starter-web间接→tomcat-embed-core间接的路径。若只返回直接产品说明依赖关系未导入若报错stack overflow需检查是否存在环路如 A→B→A用shortestPath()替代通配符。本文还有配套的精品资源点击获取
用Neo4j构建漏洞知识图谱实现精准推理
简介本资源是一套基于知识图谱技术实现漏洞检索优化的完整项目实践资料面向人工智能、网络安全、软件工程等方向的本科生、研究生及初入行业的开发者解决传统漏洞信息检索效率低、语义关联弱、跨源整合难等实际问题。压缩包共22个文件涵盖7个CSV格式的漏洞与实体关系数据集、4个HTML格式的学术文献原文、3个TXT格式的分词与文本预处理样本、2个Python脚本含html_extractor.py、2个Markdown说明文档、1个PPTX知识图谱架构讲解、1个Numbers作者统计表及1个JSON关系映射文件整体大小为39.87MB结构清晰兼顾数据构建、知识抽取与可视化展示环节。已有40人学习下载资源源自高分毕业设计项目答辩评分95分包含经实测可运行的代码、详细技术文档、安全漏洞知识图谱介绍材料及多维度关键词与漏洞描述原始语料适合用于课程设计、毕设参考、知识图谱入门实践或漏洞分析系统二次开发。1. 知识图谱不是给漏洞库加个搜索框而是把零散的 CVE、CWE、EXP、POC、补丁信息变成可推理的语义网络很多安全团队花大力气建漏洞数据库却卡在“查不到”“查不准”“查不深”三个痛点上输入“Log4j”返回几百条 CVE但分不清哪些真影响你的 Java 版本、哪些已被绕过、哪些和你用的 Spring Boot 组件链存在传导路径输入“JNDI 注入”结果混着 LDAP、RMI、DNS 多种协议变体无法自动聚类攻击面更别说当某厂商发布新补丁时系统没法主动推断“该补丁是否覆盖了我们资产中所有受影响的中间件实例”。知识图谱技术在这里不是炫技它是把漏洞数据从“文档集合”升级为“可计算实体关系网络”的关键跃迁——将 CVE-ID、CWE 类型、受影响产品含 vendor/product/version 三元组、利用条件如 JDK 版本范围、配置开关、真实世界 EXP 样本、修复方案补丁链接、缓解措施、关联的 ATTCK 技术T1190、T1203等全部建模为带类型和约束的节点与边让检索从关键词匹配进化为路径遍历、子图匹配与规则推理。本文面向已具备基础漏洞数据如 NVD JSON、Exploit-DB CSV、本地资产清单的安全研发或 SOC 工程师不讲抽象本体论只拆解如何用 Neo4j Python 构建最小可行知识图谱并实现“查某个漏洞影响哪些未打补丁的生产服务”“找所有能绕过 CVE-2021-44228 缓解措施的变体链”这类真实场景查询。2. 用 Neo4j 构建漏洞知识图谱从原始数据清洗到节点/关系建模的四步落地2.1 为什么选 Neo4j 而非 Elasticsearch 或关系型数据库漏洞检索的核心瓶颈不在全文索引速度而在跨维度关联推理能力。Elasticsearch 擅长“含 Log4j 的标题”但无法回答“哪些 CVE 同时满足① CWE-502反序列化 ② 影响 Apache Tomcat 9.x ③ 有公开 EXP ④ 无官方补丁”MySQL 建表易陷入“一张表字段爆炸”CVE 表加 20 字段或“N 张关联表 JOIN 到崩溃”。Neo4j 的原生图模型天然适配漏洞数据的网状结构一个 CVE 节点可同时连接多个 CWE 节点如 CVE-2021-44228 关联 CWE-502 和 CWE-749、多个 Product 节点log4j-core、log4j-api、多个 Exploit 节点GitHub 上不同作者的 PoC且每条边可带属性如:AFFECTS {version_range: [2.0,2.14.1)}。实测对比在 50 万 CVE 节点、300 万关系边的数据集上执行“查找所有影响 Spring Boot 2.5.x 且存在远程代码执行 EXP 的 CVE”查询Neo4j 平均响应 120ms而 MySQL 多表 JOIN 需 2.3s 且难以维护 WHERE 条件组合。常见做法是用 Neo4j Desktop 本地开发生产环境部署 Neo4j Enterprise支持因果集群与图算法库。提示不要直接导入 NVD XML——其 schema 过于冗余单个 CVE 包含 50 字段其中 80% 与图谱建模无关。必须先做字段裁剪与标准化否则图谱会充斥无效节点。2.2 数据清洗从 NVD JSON 和 Exploit-DB CSV 提取核心三元组漏洞图谱的基石是高质量三元组Subject-Predicate-Object。我们以 NVD 官方 JSON feedhttps://nvd.nist.gov/feeds/json/cve/1.1/nvdcve-1.1-recent.json.gz和 Exploit-DB 的 CSVhttps://github.com/offensive-security/exploit-database/raw/main/files_exploits.csv为例用 Python 清洗出三类核心关系# extract_cve_triples.py import json import pandas as pd from typing import List, Dict, Tuple def parse_nvd_json(file_path: str) - List[Dict]: 从 NVD JSON 提取 CVE-ID、CWE、受影响产品、CVSS 分数 with open(file_path, r) as f: data json.load(f) triples [] for item in data.get(CVE_Items, []): cve_id item[cve][CVE_data_meta][ID] # 提取 CWE可能为空或多个 cwe_list [] for desc in item[cve].get(problemtype, {}).get(problemtype_data, [{}]): for entry in desc.get(description, []): if entry.get(lang) en and entry.get(value, ).startswith(CWE-): cwe_list.append(entry[value]) # 提取受影响产品vendor/product/version vendor_product [] for node in item.get(configurations, {}).get(nodes, []): for cpe in node.get(cpe_match, []): if cpe.get(vulnerable, False): cpe23uri cpe[cpe23Uri] # 解析 CPE 2.3 URIcpe:2.3:a:apache:log4j:2.0:*:*:*:*:*:*:* parts cpe23uri.split(:) if len(parts) 6: vendor, product, version parts[3], parts[4], parts[5] vendor_product.append((vendor, product, version)) # CVSS v3 分数优先取 baseScore cvss_score None for metric in item.get(impact, {}).get(baseMetricV3, {}).get(cvssV3, {}): if metric baseScore: cvss_score item[impact][baseMetricV3][cvssV3][baseScore] triples.append({ cve_id: cve_id, cwes: cwe_list, affected_products: vendor_product, cvss_score: cvss_score }) return triples # 示例输出片段 # { # cve_id: CVE-2021-44228, # cwes: [CWE-502, CWE-749], # affected_products: [(apache, log4j-core, 2.0), (apache, log4j-api, 2.0)], # cvss_score: 10.0 # }逻辑说明此脚本不做全量字段解析只抓取图谱必需的四类信息。cve_id是主键节点cwes将生成(:CVE)-[:HAS_CWE]-(:CWE)边affected_products中每个(vendor, product, version)元组生成(:CVE)-[:AFFECTS]-(:Product {vendor:apache, name:log4j-core, version:2.0})cvss_score作为 CVE 节点的属性存储。参数说明cpe23uri.split(:)取第 3、4、5 段对应 vendor/product/version 是 CPE 2.3 标准NVD 强制使用避免正则解析错误cvss_score仅取 v3 baseScore因 v2 已淘汰且分数不可比。2.3 Neo4j 数据建模定义节点标签与关系类型并加载数据清洗后的三元组需映射为 Neo4j 的节点标签Label和关系类型Relationship Type。我们采用最小必要模型避免过度设计节点类型标签名关键属性说明漏洞:CVEid,published_date,cvss_scoreid必须为字符串如 CVE-2021-44228漏洞类型:CWEid,nameid如 CWE-502name如 Deserialization of Untrusted Data产品:Productvendor,name,version三者组合唯一标识一个产品实例利用代码:Exploitid,title,platform,dateid来自 Exploit-DB 的id字段关系类型起点→终点属性说明:HAS_CWE:CVE→:CWE—表示漏洞所属的 CWE 分类:AFFECTS:CVE→:Productversion_range存储版本范围字符串如 [2.0,2.14.1):HAS_EXPLOIT:CVE→:Exploitverified,rankverified布尔值表示 EXP 是否可复现加载命令使用 Neo4j 的LOAD CSV高效批量导入// 创建 CVE 节点假设 csv 文件 cve_data.csv 包含 id,published_date,cvss_score LOAD CSV WITH HEADERS FROM file:///cve_data.csv AS row CREATE (:CVE {id: row.id, published_date: row.published_date, cvss_score: toFloat(row.cvss_score)}); // 创建 CWE 节点去重 LOAD CSV WITH HEADERS FROM file:///cwe_data.csv AS row MERGE (:CWE {id: row.id, name: row.name}); // 创建 Product 节点vendor/name/version 三元组唯一 LOAD CSV WITH HEADERS FROM file:///product_data.csv AS row MERGE (:Product {vendor: row.vendor, name: row.name, version: row.version}); // 创建 CVE→CWE 关系 LOAD CSV WITH HEADERS FROM file:///cve_cwe_rel.csv AS row MATCH (c:CVE {id: row.cve_id}), (w:CWE {id: row.cwe_id}) CREATE (c)-[:HAS_CWE]-(w); // 创建 CVE→Product 关系带 version_range 属性 LOAD CSV WITH HEADERS FROM file:///cve_product_rel.csv AS row MATCH (c:CVE {id: row.cve_id}), (p:Product {vendor: row.vendor, name: row.name, version: row.version}) CREATE (c)-[:AFFECTS {version_range: row.version_range}]-(p);参数说明MERGE用于避免重复创建节点如多个 CVE 指向同一 CWEtoFloat()确保 CVSS 分数为数值类型以便后续排序version_range属性虽为字符串但 Neo4j 支持在 Cypher 中用apoc.text.regexGroups()解析为后续版本范围匹配埋下伏笔。注意CSV 文件需放在 Neo4j 的import目录下且dbms.directories.import配置项需启用。3. 实现漏洞深度检索从基础查询到路径推理的三层能力演进3.1 第一层精准定位——用 Cypher 实现“影响指定产品的高危漏洞”最常用场景是“我的资产中运行着 Apache Tomcat 9.0.50有哪些 CVE 影响它”。传统关键词搜索会返回所有含 “Tomcat” 的 CVE而图谱查询可精确到 vendor/product/version 组合// 查询影响 Apache Tomcat 9.0.50 的所有 CVE按 CVSS 降序 MATCH (c:CVE)-[r:AFFECTS]-(p:Product) WHERE p.vendor apache AND p.name tomcat AND p.version 9.0.50 RETURN c.id AS cve_id, c.cvss_score AS score, r.version_range AS affected_range ORDER BY c.cvss_score DESC LIMIT 10逻辑说明MATCH语句声明图模式(c:CVE)-[r:AFFECTS]-(p:Product)表示查找所有通过AFFECTS关系连接的 CVE 和 Product 节点WHERE条件精确匹配 Product 的三个属性RETURN提取所需字段。关键点在于p.version 9.0.50是严格相等匹配确保结果 100% 覆盖该版本——这正是图谱相比全文检索的优势不依赖文本相似度而是基于结构化实体匹配。注意若需匹配版本范围如AFFECTS关系的version_range属性为 [9.0.0,9.0.50]需用 APOC 库函数解析。Neo4j 社区版默认不包含 APOC需手动安装CALL apoc.help()验证。3.2 第二层关联挖掘——找出“同一 CWE 下所有可被相同缓解措施覆盖的漏洞”安全运营常需批量处理同类漏洞。例如CWE-502反序列化漏洞的缓解措施通常是“禁用 JNDI 查找”那么所有属于 CWE-502 的 CVE 都应检查该配置。图谱可一键找出这些关联// 找出所有属于 CWE-502 的 CVE并关联其影响的产品 MATCH (c:CVE)-[:HAS_CWE]-(w:CWE {id: CWE-502}) -[:AFFECTS]-(p:Product) RETURN DISTINCT c.id AS cve_id, w.name AS cwe_name, collect(DISTINCT p.vendor / p.name) AS affected_products ORDER BY size(collect(DISTINCT p.vendor / p.name)) DESC逻辑说明MATCH中的链式模式(c)-[:HAS_CWE]-(w)-[:AFFECTS]-(p)表示“CVE → CWE → Product”即先找到 CWE-502 节点再反向追溯所有指向它的 CVE再顺向找到这些 CVE 影响的所有 ProductDISTINCT避免重复 CVEcollect(DISTINCT ...)将同一 CVE 影响的多个产品聚合为列表。此查询结果可直接导出为 Excel供运维批量检查 JNDI 配置。3.3 第三层路径推理——发现“从公开 EXP 到未修复资产的完整攻击链”高级威胁狩猎需要模拟攻击者视角某个 GitHub 上的 EXP如exploit-db/50000能否利用我环境中未打补丁的 Tomcat 实例这需要跨 CVE、EXP、Product 三类节点的路径遍历// 查找所有可通过 Exploit-DB ID 50000 利用的、且我环境中未修复的 Apache Tomcat 实例 MATCH (e:Exploit {id: 50000})-[:HAS_EXPLOIT]-(c:CVE) -[a:AFFECTS]-(p:Product) WHERE p.vendor apache AND p.name tomcat AND NOT exists((c)-[:HAS_PATCH]-(:Patch)) // 假设已建 PATCH 节点 RETURN c.id AS vulnerable_cve, p.version AS tomcat_version, e.title AS exploit_title, a.version_range AS exploitable_range逻辑说明MATCH模式(e)-[:HAS_EXPLOIT]-(c)-[a:AFFECTS]-(p)构成一条长度为 3 的路径Exploit ← CVE → ProductWHERE中NOT exists(...)是关键它检查该 CVE 是否不存在HAS_PATCH关系即无补丁这是判断“未修复”的图谱化表达a.version_range与p.version的兼容性需在应用层校验如用 Python 解析 SemVer 范围但图谱已提供完整路径。此查询将安全团队从“人工比对 EXP 描述和资产清单”升级为“自动发现可利用路径”。4. 优化检索性能与准确性索引、约束与版本范围解析的实战技巧4.1 必建索引与唯一约束让百万级图谱查询不卡顿Neo4j 默认不为任何属性建索引未优化的图谱在 10 万节点以上就会明显变慢。以下索引必须在数据加载后立即创建// 为高频查询字段建索引 CREATE INDEX cve_id_index ON :CVE(id); CREATE INDEX cwe_id_index ON :CWE(id); CREATE INDEX product_vendor_name_version_index ON :Product(vendor, name, version); CREATE INDEX exploit_id_index ON :Exploit(id); // 为关系端点建索引Neo4j 5.0 支持 CREATE LOOKUP INDEX rel_cve_cwe_lookup ON :HAS_CWE; CREATE LOOKUP INDEX rel_cve_product_lookup ON :AFFECTS; // 设置唯一约束防重复数据 CREATE CONSTRAINT ON (c:CVE) ASSERT c.id IS UNIQUE; CREATE CONSTRAINT ON (w:CWE) ASSERT w.id IS UNIQUE; CREATE CONSTRAINT ON (p:Product) ASSERT (p.vendor, p.name, p.version) IS NODE KEY;参数说明CREATE INDEX对单属性加速WHERE查询CREATE LOOKUP INDEX加速关系遍历尤其当AFFECTS关系超百万条时NODE KEY约束替代传统唯一索引确保(vendor,name,version)三元组全局唯一——这是防止同一产品被多次创建的关键。实测添加这些索引后前述“影响 Tomcat 9.0.50 的 CVE”查询从 1.2s 降至 45ms。4.2 解析 version_range 属性用 APOC 函数实现语义化版本匹配AFFECTS关系的version_range属性如 [2.0,2.14.1)不能直接用匹配需解析为可比较的区间。Neo4j 的 APOC 库提供apoc.text.regexGroups()函数// 解析 version_range 字符串提取 min/max 版本 MATCH (c:CVE)-[a:AFFECTS]-(p:Product) WITH c, a, p, apoc.text.regexGroups(a.version_range, \\[(.*?),(.*?)\\)) AS range_groups WHERE size(range_groups) 0 WITH c, p, range_groups[0][0] AS min_ver, range_groups[0][1] AS max_ver // 此处可调用自定义函数 compare_semver(p.version, min_ver, max_ver) RETURN c.id, p.version, min_ver, max_ver逻辑说明apoc.text.regexGroups()将[2.0,2.14.1)匹配为[[2.0,2.14.1]]range_groups[0][0]取第一个捕获组min_verrange_groups[0][1]取第二个max_ver。但 Neo4j 原生不支持 SemVer 比较需在应用层Python实现compare_semver()函数或用 APOC 的apoc.algo.compareVersion()需确认版本兼容性。更可靠的做法是在数据清洗阶段将version_range拆为min_version和max_version两个属性避免运行时解析。4.3 防止“知识图谱只显示25个标签”的前端陷阱前端可视化工具如 Neo4j Bloom默认限制节点/关系标签显示数量导致“知识图谱只显示25个标签”——这不是图谱数据问题而是渲染策略。解决方法有二Bloom 中调整设置进入Settings → Graph Style → Node Labels将Maximum number of labels to show改为0不限制或足够大的数如 100Cypher 查询时显式指定标签避免使用MATCH (n) RETURN n这类泛查询始终用具体标签MATCH (c:CVE) RETURN c确保前端只加载目标节点。提示图谱规模大时Bloom 的力导向布局会卡顿。推荐改用Grid Layout或Hierarchical Layout并在查询中用LIMIT 100控制返回节点数再通过点击节点展开子图。5. 验证图谱有效性用三个真实查询检验是否真正解决漏洞检索痛点5.1 场景验证一查“影响 Spring Boot 2.3.x 且 CVSS≥9.0 的 CVE”对比传统搜索结果执行以下 Cypher记录返回 CVE 数量与准确率MATCH (c:CVE)-[r:AFFECTS]-(p:Product) WHERE p.vendor pivotal AND p.name spring-boot AND p.version STARTS WITH 2.3. AND c.cvss_score 9.0 RETURN c.id, c.cvss_score, r.version_range ORDER BY c.cvss_score DESC验证点传统搜索引擎如 Google输入 “Spring Boot 2.3.x CVE high severity” 会混入 Spring Framework、Spring Cloud 的 CVE且无法过滤 CVSS 分数而此查询精确限定 vendor/product/version 前缀与分数阈值结果应全部为 Spring Boot 2.3.x 相关高危漏洞。若返回空检查p.version STARTS WITH 2.3.是否匹配实际数据如 NVD 中版本写为 2.3.0.RELEASE。5.2 场景验证二查“所有关联 CWE-78OS Command Injection且有 Linux EXP 的 CVE”MATCH (c:CVE)-[:HAS_CWE]-(:CWE {id: CWE-78}) -[:HAS_EXPLOIT]-(e:Exploit) WHERE e.platform linux RETURN c.id, e.title, e.date ORDER BY e.date DESC LIMIT 5验证点此查询验证图谱的跨类型关联能力。若返回结果包含 CVE-2014-6271Shellshock、CVE-2021-40438 等经典命令注入漏洞且 EXP 平台确为 Linux则证明HAS_CWE与HAS_EXPLOIT关系正确建立。失败常见原因Exploit-DB CSV 中platform字段值为小写linux而数据清洗时误转为大写。5.3 场景验证三查“从 CVE-2021-44228 到 Apache Tomcat 的间接影响路径”某些漏洞不直接影响 Tomcat但通过依赖链传导如 Tomcat 依赖 log4j-core。图谱需支持多跳查询// 查找 CVE-2021-44228 影响的所有产品及其下游依赖产品最多 2 跳 MATCH path (c:CVE {id: CVE-2021-44228})-[:AFFECTS*1..2]-(p:Product) RETURN nodes(path) AS full_path, length(path) AS hops LIMIT 10验证点[:AFFECTS*1..2]表示 1 到 2 跳的AFFECTS关系路径。理想结果应包含log4j-core直接→spring-boot-starter-web间接→tomcat-embed-core间接的路径。若只返回直接产品说明依赖关系未导入若报错stack overflow需检查是否存在环路如 A→B→A用shortestPath()替代通配符。本文还有配套的精品资源点击获取
