大语言模型驱动的多来源漏洞影响库识别研究解析
论文信息
| 信息类别 | 具体内容 |
|---|---|
| 论文原标题 | 一种基于大语言模型的多来源漏洞影响库识别方法 |
| 主要作者 | 徐近伟、周鑫、杨焱景、李晓康、余灏沣、杨岚心、张贺、吴永航 |
| 研究机构 | 1) 南京大学软件学院（南京 210093）；2) 计算机软件新技术国家重点实验室（南京大学）（南京 210093）；3) 北京兴云数科技术有限公司（北京 100176）、 |
| 收稿/网络首发日期 | 收稿日期：2025-02-07；网络首发日期：2025-07-24 、 |
| 发表期刊 | 《计算机学报》（Chinese Journal of Computers），ISSN 0254-4164，CN 11-1826/TP 、 |
| APA 引文格式 | Xu, J.-W., Zhou, X., Yang, Y.-J., Li, X.-K., Yu, H.-F., Yang, L.-X., Zhang, H., & Wu, Y.-H. (2025). An approach for identifying affected libraries from multiple sources based on large language models. Chinese Journal of Computers. https://link.cnki.net/urlid/11.1826.tp.20250722.1653.004 、 |
| 数据集开源地址 | https://figshare.com/s/cbd35613e0e524614e1e |
一段话总结
为解决现有漏洞影响库识别方法仅聚焦NVD英文报告、忽略中文来源及不同包管理器差异的问题，徐近伟等人提出基于Qwen1.5-14B大语言模型的多来源识别方法：先从CNNVD（中文）和NVD（英文）抽取漏洞信息实现输入增强，再通过Alpaca模板+LoRA技术微调模型，最后用文本相似度算法消除幻觉；实验以9260份中/英文报告为数据集，结果显示该方法较基线在中文、英文报告F1分别提升4%和8%，中/英文互补时F1达0.85，在PyPI、Composer等多数包管理器上表现优异，同时公开标注数据集以支持后续研究、、、。
思维导图
研究背景
现代软件开发早已进入"软件供应链时代"------就像手机厂商依赖屏幕、芯片等第三方配件，开发者也依赖大量第三方软件库（如Java的Maven库、Python的PyPI库）来减少重复开发、降低成本。但第三方库一旦存在漏洞，就会像"带毒的配件"一样，危害所有依赖它的下游软件，比如曾引发全球恐慌的Log4j漏洞，就是通过第三方库快速扩散的、。
为应对漏洞风险，NVD（美国国家漏洞数据库）、CNNVD（中国国家信息安全漏洞库）等平台会定期发布漏洞报告，但这些报告有个关键缺陷：只说漏洞危害，却不清晰标注受影响的具体软件库。比如CVE-2015-7318的NVD报告只提"影响Plone平台"，但实际受影响的是Plone里的Zope Python库；CVE-2023-576的报告提"影响glassfish软件"，但具体是org.glassfish.main.orb分组下的orb-connector库。
过去，安全专家只能手动分析报告、匹配影响库，这个过程不仅要花数小时甚至数天，还容易因信息不全出错------就像医生看病只看部分病历，没结合完整检查单，难免误诊。后来出现了自动化方法，但这些方法又有新问题：
- "语言偏见"：只认NVD的英文报告，忽略CNNVD的中文报告（每年数万份，含大量高危漏洞），导致中文场景下识别准确率低；
- "包管理器盲区"：不同包管理器的库命名规则差异大（Maven是"groupID:artifactID"，PyPI只有包名），但现有方法不区分，无法评估在不同包管理器上的效果；
- "数据过期"：所用数据集截止2019年，无法适配2019年后新出现的软件库和漏洞。
这些问题导致漏洞影响库识别"慢、偏、漏"，无法为软件供应链提供及时、全面的安全防护------这就是该研究要解决的核心痛点。
创新点
-
首次实现中/英文漏洞报告互补输入：突破现有方法仅依赖NVD英文报告的局限，将CNNVD中文报告与NVD英文报告结合，通过多来源信息补充提升准确性。例如CVE-2022-4147的NVD报告只提"影响Quarkus"，CNNVD报告补充"具体影响quarkus-vertx-http组件"，两者结合可精准定位影响库、。
-
轻量级大模型微调方案：采用LoRA（低秩适应）技术对Qwen1.5-14B进行微调，仅训练两个低秩矩阵（参数减少至原模型的0.05%），1张NVIDIA A100-40GB显卡即可运行，训练时间仅2天------相比全量微调（需80GB显存、数十天），成本大幅降低且性能无明显损失、、。
-
多维度幻觉消除机制：针对大模型"输出不存在软件库"的幻觉问题，创新结合三类文本相似度算法（编辑、token、序列），而非单一算法。例如对"scancode"（模型输出）与"scancodeio"（真实库），用Levenshtein算法修正；对"eventmesh-rabbitmq-connector"（输出）与"eventmesh-connector-rabbitmq"（真实库），用cosine算法捕捉语义相似性、。
-
覆盖多包管理器的全面评估：首次系统评估漏洞影响库识别方法在Maven、PyPI、Composer、NPM、Golang 5类主流包管理器上的效果，发现不同包管理器的识别难度差异，并针对性分析原因（如Maven库命名复杂导致识别难度高）、。
-
开源高质量标注数据集：公开含9260份中/英文漏洞报告及对应影响库的数据集，覆盖5类包管理器，解决该领域数据集老旧、来源单一的问题，为后续研究提供基础、。
研究方法和思路、实验方法
一、研究方法：三步骤核心流程
步骤1：漏洞报告数据抽取------"收集并筛选关键信息"
- 中文报告（CNNVD）：抽取"漏洞标题、漏洞描述、漏洞类型"三类信息。标题含厂商/组件线索（如"WWBN AVideo命令注入漏洞"直接提影响库），描述含漏洞原因/影响组件细节，类型暗示库功能（如"日志泄露"可能关联日志库）；剔除"发布时间、严重性"等无关信息以减少噪声、。
- 英文报告（NVD）：抽取"漏洞描述、参考链接、CPE配置"三类信息。参考链接补充外部新闻/修复方案，CPE配置提示影响平台（如"linuxfoundation:dex"）；这三类信息在过往研究中被证明对识别影响库最有价值、。
- 漏洞影响库标注：从学术文献（如Chen、Haryono等人的研究）、Snyk数据库、GitHub Advisory收集影响库，确保所有标注经安全专家评审，避免错误、。
步骤2：大模型指令微调------"让通用模型变专业"
- 选择基座模型：优先用Qwen1.5-14B，因其在MMLU、C-Eval等中英文理解数据集上领先同规模开源模型，且在实体识别、关系抽取等信息任务上表现优异、。
- 构建训练模板 ：基于Alpaca模板定制中/英文模板，核心包含三部分：
- 自我认知："你是软件供应链安全专家，熟悉软件漏洞与软件库知识"------让模型聚焦领域知识；
- 任务描述："分析漏洞信息，识别受影响的软件库"------明确任务目标；
- 输出要求："仅输出软件库名称，无需额外解释"------规范输出格式，便于后续处理、。
- LoRA微调实现 ：
- 初始化两个低秩矩阵A（输入维度=模型注意力层输入维度）和B（输出维度=模型注意力层输出维度），秩设为8；
- 冻结Qwen1.5-14B的所有参数，仅训练A和B；
- 模型输出计算：(h=W_0x + BAx)（(W_0)为模型原始参数，x为输入）；
- 用交叉熵损失函数更新A和B的参数，训练完成后将A、B与原模型组合使用、。
步骤3：幻觉消除------"修正模型的'胡言乱语'"
- 核心问题：大模型可能输出不存在的库（如将"thycotic-devops-secrets-vault"误为"thycotic-secrets-vault"）。
- 解决方案 ：构建真实软件库列表，用三类文本相似度算法将模型输出映射到列表中最相似的库：
- Levenshtein相似度：计算字符串转换的最少插入/删除/替换次数（如"scancode"→"scancodeio"需插入"io"，相似度高）；
- cosine相似度：将文本拆分为token，计算向量夹角余弦值（如"eventmesh-rabbitmq-connector"与"eventmesh-connector-rabbitmq"的token重合度高，语义相似）；
- 最长公共子字符串相似度：计算最长连续相同子串长度占比（如"pineapples"与"apple"的最长子串为"apple"，相似度0.5）；
- 最优组合：将cosine与最长公共子字符串算法结合，相互弥补单一算法的不足（如cosine捕捉语义，最长子串关注连续相似性）、。
二、实验方法：严谨设计确保结果可靠
1. 数据集设置
- 规模：9260份中文报告（CNNVD）、9260份英文报告（NVD），对应9260个CVE漏洞（1个CVE对应1份中文+1份英文报告）、；
- 包管理器分布：Maven（36%）、PyPI、Composer、NPM、Golang（合计92%）；
- 划分方式：按时间顺序拆分（前80%训练，后20%测试），符合真实场景中"用历史数据预测未来漏洞"的逻辑。
2. 基线方法选择
| 基线方法 | 适用场景 | 原因说明 |
|---|---|---|
| LightXML-BERT/RoBERTa/XLNet | 中/英文报告识别 | 现有主流XML模型，广泛用于漏洞影响库识别 |
| Chronos-w/o-DE | 中/英文报告识别 | 无数据增强的时间感知模型，适配"未来漏洞"场景 |
| Chronos | 英文报告识别 | 含参考链接数据增强，英文场景性能更优 |
3. 超参数设置
| 超参数 | 设定值 | 作用 |
|---|---|---|
| lora_r | 8 | 控制低秩矩阵的秩，平衡性能与复杂度 |
| lora_alpha | 16 | 调整学习率缩放因子，与lora_r比值为2 |
| max_length | 1024 | 覆盖绝大多数漏洞报告的长度（避免截断） |
| max_new_tokens | 256 | 满足漏洞影响库输出需求（多数仅1-3个） |
| batch_size | 128 | 提升梯度计算稳定性，加速模型收敛 |
| epoch | 30 | 确保模型充分收敛（避免欠拟合） |
| temperature | 1.0 | 保证模型生成内容的多样性 |
4. 评价指标
采用信息抽取任务常用的Precision@k、Recall@k、F1@k（k=1,2,3），其中F1为核心指标（综合查准率与召回率）：
- (P@k=\frac{1}{n}\sum_{v=1}^n \frac{|lib_{k(v)} \cap \hat{lib}{k(v)}|}{min(k,|\hat{lib}{k(v)}|)})（平均查准率）；
- (R@k=\frac{1}{n}\sum_{v=1}^n \frac{|lib_{k(v)} \cap \hat{lib}{k(v)}|}{|\hat{lib}{k(v)}|})（平均召回率）；
- (F1@k=2×\frac{P@k×R@k}{P@k+R@k})（综合指标）、。
主要成果和贡献
一、核心实验结果（按研究问题RQ划分）
| 研究问题（RQ） | 实验方法 | 核心结果 | 结论 |
|---|---|---|---|
| RQ1：中/英文单独识别效果 | Qwen1.5-14B/Vicuna-13B + 不同相似度算法 | 1. Qwen1.5-14B表现优于Vicuna-13B； 2. 中文最优F1=0.78（Qwen+cosine+Levenshtein）； 3. 英文最优F1=0.82（Qwen+cosine+最长公共子字符串） | 大模型+文本相似度的方法优于传统XML模型，Qwen1.5-14B的语言理解能力更强 |
| RQ2：中/英文互补识别效果 | 最优3种方法（RQ1结果）+ 中/英文报告结合 | 1. 互补后平均F1达0.85； 2. 较单一中文报告提升3.7%，较单一英文报告提升3.5% | 多来源信息互补可填补单一报告的信息缺口，显著提升准确性 |
| RQ3：多包管理器识别效果 | 最优方法（Qwen+cosine+最长公共子字符串） | 1. PyPI/Composer/NPM/Golang F1>0.85； 2. Maven F1=0.71（虽最低但仍优于基线） | 方法在多数包管理器上表现优异，Maven因命名复杂识别难度最高 |
二、核心贡献
-
拓展数据来源：首次将中文CNNVD报告纳入漏洞影响库识别，打破"仅依赖NVD英文报告"的局限，使安全防护覆盖中英文场景------比如对CVE-2023-25313，英文报告仅提"AVideo"，中文报告明确"WWBN AVideo"，互补后可精准识别为"WWBN/AVideo"、。
-
提出高效识别方法：
- 相比传统XML模型（如LightXML），F1提升4%-8%；
- 相比全量微调，LoRA技术降低99.95%的参数量，硬件成本大幅降低；
- 幻觉消除使F1从0.68提升至0.85，解决大模型可靠性问题、、。
-
开源关键资源：公开含9260份中/英文报告及标注的数据集（地址：https://figshare.com/s/cbd35613e0e524614e1e），覆盖5类包管理器，解决该领域数据集稀缺、老旧的问题，为后续研究提供基础、。
-
揭示包管理器差异：首次系统分析不同包管理器的识别难度，发现"命名复杂度""相似库数量"是核心影响因素------为后续针对特定包管理器（如Maven）的优化提供方向、。
关键问题（问答形式）
Q1：现有漏洞影响库识别方法的核心痛点是什么？该研究如何针对性解决？
A1：核心痛点有三：①仅聚焦NVD英文报告，忽略CNNVD中文报告；②未关注Maven/PyPI等包管理器的识别差异；③大模型存在幻觉问题（输出不存在的库）。
解决方式：①用中/英文报告互补实现输入增强；②在5类包管理器上评估并分析差异；③用三类文本相似度算法消除幻觉、、。
Q2：为什么选择Qwen1.5-14B作为基座模型？LoRA微调的优势是什么？
A2：选Qwen1.5-14B的原因：①在MMLU、C-Eval等中英文理解数据集上领先同规模开源模型；②在实体识别、关系抽取等信息任务上表现优异，适合漏洞报告分析、。
LoRA微调的优势：①参数成本低（仅训练0.05%的参数）；②硬件要求低（1张A100-40GB即可运行）；③训练速度快（仅需2天）；④性能损失小（与全量微调效果接近）、。
Q3：中/英文报告互补为何能提升识别效果？能否举个具体案例？
A3：原因是单一报告存在信息缺口------中文报告可能补充英文报告的细节，反之亦然。
案例：CVE-2023-22491的漏洞影响库是NPM的"gatsby-transformer-remark"，中文报告仅提"gatsby"，英文报告明确"gatsby-transformer-remark插件"，两者结合可精准识别；若仅用中文报告，会遗漏关键子组件信息、。
Q4：为什么Maven包管理器的识别效果低于其他？有什么优化思路？
A4：MMLU识别效果差的核心原因：①命名复杂（如"org.apache.felix.healthcheck.webconsoleplugin"含组织、项目、模块、功能四层信息）；②相似库多（如"wiremock-standalone"与"wiremock-jre8-standalone"仅差"jre8"）；③部分漏洞影响子包但报告仅提主包、。
优化思路：将大模型初判结果与Maven社区安全信息结合（如Maven库关联的CVE漏洞、Spring等组织的安全公告），筛选相似库并二次确认。
Q5：该研究的数据集有什么特点？为什么说它能支持后续研究？
A5：数据集特点：①规模大（9260份中/英文报告）；②来源权威（NVD/CNNVD+学术文献/Snyk/GitHub Advisory）；③标注准确（经安全专家评审）；④覆盖广（5类主流包管理器）；⑤时间新（截止2023年底，弥补现有数据集老旧问题）、。
支持后续研究的原因：该领域此前数据集仅含NVD英文报告（截止2019年），此数据集填补了"中文报告""新漏洞""多包管理器"的空白，可用于验证新方法在多场景下的效果、。
总结
该研究针对现有漏洞影响库识别方法"数据来源单一、包管理器适配不足、大模型幻觉"三大痛点，提出基于Qwen1.5-14B的多来源识别方法：通过中/英文报告互补实现输入增强，用LoRA轻量级微调让模型适配特定任务，再用文本相似度消除幻觉。实验以9260份中/英文报告为数据集，证明该方法在中文、英文报告上的F1较基线分别提升4%和8%，中/英文互补时F1达0.85，在PyPI、Composer等多数包管理器上表现优异。同时，研究公开高质量标注数据集，为后续软件供应链安全研究提供关键资源。
局限性方面，该方法目前仅覆盖NVD/CNNVD数据源，且Maven库识别效果仍有提升空间；未来可扩展Rapid7、X-Force等数据源，升级基座模型，并结合Maven社区信息优化识别逻辑、、。