Page 57 - 《软件学报》2026年第6期

2376 软件学报 2026 年第 37 卷第 6 期

一个被检测到的缺陷集合 D found , 并使其尽可能地逼近真实存在的缺陷集 D true .
2.2 核心挑战
结合上述定义, 引言中所述的挑战 1 和挑战 2 可被更精确地做以下阐述.
挑战 1: 缺乏设计安全知识导致的高漏报率. 该挑战源于从非结构化设计文档 T doc 到结构化设计知识 K 的转

化缺失. 现有早期检测方法 f 通常只将 RTL 设计 D 作为输入, 其分析范式无法有效融入针对特定设计的关键资产
B 或安全属性 . 因此, 检测工具只能依赖一组通用的、与特定设计意图无关的规则进行分析. 这导
A、信任边界 S
致大量需要结合具体设计知识才能判定的真实安全缺陷 d 被遗漏, 即 D found 集合远小于 D true 集合, 从而产生高漏报率.
挑战 2: 缺乏对代码语义的深层理解导致的高误报率. 该挑战源于检测方法对 RTL 设计 D 的分析停留在语法

或浅层语义层面. 现有方法在判断一段代码 C 是否构成安全缺陷 d 时, 通常未能充分考虑其在整个设计中的跨模
I 和数据流上下文. 因此, 大量在特定功能或协议上下文中完全合规的实现, 会因其代码结构触发了通
块调用关系
用的、与上下文无关的启发式规则, 而被错误地标记为缺陷. 这导致 D found 集合中包含大量并非存在于 D true 中的
伪缺陷, 从而产生高误报率.
3 基于多智能体协同的硬件安全缺陷早期检测方法

针对上述挑战, 本文设计了一种基于大语言模型多智能体协同的硬件安全缺陷早期检测方法 MARC. MARC
核心思想在于模拟硬件安全专家团队的工作模式, 通过关注点分离原则将复杂的检测任务分解, 并设计了 4 类职
能明确、分工协作的智能体, 以流水线式的架构系统性地完成从设计理解、缺陷检测到根因验证的全过程, 方法
整体框架如图 1 所示.

设计文档 文档 安全设计
获取工具
规范图谱
向量数据库 LLM 模块 LLM 代码安全
安全建模 缺陷推理
安全规范 安全规范工具 待测RTL代码
文档分析智能体 缺陷检测智能体

待测代码 抽象语法树 依赖关系图 潜在漏洞 LLM 断言生成 断言验证 安全威胁
待测RTL代码 报告
依赖分析智能体 缺陷确认智能体
图 1 基于多智能体协同的硬件安全缺陷早期检测方法

3.1 依赖分析智能体
由于单一硬件模块的安全性会受到其在整个系统中的模块间交互关系的影响, 因此需要从更全局的视角分析
其交互边界并评估由此引入的潜在安全风险. 因此, 本方法设计了依赖分析智能体, 旨在自动化地构建并解析模块
间的依赖关系图, 在对模块内部代码分析时补充系统级的信息.
该智能体基于对项目中 RTL 源文件进行抽象语法树分析实现依赖关系分析. 具体的, 本文通过遍历 AST 中
实例列表的所有节点, 识别出每个父模块所实例化的所有子模块. 基于此信息构建出一个有向图, 其中节点代表硬
件模块, 有向边代表实例化或依赖的关系. 同时, 该流程也生成一个逆向依赖图, 用于快速追溯一个底层模块被哪
些上游模块所调用, 为理解影响传播路径提供了基础.
为了使构建的依赖图能够被大模型语义化的理解, 本文中的文档分析智能体在接收此依赖图后, 其内部提示