原文标题：Generating API Parameter Security Rules with LLM for API Misuse Detection
原文作者：Jinghua Liu , Yi Yang, Kai Chen, Miaoqian Lin发表会议：NDSS Symposium 2025笔记作者：龙函城主编：黄诚@安全学术圈
研究概述
随着现代软件开发对第三方库 API 的广泛依赖，开发者在调用库函数时不仅要保证功能实现正确，还需要遵循相应的安全使用规范，尤其是参数层面的安全约束。论文将研究重点放在 API Parameter Security Rules（APSRs） 上。APSRs 是 API 安全规则中的一种常见类型，主要用于描述参数取值、参数状态以及相关操作应满足的安全条件。若违反这些规则，就可能引发空指针解引用、内存破坏、拒绝服务等安全问题。作者指出，在已有 API 误用案例中，约71%与 APSRs 违规直接相关，这说明 APSRs 是 API 安全分析中的关键内容。
然而，APSR 的构建并不容易。现有方法通常依赖 API 文档、调用代码模式或传统静态分析来提取规则，但这些方法普遍存在文档不完整、调用样本有限、分析规则依赖人工设计等问题，因此容易遗漏重要约束。相比之下，API 源码更接近真实实现过程，而大语言模型又具备较强的代码理解和文本生成能力，因此论文尝试利用 LLM 直接从 API 源码中自动生成 APSRs，以进一步支持 API 误用检测。
不过，作者进一步发现，直接使用 LLM 生成 APSRs 效果并不好。一方面，LLM 可能会因为幻觉生成错误规则；另一方面，模型也容易输出过于宽泛、模糊的规则。论文的实验表明，若直接依赖 LLM 生成 APSRs，其精度只有11.9%，说明这一问题十分突出。
针对上述问题，本文提出 GPTAid 框架，用于自动生成准确且具体的 API 参数安全规则，并进一步将这些规则应用到 API 误用检测中。GPTAid 的核心思想不是直接相信 LLM 的输出，而是构建一个“生成—验证—细化—检测”的闭环流程，其框架如图1所示。
图 1 GPTAid 框架整体流程
如图1所示，GPTAid 整体包括四个阶段：首先基于 API 源码生成原始 APSRs；随后围绕每条规则生成能够正确调用 API 的 Right Code 和故意违反规则的 Violation Code，并通过运行时错误反馈验证规则是否正确；接着，系统利用代码差分分析，将原始规则进一步细化为更具体、更清晰的 APSRs；最后，再把这些规则转换为检测逻辑，用于在真实应用中发现 API 误用问题。
该方法的关键在于两点。第一，论文提出了执行反馈校验机制，即通过执行违规代码并观察运行时错误，过滤掉那些看似合理但实际上不正确的规则。第二，论文提出了代码差分细化机制，通过比较正确代码和违规代码之间的关键差异，把原本模糊的自然语言规则细化成更明确的安全约束，从而便于后续自动生成检测代码。
实验结果表明，GPTAid 在200个 API 上生成 APSRs 的精度达到92.3%，召回率达到71.0%；与已有方法相比，它能够生成更多类型的规则，并在47个真实应用中发现210个未知 API 误用问题，其中150个已得到开发者确认。总体来看，这篇论文展示了将大语言模型与程序分析技术结合，用于 API 安全规则生成与误用检测的有效性和实用价值。
贡献分析
贡献点1：提出了基于 LLM 的 APSRs 自动生成框架 GPTAid
论文提出 GPTAid，用于从 API 源码中自动生成 API 参数安全规则。与直接使用大语言模型不同，GPTAid 重点面向两个核心难点：一是 LLM 容易生成错误规则，二是容易生成过于宽泛、缺乏可执行性的规则。
贡献点2：设计了执行反馈校验与代码差分细化两项关键技术
为了提升生成规则的可靠性，论文提出了 execution feedback-checking 机制，通过生成违规调用代码并结合运行时错误反馈来验证 APSRs 的正确性；同时提出 code differential analysis，利用正确代码与违规代码之间的关键差异，将原本模糊、笼统的规则进一步细化为更具体、更清晰的安全约束。这两项技术共同构成了 GPTAid 的核心方法基础。
贡献点3：证明了生成规则在真实 API 误用检测中的有效性
论文不仅完成了 APSRs 的自动生成，还将这些规则进一步用于 API 误用检测，并证明了其实用价值。实验表明，GPTAid 生成的规则能够支撑后续检测流程，并且检测效果优于现有先进方法。此外，基于这些生成规则，作者共发现210个未知安全 bug，其中150个已被开发者确认，说明该方法不仅在规则生成层面有效，在真实漏洞发现任务中也具有较强应用价值。
贡献点4：发现了大量文档缺失规则，并总结了实践性建议
论文在8个常用库的实验中发现，在生成的579条 APSRs 中，有61.3%在现有 API 文档中没有对应描述，这说明 GPTAid 在一定程度上能够补充和丰富 API 文档中的安全约束信息。与此同时，论文还进一步总结了两类实践建议：一类是面向 API 开发者的文档改进建议，另一类是面向 LLM 使用过程的 prompt 设计建议，从而增强了研究的工程指导意义。
代码分析
代码链接
https://github.com/icy17/GPTAid/
使用类库分析
该项目整体采用 Python 作为主要实现语言，属于典型的“LLM 调用 + 程序分析 + 动态验证 + 规则细化”型研究代码框架。系统一方面调用大语言模型完成 API 参数安全规则生成、正确调用代码生成、违规调用代码生成以及规则细化；另一方面结合源码解析工具、运行时检测工具和静态检测工具，对生成结果进行验证与落地应用。整体来看，这个项目并不涉及复杂的模型训练，而是更侧重于将论文中的方法流程工程化实现。
代码实现难度与工作量评估
从实现角度来看，该项目难度属于中等偏上。它的难点不在于单一算法本身，而在于需要把论文中的多个环节稳定串联起来，包括目标库源码预处理、API 安全规则生成、正确与违规调用样例构造、运行时错误验证以及最终规则细化与检测。
代码关键实现功能
（1）源码预处理与信息抽取模块。该部分主要负责对目标库源码进行分析，提取 API 函数定义、参数信息以及相关调用关系，为后续大语言模型生成规则提供必要上下文。它相当于整个系统的数据准备阶段，为后面的规则生成和验证打基础。
（2）API 参数安全规则生成模块。该模块围绕目标 API 及其参数构造提示信息，引导大语言模型生成初始的 API 参数安全规则。其作用是让模型从源码层面理解参数约束，而不是仅依赖文档或调用样本，从而为后续检测提供候选规则。
（3）正确调用代码与违规调用代码生成模块。为了验证规则是否合理，系统会围绕目标 API 自动生成能够正常调用的代码样例，以及违反特定规则的调用样例。该模块是把自然语言形式的规则落到可执行程序层面，使得后续能够通过真实运行结果来检验规则质量。
（4）执行反馈验证模块。该部分是整个系统的重要环节。系统通过执行生成出的违规代码，并结合运行时错误检测机制来判断某条规则是否真正有效。相比仅依赖模型文本输出，这种方式能够更可靠地过滤掉错误规则或无意义规则，是提升 APSRs 精度的关键步骤。
（5）规则细化与误用检测模块。在得到初步验证后的规则后，系统还会进一步对规则进行细化，使其从较为模糊的表述变成更具体、可解释、可检测的安全约束。最终，这些规则会被转化为检测逻辑，用于在真实应用程序中发现 API 误用问题。
论文点评
总体来看，这篇论文是一项较有价值的 LLM 与程序分析结合的安全研究工作。它的重点并不只是利用大语言模型生成 API 参数安全规则，而是进一步针对直接使用 LLM 时容易出现的错误规则和规则过于泛化两个问题，设计了执行反馈校验和代码差分细化两项机制，从而提升了规则的准确性和可用性。
从实验结果来看，论文具有较强说服力。GPTAid 在 APSRs 生成任务上取得了 92.3% 的精度和 71.0% 的召回率，并进一步在真实应用中发现了210个未知安全问题，其中150个 已被开发者确认。这说明该方法不仅在规则生成层面有效，而且具备较强的实际漏洞发现能力。与此同时，论文还发现大量生成规则在现有 API 文档中没有对应描述，说明 GPTAid 在补充 API 安全约束信息方面也具有现实意义。
不过，这篇论文也存在一定局限。它的验证方式较大程度上依赖运行时错误反馈，因此对于那些不会立即触发异常的 API 误用问题，检测能力可能有限。此外，系统在规则到检测逻辑的转换过程中仍带有一定人工总结和模板化处理成分，说明其自动化程度还有进一步提升空间。
总体而言，本文提出了一个结构完整、思路清晰的方法框架，展示了大语言模型在 API 安全规则生成与误用检测中的应用潜力。它也说明，在软件安全分析场景下，LLM 更适合与程序验证和分析技术协同使用，而不是单独作为黑盒生成工具。
论文文献
Liu J, Yang Y, Chen K, Lin M. Generating API Parameter Security Rules with LLM for API Misuse Detection[C]//Network and Distributed System Security Symposium (NDSS). 2025.
安全学术圈招募队友-ing
有兴趣加入学术圈的请联系 secdr#qq.com
声明：本文来自安全学术圈，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
