文章总结： 本研究介绍了PatchDiff-AI，一个基于大型语言模型的多智能体系统，可自动分析微软补丁星期二更新的漏洞根本原因。系统通过分而治之和情境丰富化策略，在识别正确可执行文件方面成功率达88.6%，识别正确易受攻击函数达83.9%，找到正确根本原因达71.4%。当提供正确代码块时，成功率高达96%。该系统可帮助安全团队快速分析漏洞用于防御或攻击目的，平均每份报告成本约0.14美元。案例研究展示了系统在分析NTFS驱动程序越界读取漏洞和CLFS驱动程序缓冲区溢出等方面的应用，但也指出了在处理大规模代码修改和多漏洞组件时的局限性。 综合评分： 85 文章分类： 漏洞分析,AI安全,二进制安全,WEB安全,红队
【好文翻译】Patch Wednesday：基于大语言模型的根因分析方法
Maor Dahan
安全视安
2025年12月14日 22:01 中国台湾
声明：该公众号分享的安全工具和项目均来源于网络，仅供安全研究与学习之用，如用于其他用途，由使用者承担全部法律及连带责任，与工具作者和本公众号无关。
摘要
- 在这项研究中，我们探讨了使用大型语言模型来查找已修补漏洞的根本原因。
- 我们开发了一个名为 PatchDiff-AI 的多智能体系统，它可以自主分析“补丁星期二”漏洞的根本原因，并生成详细的报告。
- 这种分析方法可以帮助安全团队几乎立即分析漏洞，用于防御或攻击目的。
- 通过采用多种策略，我们能够微调系统，在全自动报告生成方面实现超过 80% 的成功率，包括攻击向量分析和触发流程。
周二补丁日 → 周三漏洞利用日
微软的常规更新周期以“补丁星期二”为核心——每月第二个星期二，微软会发布一份包含所有CVE漏洞及其对应修复程序的完整列表。这些修复程序以Microsoft独立更新（MSU）文件的形式发布，这种打包格式通过修补或替换核心系统文件来应用更新。
补丁星期二之后通常会紧接着所谓的“漏洞利用星期三”，攻击者会争分夺秒地寻找微软已发布补丁的漏洞。通过对更新后的二进制文件进行二进制差异比较，攻击者可以快速定位潜在的安全问题，并在组织机构广泛部署补丁之前尝试利用这些漏洞。
同样，防御者经常急于分析这些补丁，以了解漏洞的根本原因，从而制定检测和缓解措施。
当前补丁差异比较的状态
如今，补丁差异比较是一个繁琐的过程(https://googleprojectzero.blogspot.com/2020/04/tfw-you-get-really-excited-you-patch.html)。为了成功识别出存在漏洞的代码段，研究人员需要：
- 确定疑似包含漏洞的文件
- 执行二进制差异比较以识别更改
- 将安全相关的更改与其他例行代码更新隔离开来
- 分析可疑部件并了解根本原因
- 动态检查呼叫流程，以发现潜在的触发途径
- 评估补丁修复的完成情况
这些步骤有时可能需要数周时间才能完成，而每月同时发布的漏洞数量之多，更使这个问题雪上加霜。
我们着手寻找一种更好的方法——一种能够让研究人员快速分析已修补漏洞并了解其根本原因的方法。
使用LLM进行斑块差异分析
大型语言模型（LLM）(https://www.akamai.com/glossary/what-are-llms)能够基于训练数据和用户输入，在统计学上生成合理且准确的信息。但它也存在一些局限性，例如上下文窗口有限（这会影响其数据处理能力和运行成本）以及臭名昭著的模型幻觉。
多年来，已有大量论文探讨了LLM在安全领域漏洞评估方面的贡献。如今，LLM在分析闭源软件时似乎表现不佳，但在分析开源软件和(https://googleprojectzero.blogspot.com/2024/10/from-naptime-to-big-sleep.html)Web漏洞(https://arxiv.org/abs/2406.01637)时则表现更佳，因为它们的共同点在于都存在人类可读的代码。
OpenAI 的 Aardvark(https://openai.com/index/introducing-aardvark/)和Claude Code 安全审查工具(https://claude.com/blog/automate-security-reviews-with-claude-code)仍然依赖于可读源代码。另一方面，谷歌 Project Zero 的Big Sleep(https://googleprojectzero.blogspot.com/2024/10/from-naptime-to-big-sleep.html)旨在发现 0day 漏洞(https://www.akamai.com/glossary/what-is-zero-day-attack)。这两种方法都不分析闭源二进制文件。
介绍 PatchDiff-AI
我们的研究采用了一种不同的方法，即使用 LLM 对安全补丁进行根本原因分析 (RCA)。我们的理论（似乎已得到验证）是，二进制“diff”提供的额外上下文信息能够显著增强 LLM 理解复杂底层代码的能力。
为此，我们开发了一个多智能体系统，可以自动分析特定平台上的 Microsoft 知识库 (KB) 更新（图 1）。我们称之为 PatchDiff-AI。
图 1：我们的多智能体系统 atchDiff-AI 的示意图
PatchDiff-AI 定义
- Windows 内部组件代理——该代理使用基于检索增强生成 (RAG) 管道的分析方法，并借助包含 Windows 二进制文件及其功能元数据的向量存储库进行分析。这使得代理能够显著缩小分析范围，专注于最相关的组件。
- 逆向工程代理——该代理使用高级逆向工程工具对相关文件进行分析和差异比较。它会将找到的工件添加到整体上下文中，供其他代理使用。
- 漏洞研究代理— 该代理通过收集上下文中存在的所有工件和其他信息来协调分析，并生成一致的报告。
方法论
由于上下文窗口的限制和幻觉，为了尽可能有效地使用 LLM，提供相关且简洁的上下文至关重要，这样才能在隔离易受攻击的代码组件时保持较高的准确性，同时降低运营成本。
分而治之
我们实施过程中一个关键的细节是将分析分解成几个更小、更集中的任务，这些任务最终作为代理运行：
-
获取有关 CVE 的信息以创建配置文件
-
下载相关更新并将增量更新应用到基础版本文件。
-
创建一个 Windows 内核 AI 代理，利用漏洞元数据隔离相关文件。
-
创建一个能够进行逆向工程的人工智能代理，该代理可以：
-
反汇编并应用符号，然后导出以进行二进制差异比较。
-
关联二进制文件，识别变更和调用流程。
-
找出存在漏洞的代码块
-
创建一个漏洞研究人工智能代理，使其遍历所有可能的漏洞路径，进行交叉关联分析，从而找到最佳解决方案。
这种划分的主要优势之一是，它允许我们针对每种任务类型使用特定的模型；OpenAI o4-mini 擅长丰富文件元数据，而 OpenAI o3 则用于对疑似存在漏洞的代码进行最终的深入分析。
选择合适的模型来完成这项任务有两方面的好处——首先是提高了准确性，其次是降低了成本。
情境丰富化
逻辑记忆模块（LLM）是一种能够“记忆”大量信息的机器。通过提示调用LLM，它会根据提示内容调整信息，提供最相关的信息。
我们向LLM提供的任何关于已修复漏洞的信息都有助于生成更准确的响应，并提高定位漏洞代码的几率。然而，关于漏洞的信息如果含糊不清，则可能导致糟糕的结果，甚至毫无结果。
在分析过程中，利用漏洞元数据丰富上下文至关重要。为了实现这一点，我们向 LLM 提供了知识库描述、系统文件描述和二进制差异数据。这种方法使我们能够减少需要分析的变更数量，从而缩短上下文长度并减少 LLM 的迭代次数。
结果
为了评估我们的框架，我们检验了模型正确识别以下问题的能力：
- 与CVE(https://www.akamai.com/blog/security/cves-what-they-are-ways-to-mitigate-their-impact)对应的易受攻击的可执行文件
- 可执行文件中存在漏洞的函数。
- 找出漏洞的根本原因并正确解释它。
基于这些参数，我们分析了 Windows 11 24H2 的最近三个“周二补丁日”版本。运行我们的工具并生成自动报告后，我们手动检查了选定的结果，并确定了最终模型响应的准确性。
在完善上下文并针对不同任务调整各种模型后，我们最终取得了以下结果：
- 在 88.6% 的情况下，识别出了针对相关 CVE 漏洞已打补丁的正确可执行文件。
- 83.9% 的情况下找到了正确的易受攻击函数
- 在 71.4% 的情况下，找到了漏洞的正确根本原因
如果我们排除因上下文信息不足导致的报告生成失败（例如静态分析工具崩溃或无法应用增量补丁），我们就可以估算模型在获得正确代码块时的成功率。在这种情况下，当上下文中提供了正确的代码块时，LLM 的成功率约为 96%（图 2）。
图 2：选定 CVE 报告的估结果
请提供一份CVE报告。摇匀，不要搅拌。
因此，我们遇到了一些有趣的用例，希望与大家分享并进行深入研究。每个用例的报告结构都相同：
-
构成该报告的 CVE 详细信息
-
RCA——报告的核心
-
补丁前后的代码片段
-
自上而下地概述了漏洞可能如何被触发
-
补丁的重点描述
-
可以利用该漏洞的攻击途径
-
漏洞造成的清晰、详细的影响
此外，每份报告的最后一部分都会尝试质疑补丁的有效性，并审查可能的绕过方法。
案例研究
在接下来的四个案例研究中，我们将探讨一些有趣的案例，以突出我们的框架在哪些方面表现出色，在哪些方面存在不足，以及在哪些方面完全失败。
案例一：安装与破坏
我们分析的漏洞之一是CVE-2025-24991(https://github.com/akamai/patchdiff-ai/blob/d508b19682f76d26edcdc765dd8cdbf8de7987ad/reports/2025-mar-12390-windows_11_24H2_x64/CVE-2025-24991_ntfs.sys.txt)，根据微软安全响应中心 (MSRC) 的说法，这是一个“ Windows NTFS 中的越界读取漏洞，允许授权攻击者在本地泄露信息”。常见问题解答中也提到：“攻击者可以诱骗易受攻击系统上的本地用户挂载一个特制的 VHD，从而触发该漏洞。 ”
现在，该漏洞显然与 NTFS 组件有关，这肯定意味着ntfs.sys参与其中。
另一个线索是，该漏洞是由挂载的 VHD 文件触发的。手动分析补丁可能需要几个小时，但使用PatchDiff-AI工具只需几分钟即可完成。更重要的是，即使没有明显的根本原因可循，我们的工具也能像本例一样高效地解决问题。
在这种情况下，系统声称已在 KB5053598 更新中对该文件所做的 17 项最相关的更改中找到了根本原因。完整报告可在我们的 GitHub代码库中找到，以下是我们的评估过程。
首先，我们的工具输出相关组件（即ntfs.sys）和相关函数ReadRestartTable()。它还输出一段简短的解释，说明该逻辑的设计目的（图 3）。
Microsoft Windows NTFS driver (ntfs.sys)
Affected routines: ReadRestartTable() and its consumer
InitializeRestartState().
3：ntfs.sys 功能逻辑说明
接下来，我们来看与 CWE 索引相关的漏洞类别，在本例中为CWE-125：越界读取。这将有助于我们了解 LLM 在生成此报告时正在查找的漏洞类型。
图 4 是我们工具的根本原因分析 (RCA) 的实际输出结果。它清晰地概述了出错的原因，并精确地指出了问题所在。
ReadRestartTable() processes a restart area that was previously
retrieved from the NTFS transaction log (LFS). The function first
validates the outer log record with NtfsCheckLogRecord(), then calls
NtfsCheckRestartTable() to validate the embedded restart table.
Buggy offset computation (pre-patch)
1. v9 = *(QWORD *)(a4 +72) // ptr to restart area
2. offset_to_tbl = *(WORD *)(v9 +4) // value comes from log
3. NtfsCheckRestartTable(v9 + offset_to_tbl, size, cookie)
The code trusts the 16-bit field at offset +4 of the restart area to
locate the first restart table. If an attacker supplies a crafted
restart record in which this field is smaller than the actual header
size, NtfsCheckRestartTable() will be invoked on a memory range that
starts inside the header instead of at the real table. Because the
size argument (derived from *(DWORD *)(a4 +64)) is unchanged, the
routine reads past the caller-supplied buffer, disclosing adjacent
kernel memory.
Additional consequence: the return value (pointer returned to the
caller) is likewise computed from this untrusted field, so callers
such as InitializeRestartState() may later copy the out-of-bounds data
into pageable pool that is accessible to user mode via other
interfaces.
Patched behaviour
The patch discards the header-supplied offset. Instead it derives the
correct header length from the number of client entries:
hdr_len = (clients <=1) ? 40 : (8 * clients +32);
NtfsCheckRestartTable(v10 + hdr_len, ...);
If the validation fails, execution now jumps to new corruption
handling code that raises STATUS_DISK_CORRUPT_ERROR before any out-of-
bounds access can occur.
4：PatchDiff-AI 的 RCA 输出
使用 IDA 和 BinDiff 对这些结果进行检查后发现，这确实是正确的位置。我们之所以知道这一点，是因为微软使用了功能标志来选择不修复此漏洞；这样，如果出现意外情况，就可以撤销修复（图 5）。
图 5：微软功能标志（绿色方）、固定路径（蓝色方块）和易受攻击的路径（红色方块）
在报告中，我们可以找到反编译后的函数中存在漏洞部分的代码片段，并查看存在漏洞的代码（图 6）。
// pre-patch (simplified)
WORDoffset=*(WORD*)(RestartArea+4);
if (!NtfsCheckRestartTable(RestartArea+offset,
Total-offset, Cookie))
NtfsRaiseStatus(...);
// post-patch
WORDclients=*(WORD*)(RestartArea+14);
ULONGhdrLen= (clients<=1) ?40 : (8*clients+32);
if (!NtfsCheckRestartTable(RestartArea+hdrLen,
Total-*(WORD*)(RestartArea+4),
Cookie))
NtfsRaiseStatus(...);
6：反编译后的函数易受攻击部分
该报告的亮点之一是自上而下的触发部分。在这一部分，LLM 提出了触发漏洞可能需要采取的步骤（如适用），甚至还提供了实际的利用细节（图 7）。
1. User mounts or accesses a volume containing a malicious $LogFile.
2. NtfsMountVolume() → NtfsRestartVolume() → InitializeRestartState().
3. InitializeRestartState() reads the first restart area and calls
ReadRestartTable().
4. ReadRestartTable() uses the untrusted 16-bit offset to pass an
out-of-range buffer to NtfsCheckRestartTable(), which performs the
actual out-of-bounds memory read.
5. The leaked data is later copied back into attacker-controlled disk
structures or user-mapped memory, allowing disclosure.
7：LLM 关于如何利用该功能的建议
结合后续提示，我们的工具可以进一步分析反编译代码，发现更多信息，甚至可以提出最小的概念验证 (PoC)。
攻击向量部分也提供了另一个有用的见解，它概述了漏洞利用过程。它能帮助我们了解漏洞的范围以及攻击者利用漏洞所需的条件（图 8）。
Local attacker crafts an NTFS image (or directly edits $LogFile on an
existing volume) so that the Restart Area field at offset +4 contains
an undersized value. Mounting or otherwise activating the volume on a
vulnerable system triggers the OOB read in kernel context.
8：LLM 的攻击向量部分输出
其余章节将更全面地描述补丁本身及其对系统的安全影响。然而，在最后一节中，我们要求LLM尝试对该补丁进行测试，看看能否快速发现修复程序中存在的其他漏洞。在这种情况下，LLM评估认为该补丁是完整的：“所有错误路径现在都会在任何潜在的越界访问之前抛出。 ”
案例二：当群星汇聚之时
对于专注于检测或缓解的团队而言，将报告与自动生成的IDA数据库和BinDiff输出进行比对，通常就足够了。然而，我们的方法更进一步，并且在某些情况下，由于系统可以超越分析层面，实际生成可用的漏洞利用程序，因此对于攻击目的也可能非常有用。
例如，CVE-2025-32713(https://github.com/akamai/patchdiff-ai/blob/d508b19682f76d26edcdc765dd8cdbf8de7987ad/reports/2025-jun-12390-windows_11_24H2_x64/CVE-2025-32713_clfs.sys.txt)漏洞已在 2025 年 6 月的更新 (KB5060842) 中修复，该漏洞被描述为：“ Windows 通用日志文件系统驱动程序中的基于堆的缓冲区溢出允许授权攻击者在本地提升权限。” 大约两分钟后，我们的工具生成了一份报告，将问题追溯到CClfsLogFcbPhysical::ReadLogBlock()。
目前，应对剥削挑战有两种方法。
- 手动反转函数及其调用者，直至用户模式调用。
- 让LLM为我们代劳，自主构建概念验证（PoC）。
然而，通常情况下，还有第三种选择：混合方法。让LLM（代码语言管理专家）承担逆向工程的繁重工作，而您则负责确定间接代码流程并解析二进制文件逻辑部分之间的复杂连接。这将使LLM能够得出更好的结果。
利用这种方法，我们仅用了几个小时就实现了蓝屏死机 (BSOD) 漏洞利用（图 9）。
图 9：CVE-2025-3713 PoC 执行期间的蓝屏死机
对漏洞触发流程的理解始于对根本原因分析 (RCA) 部分中描述的漏洞代码的评估。在意识到该补丁试图修复一个安全缺陷后，我们分析了直至输入/输出控制 (IOCTL) 0x80076832 的调用流程。
在寻找用户模式对应物时，我们发现了两个候选对象，因为clfsw32.dll导出了**ReadLogRecord函数，并提供了调用此 IOCTL 的直接路径（图 10）。
图 10：调用流程图，从用户式导出的方法开始，一直到内核驱动程序（使用 IOCTL 调用）
在每个步骤中，我们都评估了LLM如何协助逆向工程和逻辑分析，因为它是基于部分知识进行训练的。图11展示了它如何满足v4的条件要求，即我们提供的缓冲区大小。
图 11：使用 LLM 分析验证检查
尽管我们看到LLM发现了一些非常优秀的漏洞，但也存在一些结果具有误导性的情况。以CVE-2025-32713为例，在其一份回复中，我们的报告包含了如图12所示的引述。
“crafts the log header so that the page size (v48) exceeds the supplied buffer”
12：LLM 的误导性结果输出
这个回复令人困惑，最终反而让我们偏离了理解如何触发漏洞代码的方向。事实上，它把我们引向了一条完全无关的研究路径（我们试图篡改 已经采取了缓解措施的.blf 文件结构）。之后，我们创建了每个扇区物理字节数和逻辑字节数各不相同的虚拟磁盘，并通过调试分析了它们的行为。
可以说，LLM完成了大部分工作，但它需要经验丰富的研究人员的密切监督。LLM 是辅助人类的工具，前提是辅助方式正确。
该模型偶尔会偏离正轨，需要人工指导才能使其保持正确方向。尽管如此，结果本身就足以说明一切：LLM 正确识别了存在漏洞的代码，准确地追踪了调用流程，并解释了 v27 的错误赋值如何导致 CcCopyRead()函数溢出。
案例三：大海捞针
有些情况下，您需要谨慎对待 LLM 的输出。幻觉并非 LLM 的唯一风险；各种 LLM 界面都反复强调这一点（例如，“ ChatGPT 可能会出错。请查看重要信息。”）。
同样的谨慎也适用于此，尽管系统会尝试验证其输入和输出，并检查多条路径以找出根本原因。但有时几乎不可能做到这一点，因为情况过于宽泛和模糊。
我们以5 月份 KB5058411 更新中的CVE-2025-29974为例。MSRC 关于此漏洞的信息页面指出：“ Windows 内核中的整数下溢（回绕）允许未经授权的攻击者通过相邻网络泄露信息*”，这可能有些晦涩难懂。
接下来，我们看到MSRC页面提到攻击者必须在附近；也就是说，攻击者必须在接收无线电传输的范围内。这显然是在讨论通过物理隔离方式窃取信息。然而，不清楚具体是如何窃取的，或者使用了什么硬件。这种上下文信息的缺失降低了获得有效报告的可能性（如果有的话）。
关于 CVE-2025-29974，我们运行了工具，并收到一份关于两个未命名函数的报告：sub_1408E6D3C和sub_1408FAD58。为了方便起见，我们将它们分别称为primary()和secondary()。图 13 是这两个函数的 BinDiff 视图，很容易看出它们差异很大……在我看来，差异太大了。
图 13：使用 PatchDiff-AI 自动创建的 BinDiff 变更视图
仔细检查后，我们发现正确的函数是sub_1408E7738，这是一个完全不同的方法，位于不同的地址。造成这种混淆的主要原因是ntoskrnl.exe在此次更新中被大幅修改。共有 3791 个函数被修改，导致找到正确修改前后对应函数的概率急剧下降。
该案例报告提供的置信度为 0.2，表明报告找到正确漏洞的概率仅为 20%。这一置信度，加上大量的代码块修改，都与糟糕的检测结果相符。
案例四：过于脆弱
有些情况下，组件可能存在多个漏洞，而更新可以修复这些漏洞。这种情况并不罕见，因为单个逻辑缺陷可能包含一系列不同类别的漏洞。
如果我们查看 KB5055523（2025 年 4 月）更新，会发现一组漏洞，编号分别为 CVE-2025-24058、CVE-2025-24060、CVE-2025-24062、CVE-2025-24073 和 CVE-2025-24074（图 14）。所有这些漏洞都与桌面窗口管理器 (DWM)相关，并且都是由“ CWE-20：输入验证不当”导致的，这使得它们在模型中难以区分和明确。
图 14：2025 年 4 月更新的部分错误列表
使用 LLM 算法有利有弊。所有算法的共同点在于成本因素。即使所需的上下文不匹配，LLM 算法也会尝试在一次迭代中完成任务。为了获得更准确的结果，我们必须通过启发式方法评估结果，并优化上下文，以便生成更好的变异模型。
我们利用2025 年 4 月更新漏洞的报告来评估此类用例的结果。通过比较根本原因和附加信息，我们能够通过分析（见表）了解多个漏洞如何影响 LLM。
| CVE | 主要故障功能 | 漏洞类 | 根本原因 | | — | — | — | — | | CVE-2025-24074 | COcclusionContext::PreSubgraphCDDisplaySwapChain::PresentMPOCLegacySwapChain::Present | 不正确的输入验证导致堆内存损坏 /动态数组增长期间发生整数溢出（CWE-20，导致 CWE-787）。 | 同样的 PreSubgraph 整数回绕会触发遮挡信息缓冲区溢出。 | | CVE-2025-24073 | COcclusionContext::PreSubgraph | 由于不当操作导致的基于堆的缓冲区溢出/整数溢出输入验证（CWE-20，会导致内存损坏） | 同样的 PreSubgraph 整数回绕会触发遮挡信息缓冲区溢出。 | | CVE-2025-24060 | COcclusionContext::PreSubgraphCOverlayContext::ComputeOverlayConfiguration | 输入/边界验证不当导致堆越界写入 | 同样的 PreSubgraph 整数溢出会触发遮挡信息缓冲区溢出，以及另一次溢出。 | | CVE-2025-24058（dwmcorei.dll） | CLocalAppRenderTarget::EnsureRenderSurface | 释放后使用/类型混淆是由于传递已释放的对象而导致的。指针作为隐式 this 指针（CWE-416、CWE-843） | 已释放的 CD3DDevice 指针被重用作 CDeviceManager。 | | CVE-2025-24058（dwmcore.dll） | CLegacyRenderTarget::CollectOverlayCandidatesCOverlayContext::ComputeOverlayConfiguration | 由于输入验证不当而导致的基于堆的缓冲区溢出呼叫者提供的列表长度（CWE-20，导致 CWE-122） | 使用 CollectOverlayCandidates 的堆溢出 | | CVE-2025-24062 | CCompositionSurfaceBitmap::AddOcclusionInformationCSurfaceBrush::AddOcclusionInformation | 指针截断/输入验证不当导致使用后错误权限提升（CWE-20，与 CWE-704 相关） | 参数类型扩展为 __int64；新增 IsOverlayCandidateCollectionEnabled() 方法 |
通过LLM确定了多个漏洞及其根本原因分析(RCA)。
该表格仅反映了报告的内容。对 2025 年 4 月更新漏洞的评估发现，CVE-2025-24074、CVE-2025-24073 和 CVE-2025-24060 存在重复。这三个漏洞均涉及相同的功能，仅有细微的更改或新增。
CVE-2025-24058 ( dwmcore.dll ) 似乎与 CVE-2025-24060 对ComputeOverlayConfiguration的考量有所重叠。然而，CVE-2025-24058 ( dwmcorei.dll ) 和 CVE-2025-24062 似乎针对的是完全不同的根本原因。
由于LLM并非确定性系统，即使输入完全相同，输出也可能不同。我们可以观察到，输入环境的任何细微变化都会影响LLM的输出，并导致两种不同的报告。
价格标签
PatchDiff-AI 基于监督式多智能体架构，采用不同的 LLM 模型，在保持高精度的同时降低成本。使用 OpenAI 模型生成一份报告的成本分析显示，最高成本为1.43 美元。
实际上，我们根据 3 月、4 月和 5 月的更新生成了 131 份报告，这些报告仅针对 Windows 11 24H2 x64 系统。平均每份报告的成本约为0.14 美元。考虑到每天（甚至每小时）都需要应对大量漏洞，这些成本在规模扩大后可能相当可观。
当启用完全自主功能时，例如对 Windows 内部进行扩展改进和漏洞研究代理，价格的计算可以设定上限；但是，由于系统的不确定性，它不可能有一个平均值。
结论
人工智能，特别是生命周期管理（LLM），在网络安全领域的应用前景十分光明。LLM 可以轻松地将复杂但又繁琐的方法论流程简化为简单的工作流程，并可集成到各个安全团队的现有流程中。
我们的研究表明，对漏洞进行全自动根本原因分析不仅是可能的，而且是切实可行的——具有有意义的准确性和合理的成本。
通过将问题分解为微任务，并将其调整为结合了 Windows 内部逻辑推理、逆向工程工作流程和漏洞特定分析的专用多智能体架构，我们使 LLM 能够克服其传统局限性。这种方法（以及配套工具 PatchDiff-AI）也可推广到其他产品和平台。
借助我们的系统，安全团队可以创建全面的检测机制，有效缓解漏洞，并为系统创建渗透测试和回归测试。此外，我们的系统还可以帮助缩短已知漏洞的触发流程，从而能够对存在漏洞的共享代码库进行更深入的研究和变种发现。
查看原文：《【好文翻译】Patch Wednesday：基于大语言模型的根因分析方法》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论