如何阅读智能合约审计报告 - Chainsecurity

如何阅读智能合约审计报告

如果智能合约要发挥有意义的作用，对其进行审计是必要的。项目的所有利益相关者阅读其审计报告也至关重要。这样可以更深入地了解项目及其安全前景。

审计报告是技术文档，阅读它们可能具有挑战性。此外，智能合约审计的性质也可能令人困惑。例如，许多人将审计视为二元实体；如果一个项目经过审计，它就被认为是安全的。然而，正如我们稍后将看到的，事实并非如此。在本文中，我们将澄清许多此类误解，并学习如何正确理解审计报告。

衡量审计师声誉

审计智能合约是一项高度技术性的工作。它不仅需要深入了解被审计的代码库，还需要了解区块链生态系统中的其他项目。因此，审计师的声誉和资历是需要考虑的重要因素。通常，审计师应该广为人知，拥有多年的审计经验，审计过几十个项目，并且由他们审计的代码不应该有被利用（exploited）的记录。审计过高使用率和高价值的项目也是一个加分项。

阅读执行摘要

审计报告通常在开头包含执行摘要；这是一个重要的阅读信息。它告诉我们审计团队审查代码的方法、审计时间范围以及审计师对代码库的普遍看法，以及任何辅助信息。它还让我们了解审计团队对代码库的信心以及他们进行审计的方法。例如，如果通过阅读执行摘要，我们得知审计期非常短，那么我们推断审计可能遗漏了重要内容并非不合理。

阅读评估概览

本节界定了审计的范围。它提及了审计范围内的文件，并排除了不在范围内的文件。虽然开发者应该审计其项目的全部内容，但有时他们无法做到；因此，他们可能选择只审计部分文件。这意味着，如果未经审计的文件存在漏洞，整个项目将遭受利用（exploit）。尽管存在这些问题，但由于资源限制等原因，范围界定仍然是智能合约审计的现实。

阅读系统概览

审计报告也可能包含系统概览部分。在此部分，审计团队会撰写一份被审计代码库的总结性、整体性概览。它告诉我们项目结构以及构成整个代码库的各种智能合约之间的相互作用。此外，它还提及了审计师所基于的任何假设。与执行摘要类似，这部分很重要，因为它为我们理解漏洞披露提供了最基本的知识。

进行新旧程度检查

必须确认审计过的代码和部署的代码是相同的。后者可以通过访问Etherscan等区块浏览器上的智能合约地址，然后转到“contract”选项卡来找到。一个经过验证的智能合约会在其 Etherscan 页面上显示其代码。一般来说，开发者应该在区块浏览器上验证他们的智能合约，或者提供不这样做的有力理由。此外，不言而喻的是，由于 Etherscan 等区块浏览器是私有运营的，因此对其信任是隐含的。获取链上智能合约代码的去中心化方法是运行给定区块链的节点，并查询其相关信息。

如果我们进行逐行比较，审计过的智能合约与已部署的智能合约进行比较可能不切实际。大多数项目将其代码库托管在 GitHub 等版本控制服务上；审计报告要么提及被审计代码的 GitHub 仓库的 commit hash，要么包含文件及其各自哈希的列表。

commit hash 是一个唯一的字符串，代表 GitHub 上仓库的状态；它对于代码的每个状态都不同，因此当代码发生变化时，无论多么微小，它都会改变。因此，我们可以比较审计代码的 commit hash 与部署代码的 commit hash，确保两者彼此相同。对于列出文件哈希的审计报告，通常需要向项目团队询问具体的 commit，并手动验证文件哈希与该 commit 中存在的文件匹配。

我们为什么要这样做很重要；智能合约中即使最微小的改变也可能引入严重的漏洞。因此，代码在审计和部署之间没有改变应该是我们首要关注的问题。

诚然，执行上述过程并不容易，有时甚至不可能。然而，如果一个人计划实质性地依赖项目的安全和持续运行，那么尝试一下绝对值得。即使审计代码和部署代码彼此不同的迹象也足以表明该报告或多或少已经过时，并且没有评论代码库当前的链上状态。

阅读审计发现

漏洞披露是通过列出并解释审计代码中的问题来进行的。这些问题通常分为四个风险或严重性类别：关键 (Critical)、高 (High)、中 (Medium) 和 低 (Low)。

关键 问题导致功能完全崩溃和/或资金损失。高 和 中 问题会削弱功能和/或导致资金损失，而 低 问题则指向不会导致资金损失或恶化代码执行效率的问题。

一份好的审计报告的标志是，所有问题，特别是关键和高级别的问题，都得到了全面解释。同时，高亮显示的问题质量要好，团队不能仅仅是复制粘贴 static analysers 的输出。

另一个需要注意的重要事项是“严重性膨胀”（Severity Inflation），即审计师滥用严重性标签。较低严重性级别的问题被故意标记为较高严重性级别，以增加审计的感知价值。

理解项目所有者对审计发现的回应

阅读问题时，我们应该充分理解代码库的哪个部分受到影响，如何受到影响，以及可以采取什么措施来利用该漏洞。此外，我们应该特别关注项目所有权如何回应审计发现。

应该检查他们是否修复了问题，或者选择不修复。如果他们确实修复了，我们应该确认审计团队是否认可了该修复。问题可能被当作非问题而忽略，但后来却成为利用（exploit）的手段，或者修复没有传达给审计师，导致黑客攻击。因此，项目所有权对审计发现的态度非常重要。

理解审计后漏洞利用的影响

项目可能已经经过审计，甚至不止一次，但最终仍然被利用（exploited）。这可能意味着几件事。

首先，可能是审计团队错过了最终被利用的特定 attack vector。审计的承诺并非是无 bug 的代码，而是在给定时间和资源内尽力发现尽可能多的漏洞。

其次，项目团队可能在审计后进行了更改。项目在审计后进行更改，认为不会引起任何问题，这并不少见。一个例子是当开发者升级他们的智能合约时，因此引入了审计时不存在的漏洞。在这种情况下，审计报告的存在并不意味着当前代码库已通过审计，而仅表示其先前版本已通过审计。

第三，有些项目选择在开发周期的不同阶段进行审计。在这种情况下，即使他们的网站或公共 GitHub 可能显示存在多个审计报告，这并不意味着相同的代码被多次审计。这仅意味着不同的代码在不同时间点由不同的审计团队进行了审计。

第四，有些情况下项目选择让不同的团队审计其代码库的不同部分；每个审计的范围都不同。因此，即使项目的某些部分已经单独审计，但当系统作为一个整体来看时，它最终可能被一个专业的黑客团队利用。

另一个需要考虑的事实是，审计定义的范围不包括与外部合约的交互。项目开发者将外部合约视为安全是合理的；他们不可能审计他们交互的每一个外部智能合约。因此，可能会发生审计代码本身是安全的，但外部 dependency 不安全的情况，从而导致漏洞利用。

因此，不应将多次审计视为相互加强并因此表明代码库经过高度审计，这仅仅是因为各种审计可能处理了不同的代码库、commits 和/或范围。

结论

在本文中，我们了解到理解审计报告对项目的所有利益相关者至关重要。它不仅告诉我们审计过程中发现的漏洞，还告诉我们项目所有权决定如何处理这些披露。它还向我们传达了审计团队对项目的理解以及他们对这种理解的信心。我们还探讨了审计的含义，以及它对项目用户和所有者的影响。审计报告的性质以及多次审计之间的相互作用也得到了探讨。

external-link

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