AI 辅助进行代码安全审计

感谢我们的审计师： Christian， Kirill，Lucas 和 Peppe，为本文的贡献。

随着 AI 驱动工具的出现，区块链安全审计的格局正在发生显著变化。作为安全专业人员，我们正在见证审计方式的转变，人工智能正成为我们工具库中越来越有价值的补充。在本文中，我们探讨了区块链安全审计师当前可用的 AI 工具的现状， examining 其实际应用、局限性，并披露我们在 Oak Security 的审计师所使用的现实世界策略。

Oak Security 已为超过 500 个项目进行了安全评估，项目范围从 Lido 和 1inch 等 DeFi 协议到包括 Filecoin 的虚拟机和 Dusk 共识协议等关键基础设施。作为 Solana、Polkadot 和 Cosmos 生态系统的可信安全审计师，我们的团队在评估复杂的区块链系统方面拥有丰富的经验。

免责声明：隐私挑战

面对希望利用 AI 的安全审计师，最紧迫的挑战可能是使用这些强大资源与维护客户机密性之间的根本紧张。大多数审计师在严格的保密协议 (NDAs) 下工作，这对他们与 AI 平台的互动创建了显著限制。使用专有的 LLM（大型语言模型）可能会导致敏感客户数据（或报告发现）对第三方的暴露。但是，有几种可行的方法可以解决这一挑战。在我们深入探讨这些解决方案之前，请确保审查你的特定客户协议以了解限制，并确认这种处理方式在你的案例中合适和合法。

为了避免使用专有的 LLM，你可以利用 GitHub 上找到的多种 开源语言模型，因为它们在 MIT、Apache 2.0 和 OpenRAIL-M 等宽松许可证下发布。通过在你的私有基础设施中部署这些模型，你可以完全控制提供给 LLM 的数据及其安全协议。

在本地运行这些模型提供了对数据处理的完全控制，但这会带来技术开销，并可能导致与基于云的解决方案相比性能降低。因此，一些组织选择在专用云基础设施上部署 AI 模型，在控制和性能之间取得平衡，尽管这需要组织保持对基础设施的完全所有权。无数据收集 AI 工具或支持“隐私模式”特性的工具代表了另一种潜在解决方案，尽管审计师在处理此类供应商声明时应持适度怀疑态度，并确保查看其隐私政策。即使在这些保证得到验证的情况下，许多客户仍可能要求额外的确保，或有时完全禁止在其代码中使用外部 AI 工具，因此请确保在开始 AI 协助审计之前确认这一点。

AI 工具包

传统上，安全审计师依赖于 Mytrhil、Slither 和 Oyente 等静态分析工具的组合，以便检测已知漏洞模式，以及像 Echidna 这样的动态分析工具进行基于模糊测试的漏洞发现。尽管这些工具仍然是审计过程的基础，但审计师们开始在安全过程中添加按照 AI 驱动的工具作为额外的辅助。

通过我们的实践经验，我们观察到 AI 工具在现代审计工作流程中倾向于承担 4 个常见功能：

1. 代码理解
2. 漏洞检测
3. 攻击向量验证
4. 文档/报告撰写

每个类别针对审计工作流程中的特定挑战，提供不同的工具，以解决这些问题。

在我们深入探讨之前，我们想强调任何自动化工具的有效性——无论是传统静态分析还是现代基于AI的——最终依赖于使用它的人类审计师的专业知识。 与传统工具一样，AI 助手也需要细致的人类监督和对其输出的验证。

1. 代码理解

AI 助手在解释代码部分和复杂的多合约交互方面表现出色，帮助审计师快速理解复杂的协议机制和潜在的边界情况。像 Claude 和 ChatGPT 这样的工具在这一领域的表现尤为突出。对于简单的智能合约，它们通常能够充当代码解释器，并有时可以生成功能性数据或控制流图，但更倾向于依赖像 Solidity Visual Developer 这样的专用工具，获取更准确和全面的结果。

协议架构分析： Cursor 已成为审计师特别有用的工具，其将 LLM 能力直接集成到开发环境中。该工具的一个主要优势在于对代码库及其文件的完整上下文的访问。这使得在询问有关整个代码库的一般分析问题时，轻松参考代码部分。例如，在图 1 中，我使用 Cursor 中的“ @codebase” 引用，检查 Uniswap V4 的代码库，并询问其在所有项目文件中协调交换的逻辑。Cursor 将问题传递给底层语言模型，同时附上当前项目文件的上下文，以获得答案。

图 1：在 Uniswap V4 中询问 Cursor 全代码库的问题

代码流程解释： Cursor 的另一个有用特性是选择合约中的一段代码并按快捷键（Mac 上为 ⇧⌘+L）询问与其相关的任何问题。在这种情况下，只有所选的代码行会被自动添加为 LLM 的上下文。

让我们以臭名昭著的 MakerDAO 代码命名法为例。由于独特的命名惯例，阅读此代码可能令人困惑。在以下示例中，我高亮显示了一个特定的代码块，并请 Cursor 帮我解读清算逻辑的术语：

图 2： 请 Cursor 解读 Maker 的 DAI 实现中的代码片段

Cursor 特别强大的地方在于它分析所选的代码行，同时保持对整个代码库上下文的意识，提供的解释考虑到了更广泛的项目背景。这种上下文理解在调查由于不同合约间的相互作用、继承模式或系统状态修改而产生的错误时尤其有价值。

GitHub Copilot 也擅长通过提供行内解释和建议潜在的边界情况来协助理解复杂功能。我们通过运行同样的两个示例进行比较，尽管第一个答案看起来类似，Cursor 在定义方面似乎提供了更好的陈述和关于 Uniswap 命名法更详细的解释。

图 3： 在 Uniswap V4 中询问 Copilot 全代码库的问题

图 4： 请 Copilot 解读 Maker 的 DAI 实现中的代码片段

模型选择： 值得注意的是，底层模型的选择差异很大。我们尝试的一些模型（包括较新的 OpenAI o1 和 o3 模型）产生了一些糟糕的结果，例如过于简洁的解释和不一致的推理。目前，Copilot 仍使用 GPT-4o 模型，而 Cursor 则依赖于 claude-3.5-sonnet，这是有充分理由的。这两个模型都产生一致的质量结果，且相当可比较。在代码解释方面，表现最佳的仍然是 GPT-4o 和 Claude 3.5 Sonnet。

代码可视化： 除了经典的 Solidity Visual Developer 扩展，像 TRUSTBYTES 的 应用 也开始从漏洞检测转向通过可视化表示增强审计师理解。

图 5：使用 Trustbytes 的应用程序进行代码可视化

这种转变承认了安全审计中的一重要真理：帮助审计师更好地理解复杂协议的可视化工具，可能比那些尝试自动检测漏洞的工具更有价值。正如某位行业参与者所指出的：“漏洞往往源于看似安全组件之间的微妙交互。” 增强审计师理解这些交互能力的工具——通常通过代码可视化——加速了批判性思维过程，而不是绕过它。这是 AI 可以辅助但无法替代人类理解的典型任务。

限制：虚假信息的潜力

AI 系统有时会在回答中包含虚假信息。虚假数据与真实数据的比例在不同模型中变化。最好使用那些能够识别自身无法提供合适答案的模型，而不是那些试图在没有证据的情况下过于承诺的模型。AI 提供的任何数据都应由审计师验证，因为它很容易误导并导致你构建错误的审计项目的心理模型或聚焦于无关细节。

2. 漏洞检测

曾经由静态分析器、符号分析器和模糊测试工具（Slither、Mythril、Echidna、MythX - 已弃用、SmartCheck - 已弃用，以及 Securify - 已过时）主导的领域，现在正在见证新基于 AI 工具的出现。然而，安全社区对 AI 漏洞检测的固有怀疑值得一提。

通常，安全研究人员要求工具输出的绝对确定性——这是当前 AI 系统始终困难以实现的标准。当工具标记潜在漏洞时，审计师仍必须通过手动追踪执行路径、理解状态变化以及验证边界情况来验证发现。如果这种验证的时间 consistently 超过直接手动分析，则该工具变成责任而不是资产。

这一现实使一些工具提供商（如 TRUSTBYTES）转向于不纯粹基于 AI 的漏洞检测，以改善审计师对代码库的理解，正如我们在前一节中所讨论的。当处理复杂的智能合约系统时，挑战尤为明显。以潜在的重入漏洞发现为例：虽然 AI 可能在状态更新之前标记出像外部调用这样的可疑模式，但若要了解发现是否代表真正的漏洞，需要分析 AI 目前无法克服的因素，比如复杂的访问控制机制、协议特定的不变量和跨合约状态依赖性。这种限制解释了为什么许多成功的 AI 实施在安全领域更专注于加速理解和模式识别，而不是直接尝试发现漏洞。

抛开这一点，让我们看看当前可用的漏洞检测工具的现状：

Cursor 的漏洞查找系统

Cursor 推出的新功能 Bug Finder 取代了旧的“审查”功能，并在误报方面似乎表现得比之前更好。此功能逐行扫描你对提交分支所做的更改，并检查是否引入了任何漏洞。这在审计的后期阶段非常有用，当你通过客户端来验证纠正措施或漏洞修复时。尽管仍是实验性的，但运行此功能的费用可能颇高，具体取决于所做更改的数量，因为它逐行工作，以查看是否引入了任何漏洞。

图 6：Cursor 的漏洞查找系统功能

随着对当前更改的分析，它准备了一份格式整齐的漏洞报告，列出发现的所有新问题。

在我们的案例中，我们在一个示例支付合约上测试它，通过在发送资金之前移动更新余额和付款状态的行，以查看 Cursor 是否能捕捉到这个问题。令人惊讶的是，它在发现这个问题时表现良好（即使是在免费运行漏洞查找系统的情况下）。

图 7：Cursor 的漏洞查找系统捕捉到一个漏洞

有趣的是，它还为提议的发现分配了信心水平，这可以成为在验证其结果时应关注的有用指标。

尽管我们在对小变化实施此功能时看到良好结果，但运行一次漏洞查找系统的成本可能较高。在测试的简单案例中，仅有几行代码被修改，每次运行的成本约为 $2-$4。但在验证架构更改或逻辑重写时，这可能会迅速变得昂贵，因此请在提交之前注意运行时成本。

Solidity Sentinel

由 Solidity 工程师 Ahmed Ihsan Tawfeeq 于 2023 年 10 月发布的 Solidity Sentinel 代表了一种 AI 辅助审核的有趣方法。它基于 ChatGPT 构建，作为专门的 GPT 模型，在智能合约漏洞和审核报告的数据集基础上进行微调，专注于智能合约安全分析。

图 8。Solidity Sentinel 聊天界面

我们的测试揭示了在漏洞检测方面的令人印象深刻的能力。在分析一个示例漏洞合约时，Sentinel 成功识别了包括重入漏洞、随机性实现失败以及构造函数和修饰符安全缺陷在内的关键问题。该工具以结构良好的格式呈现发现，按严重性对问题进行分类，并为每个漏洞提供具体的修复步骤。

图 9。Solidity Sentinel — 漏洞概述

值得特别注意的是，Sentinel 能够生成全面的安全报告，并提供合约的改良版本，实施所有建议的修复措施。作者很可能嵌入了特定的提示说明以查找安全模式，因为这些建议显示出对智能合约安全最佳实践的扎实理解，例如建议使用 OpenZeppelin 的 ReentrancyGuard，升级到 Solidity 0.8+ 以防止溢出，并实施基于拉取的提取模式。

图 10。Solidity Sentinel — 最终建议

而该工具也有局限性。最明显的是，代码必须直接粘贴到聊天界面中，而不是作为文件上传，这对于复杂项目涉及多个合约和依赖项来说可能显得繁琐。这个限制使它在分析大型协议时的适用性不如像 Cursor 这样的专用开发环境工具。

如果你想了解其他面向审计师的 GPT 衍生工具，theresanaiforthat.com 上有许多类似的工具，例如 AI Auditor、Solidity Auditor、SecuredAI 等，由社区成员构建。

LightChaser

作为 Code4rena 的机器人竞赛中的顶级选手，LightChaser 实现了超过 1000 种检测模式和 100 多种 gas 优化检查，帮助审计师打勾并覆盖低难度的漏洞。有趣的是，虽然 TRUSTBYTES 已转向代码可视化，但他们最近与 LightChaser 合作，显示了其自动化预扫描产品的需求。LightChaser 在本地运行，有助于保护隐私，并可以根据你项目的需求进行定制。

以下是 LightChaser 对 AAVE V3 代码生成的公共审计报告之一：

图 11：LightChaser 对 AAVE V3 代码的报告。来源：https://gist.github.com/ChaseTheLight01/66625ecfb9a2c07744a1c0c3050c560b

它发现总共存在 67 个问题，其中 3 个为中等严重性问题。像这样的预扫描工具发现的总问题数量可能会非常庞大，查看其他公共审计报告，似乎是个普遍现象（Euler Vault Kit 的 180 个问题报告， Axelar 的 113 个问题报告）。通常，有些项目是非常基础的格式相关问题，例如“函数未按照风格指南排序”或“合约行长度应不超过 120 个字符以提高可读性”。某些较高严重性的结果，如“特权函数可能导致故障点”，需要审计师判断哪些特权函数应该更好地受到保护，并权衡将它们迁移到多重签名下的得失。而其他一些更高严重性的发现则非常有用，例如“isContract 不是确定地址是 EOA 还是合约的可靠方法”，因为手动跟踪已弃用函数可能颇具挑战性。

Peculiar

Peculiar [4] 代表了一种创新的方法，将关键数据流分析与预训练 LLM 结合在一起，准确检测智能合约漏洞。Peculiar 引入了一种简化的 CDFG（关键数据流图），专注于与潜在漏洞最相关的变量和关系。例如，在分析重入漏洞时，CDFG 捕捉到外部调用和状态修改的关键数据流，同时过滤掉无关的代码路径。

图 12：Peculiar 架构

Peculiar 特别的地方在于它能够分析合约不同部分之间的关系， تستطيع在检测跨多个函数或涉及复杂状态修改的漏洞方面表现得非常有效。

该工具的架构利用了 GraphCodeBERT，这是一个预训练模型，能够理解代码结构和语义，但特别针对漏洞检测进行了调整，通过新颖的图引导的掩蔽注意机制来实现。这使得 Peculiar 能够在考虑合约不同组件相互作用的更广泛上下文的同时推理潜在漏洞。

以下是 Peculiar 与受欢迎的工具（如 Mythril 和 Securify）在 SmartBugs Wild Dataset 上进行比较的结果，其中包含 47,398 个智能合约。

F1 分数对于漏洞检测准确性尤其重要，因为它综合测量了假阳性（错误标记安全合约为漏洞）和假阴性（遗漏实际漏洞）。工具需要识别真实漏洞（高召回率）并且不引发假警报（高精确率），才对审计师真正有用。

我们可以看到，传统工具（如 Manticore、Mythril 和 Osiris）表现一般，F1 分数在 50% 左右，因为它们主要依赖于静态分析和符号执行。Slither 显示出更高的召回率（65.41%），但精确率（51.97%）存在困难。使用机器学习方法的 DR-GCN 和 TMP 手段进一步提高了表现，F1 分数分别为 76.39% 和 78.11%。然而，Peculiar凭借其组合的自定义预训练 GraphCodeBERT 模型和图引导机制显著脱颖而出。

虽然这个例子显示出 Peculiar 能够通过其流分析准确识别重入漏洞，但审计师需注意，其图形构造过程对于非常大的合约可能会计算密集。该工具是开源 的，且与自动化扫描流水线集成良好。

最新研究

• SmartLLMSentry [1]（原型）是一种新颖的 AI 框架，结合了传统静态分析与 LLM 驱动的规则生成。其在检测漏洞（如重入（93.12%）、时间戳依赖（95.17%）、和 delegatecall（94.51%））方面取得了优秀的准确率。传统静态分析器依赖于需要不断更新的手工制作规则，而 SmartLLMSentry通过基于 LLM 的规则生成来实现这一过程的自动化。该工具在复杂场景中表现尤为出色——例如，在分析具有复杂访问控制机制的合约时，它能够准确区分真实漏洞与看似脆弱的安全模式。然而，作为一款研究原型，它尚未作为生产工具供审计师使用。此外，作者们指出：“当前模型生成的规则并非完全自动化，仍需一些专家干预。”

• Smart-LLaMA [2]（原型）：建立在 LLaMA-3.1–8B 模型上，Smart-LLaMA 引入了一种两阶段的方法来检测漏洞：1）智能合约特定的持续预训练，随后 2）解释引导的微调。通过这种方式，模型不仅能够检测漏洞，还能够为其发现提供详细解释。该工具在不同漏洞类型中的准确率达到91%至 95%。值得注意的是，其涉及 32 小时专家评审的人工评估过程展示了其能力和局限性。例如，尽管在检测时间戳依赖漏洞（95.17% 准确率）和识别微妙重入模式时表现突出，但在涉及多个合约交互的复杂案例中，仍需要人工验证。与其他工具不同，Smart-LLaMA 侧重于提供详尽解释与其检测结果，使其在理解何种代码可能存在漏洞方面显得尤为有用。SmartLLaMA 目前也只是一个研究原型，不可用于生产。

• SmartEmbed [3]：作为一项专门的检测工具，SmartEmbed 使用代码嵌入和相似性检查来识别智能合约中的漏洞模式。在分析了超过 22,000 个 Solidity 合约时，它识别出高达 90% 的代码克隆比例，并发现了 194 个克隆相关的缺陷，精确率为 96%。虽然代码克隆本身并不一定是漏洞，但当漏洞代码模式被重复使用时，往往会在项目中传递安全问题。该工具在审计早期阶段特别有价值，能够识别人们可能从公共代码库或流行实现模式中遗传下来的潜在漏洞模式。然而，值得注意的是，该工具专注于克隆相关漏洞，应该与其他检测工具一起使用以提供全面覆盖。

限制：新颖攻击向量的缺乏

这些全自动工具的一个关键限制是，它们往往擅长找到 已知 漏洞模式，但可能会错过 新颖 攻击向量。这在很大程度上是由于它们的构建方式，因为几乎所有这些工具都基于以前已知的漏洞模式。

限制：过时的模式识别

为了保持这些工具的相关性，作者必须不断维护其操作的现有规则，包括更新漏洞搜索模式，以跟上安全社区中已知的最新漏洞类型。一个例子就是名为 Securify 的工具，最后一次更新是在 6 年前，拥有 37 种已知漏洞模式，且自那时以来未做更新。

3. 攻击向量推理与验证

在任何安全审计中，验证潜在攻击向量的假设是一个关键阶段。AI 工具已经成为这一头脑风暴过程中的良好助手。 Perplexity 和 ChatGPT 帮助审计师通过分解复杂交互来推理攻击场景，而无需提供源代码。不同于 Claude，不支持打开 URLs 或外部链接，Perplexity 和 ChatGPT 能够读取 etherscan 中的已部署合约并对此进行推理。以下是一个例子，我们询问两个工具推理一个假设的价格操控攻击，该攻击针对一个 已部署 的 Uniswap ETH/USDC 池进行：

图 13： Perplexity 推理价格操控攻击

图 14： ChatGPT 推理价格操控攻击

两个工具都能够访问给定地址的已部署代码，并很好地分解这一假设攻击中涉及的步骤。

在这项任务中，之前所提到的 Cursor 也是一个强有力的助手。

Cursor 与开发环境的深度集成提供了对整个代码库及其依赖项的全面可见性。这一全面的上下文在验证跨多个合约或依赖于复杂继承模式的攻击向量时尤为宝贵。例如，当测试潜在的重入攻击时，Cursor 能够追踪调用流，识别所有相关状态修改，并帮助构建一个考虑到完整系统状态的概念证明。

在下面的示例中，我们指出了一行我们认为由于缺乏 SafeMath 而易受溢出的代码，并要求 Cursor 确认这是否是一个漏洞：

图 15：Cursor 确认脆弱合约中的溢出漏洞

这种上下文意识在以下情况下特别有用：

• 穿越多个合约追踪状态变化
• 验证关于合约交互的假设
• 理解漏洞对整个协议的影响
• 分析复杂的继承层次结构

限制：伦理约束

你可能遇到的一个常见挑战是 AI 工具在讨论潜在漏洞时内置的伦理约束。例如，在分析可能的攻击向量时，像 Claude 或 ChatGPT 这样的工具可能会拒绝提供具体的利用细节或验证漏洞，因为它们的内置安全协议。考虑以下示例，我们询问关于 Cosmos 网络的特定攻击向量：

相反，经验丰富的审计师已经学会了：

• 将查询集中在防御模式上：“什么安全检查可以防止这样的漏洞？”
• 分解技术组件：“这种代码模式有什么影响？”
• 分析类似的历史漏洞：“这与已知的安全实现有何比较？”

这种伦理限制实际上强化了良好的安全实践，鼓励审计师循序渐进地思考漏洞，而不是专注于利用生成。关键在于将查询框架化为安全模式和保护措施，而不是攻击实施。

>> 来自我们审计师：验证发现 <<

Christian：“当验证问题时，我使用经过预训练的 Flan-T5 模型，这个模型的训练数据集中包括报告发现作为起点。然后，我将问题的描述和受影响的功能传递给该模型。与其询问模型这些是否是个问题，我专门指示它逐步检查这些函数，并交叉检查我描述的该问题的行为。该方法有两个主要优势：

1. 聚焦分析：通过让模型验证事件序列而不是评估是否存在问题，避免了二元“是”或“否”回答的陷阱。
2. 降低偏见：像 GPT 这样的模型倾向于一旦承诺特定的 “是” 或 “否”，就开始为其最初的回答辩护。这种方法确保模型不会将其推理锚定在早期假设上。例如，如果 GPT 开始说“是”或“否”，它通常会根据这一肯定或否决，调整其余的回应，以为该立场辩护，即使它可能并不完全准确。这就是为什么对这一特定任务进行微调的模型将提高分析的价值。”

示例：

Christian 认为 Cosmos SDK 链中的 marshalling/unmarshaling 编码可能存在问题。他使用自定义的 LLM 来检查这一假设。这个问题最终被证明是无效的，但模型提供了一些线索，如图 16 所示。

图 16：我们的审计师使用自定义 LLM 测试漏洞假设

4. 文档与报告撰写

审计的文档阶段需要既要技术准确，又要在描述问题时清晰沟通，以及遵循审计公司设定的标准报告格式。尽管你可以在这里使用通用的 AI 助手，如 Claude 或 ChatGPT，但最近由 Code4rena 的工程师 0xTotem 开发了一款更好的工具，名为 Documentation Bot。

Documentation Bot 特别为区块链安全审计师设计。它采用了一种检索增强生成 (RAG) 系统，将所有响应锚定在项目的官方文档中。

这里的关键优势在于其可验证的来源。在记录漏洞时，审计师需要对协议行为和预期实现有绝对的确定性。尽管 Claude 或 ChatGPT 可能会根据其训练数据提供看似合理的解释，但 Documentation Bot 则直接引用项目特定来源，从而带来更高的信任度。通过利用 RAG 架构，它提供对经过验证的协议信息的实时访问。例如：

图 17：问 Documentation Bot 关于清算阈值

这一区别对于审计报告至关重要——Documentation Bot 的回应基于项目特定的文档来源，降低了因错误假设或概括而导致的假阳性或漏掉漏洞的风险。

>> 来自我们审计师：报告撰写 <<

我们的一位审计师 Christian 使用自定义调优的 LLM 来保持审计报告的专业语气一致。

Christian：“为了培训模型用于报告撰写，我整理了过去一年中记录的所有审计问题。我以一致的格式结构化这些发现，并使用此数据集对模型进行微调。我的方法确保了模型学习了我在报告中使用的技术结构和专业语气。

我遵循的结构大致如下：

• 介绍性背景：“在 {代码部分} 中，函数 {函数名称} 执行…”
• 问题描述：“然而，有某些情况并不如预期…”
• 影响解释：“因此，这允许攻击者…”

模型也学会了我喜欢使用的特定术语。例如，我经常使用术语“基数”，经过微调，该模型能够自然而然地采用这一风格。

通过这种训练，我现在可以将原始笔记传递给模型，它会将其改写为我期望的精炼且结构化的格式。”

示例：

输入（审计师的笔记）：

“在 Example.sol 中，X 函数返回一个布尔值，用以指示一个代币是否已过期。如果合约未被激活，X 将返回 0，这与 Y 相加总是小于当前块时间戳。如果合约尚未激活，用户会收到其代币已过期的信号，而这并不准确。应返回一个错误，说明合约尚未激活。”

输出（模型生成）：

“Example.sol 中的 X 函数旨在确定代币是否已经过期。然而，当合约未激活时，该函数返回 0。将此结果与 Y（对于未激活的合约，其值也为 0）相加，得到的值便小于当前块时间戳，从而导致函数错误地表明代币已过期。因此，这种行为会在合约尚未激活时，错误地表示代币状态。相反，应该生成一个适当的错误消息，以告知用户合约的非激活状态。”

技术写作辅助

此外，像 Claude 这样的通用工具能帮助清晰地编写漏洞的技术解释。例如，要求将技术发现转化为清晰的报告条目并不难：

图 18：询问 Claude 将技术发现转化为报告条目

每一类别的工具都需小心集成到现有的审计工作流程中，并应视为审计师专业知识的补充，而非替代。关键是要记住，这些工具在不同方面是有限的（一些没有完整的代码库上下文，有些在知识截止的早期时间点），这让审计师在特定情况下有效地利用它们，同时保持严格的安全标准。

人类监督在 AI 辅助漏洞检测中的重要性

来自 Zaazaa 和 El Bakkali 的 SmartLLMSentry 框架[1] 及 Yu 等人的 SmartLLaMA 研究[2] 提供了有关 LLM 和人类专业知识在智能合约安全之间关系的有价值见解。尽管 SmartLLaMA 通过其新颖的两阶段培训过程在不同漏洞类型中达到了 91% 至 95% 的准确率，但这两项研究重要地强调这些 AI 工具在有经验的人类安全审计师监督下最为有效。

研究侧重于四个关键漏洞类别，约占以太坊智能合约攻击中所造成的 70% 的经济损失。SmartLLaMA 在检测时间戳依赖漏洞（准确率为 95.17%）方面表现极佳，识别出从块时间戳操控风险到不安全随机数生成的各类问题。该系统在探测重入漏洞方面也表现出良好的准确率（93.12%），成功识别单功能和跨功能重入模式，同时还妥善评估像 onlyOwner 修饰符等保护措施在具看似重入模式情况下仍提供充分安全性。

然而，即使拥有令人印象深刻的结果，研究揭示了重要的局限，强调了人类监督的必要性。这些模型在分析具有复杂继承关系的合约时准确性降低，并且在追踪多个合约间的状态变化时面临困难。新颖攻击模式及未见过的已知漏洞变种特别需要人类的验证。这些限制在涉及复杂访问控制机制的案例中尤为明显，在这些案例中，模型有时会错误地将安全模式作为漏洞标记，需人类专业知识来验证安全措施。

SmartLLaMA 的研究团队通过在评估流程中引入 32 小时人类专家的审阅来展示人类监督的价值。这一广泛的验证对确保合约的可靠性至关重要，特别是在涉及复杂的合约间依赖关系或依赖于上下文的漏洞时，人工无法独立评估。这一系统在检测整数溢出/下溢漏洞方面实现了 89.78% 的准确率，在 delegatecall 漏洞方面的准确率达到了 94.51%，但仍需要人机通力合作以验证发现和理解更广泛的安全影响，尤其是在涉及复杂权限系统或协议交互的情况时。

安全审计师们在这一过程中发挥着多个无法替代的角色。除了验证 AI 在检测常见漏洞模式中的能力，审计师还在更广泛的安全背景中对发现结果进行重要解读。他们的专业知识在评估经济安全和部署场景上尤其重要，AI 模型目前在这些方面显得不足。在面对新颖漏洞模式或复杂的跨合约安全影响时，人类审计师对区块链架构和现实攻击向量的深入理解显得至关重要。

最佳的方法似乎是合作模型，LLM 充当复杂的分析助手，帮助审计师更高效地处理更多的代码，并可能识别出人类注意不到的微妙模式。SmartLLaMA 的研究支持了这一结论，即便在其先进的两阶段训练方法下，人类专家仍充当着验证解释并确保实用的关键角色，尤其是在涉及多个合约或新颖攻击向量的复杂场景中。

这种混合方法维护了自动化的优势，同时保留人类专长不可替代的要素：上下文理解、细致判断和全面的安全评估。SmartLLaMA 的实施通过其架构体现出这一点，即便在达到了最先进的检测率后，该系统仍整合了广泛的人类验证组件。随着智能合约复杂性持续增加及新的漏洞模式产生，审计师与 AI 工具之间的伙伴关系代表了区块链安全的最稳健前行路径。

展望未来

AI 技术的快速发展表明，我们仅仅看到了其对安全审计影响的开端。保护隐私的 AI 技术正在快速提升，潜在地提供当前保密问题的解决方案。专门化审计工具的出现及本地模型部署的改进，可能会为处理敏感客户数据提供更多选项。

安全审计师应积极参与这些发展，并在可能的情况下为开源替代品贡献力量。未来可能出现更多专门针对区块链安全审计独特需求的工具计划。

在我们的文章中，我们强调了 AI 工具在安全审计师工具库中可以成为强大补充的几个阶段，但有效利用这些工具需要仔细考虑隐私、准确性和方法论。成功的关键不在于取代人类专业知识，而在于通过明智地应用这些工具增强专业知识，同时保持严格的安全实践。随着这些技术的持续发展，其在审计工作流程中的整合可能会深化，这将使安全审计师掌握这些工具变得必不可少。

由于这一领域不断演变，我们非常乐意听到你使用上述或其他工具的经验。如果你对这篇文章有任何见解或补充，请在下面的评论中分享它们！

我们在 Oak Security 的团队在以太坊和 Solana 安全模型方面具有深刻的理解，能够帮助你覆盖方案审查的各个方面，从早期规划、安全设计、经济咨询、安全开发流程与深入的协议审查。 查看我们的 审计报告 或通过 电子邮件 及社交媒体渠道与我们联系，社交媒体渠道包括 X 或 LinkedIn。

参考文献

[1] O. Zaazaa 和 H. El Bakkali, “SmartLLMSentry: 一种基于 LLM 的智能合约漏洞检测框架,” 《元宇宙期刊》，第 4 卷，第 2 期，页 126–137, 2024 年 12 月, doi: 10.57019/jmv.1489060。

[2] L. Yu, S. Cheng, H. Yuan, P. Wang, Z. Huang, J. Zhang, C. Shen, F. Zhang, L. Yang, 和 J. Ma, “Smart-LLaMA: 大型语言模型在智能合约漏洞检测和解释中的两阶段后训练,” arXiv:2411.06221v1 [cs.CR], 2024 年 11 月。

[3] Alam, M. T., Halder, R., & Maiti, A. (2024). 检测变得简单: 大型语言模型针对 Solidity 漏洞的潜力. arXiv:2409.10574 [cs.CR]。

[4] Wu, H., Zhang, Z., Wang, S., Lei, Y., Lin, B., Qin, Y., Zhang, H., & Mao, X. “Peculiar: 基于关键数据流图和预训练技术的智能合约漏洞检测。”

• 原文链接： medium.com/oak-security/...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～