在保障区块链项目的安全及稳定方面，审计一直以来都发挥着至关重要的作用。
CertiK的审计专家团队拥有丰富的经验，迄今为止已获得了家企业客户的认可，挖掘了超过个代码漏洞，保护了超过亿美元的数字资产。
CertiK的审计过程全面且彻底，我们的安全专家会细致检查项目的设计、架构和源代码，以发现漏洞或风险。
凭借我们的安全专业知识和业内领先的端到端安全解决方案，CertiK持续引领着Web3.0行业的安全领域，提供从最基本的token到最复杂的DeFi协议乃至区块链整体架构的安全审计服务。
但是想必会有用户疑惑于我们具体是如何进行审计的，审计方法是什么，关键的审计特点又是什么？
往下看，这篇文章就可以给出答案。我们的审计流程的第一步，是获得源代码并搭建一个定制环境。
第二步是审查项目文件并进行威胁模型分析，随后使用内部工具和人工审计来寻找安全漏洞和设计缺陷。
第三步是提交一份包含所发现的风险及其修复建议的初审报告。
第四步则是出具终审报告，该报告将详细描述审计工作为项目带来的帮助，并展示了CertiK审计专家是如何协助项目规避Web3.0关键漏洞的。
环境配置
目前，CertiK的审计及端到端安全解决方案已覆盖目前市面上大部分生态系统，并支持几乎所有主流编程语言，就区块链平台、数字资产交易平台、智能合约的安全性等领域为各个生态链提供安全技术支持。
虽然某些编程语言所编写的项目可能需要非常复杂的配置过程，但这个问题可以通过使用预先配置的虚拟机环境得到一定程度的解决——将代码导入到配置好的环境中，检查其能否成功编译和部署，该环境的设置使安全专家能够运行代码并编写测试，以获得对项目更深刻的理解。
架构审计
确定项目的架构对于了解系统和安全相关的关键组件与部分至关重要。
对架构的彻底理解对于有效的威胁模型分析也是必不可少的。
理想情况下，项目团队会提供一份白皮书和技术文件，概述项目的详细架构。
然而在许多情况下，这些架构文件是缺失的，审计员必须进行架构提取以确定架构。
架构提取包括检查组件之间的交互、外部输入的处理、库的导入、新想法的实现、对代码标准的遵守以及对并发的支持。
对于常见的项目类型（例如包含存款、贷款、手续费、收入、价格预言机和清算组件的借贷协议）来说，利用工具生成调用图和存储布局图来辅助进行可视化的过程可能很简单。
然而，对于组织不完善或非常规的项目，审计员可能需要通过逐个分析功能和源文件来手动确定组件结构及其关系。
确定一个项目是原创设计还是另一个项目的分叉也很重要。因为分叉很有可能会继承来自其初始项目的漏洞——PancakeBunny协议遭到闪电贷攻击，损失超过万美元，其源代码被其他多个项目分叉，由于未能识别和修复漏洞，导致他们遭受了相同的攻击。但本来一个彻底的安全审计就可以发现这个漏洞从而规避此种攻击。
威胁模型分析
威胁模型分析包括对一个项目的关键资产、资源和安全需求的描述，以及划分出了一个潜在漏洞和安全威胁的列表。
抽象的描述是在架构审计期间建立的，安全需求可以通过基于系统架构提出并回答有关问题来确定。例如，在一个治理系统中，可以尝试提出以下问题：
谁可以创建提案？
创建一个提案有哪些要求？
一个提案需要多少百分比的票数才能通过？
提案的验证期有多长？
项目使用的是什么投票token和机制？
特权账户可以修改哪些配置？
一旦确定了安全需求，就该考虑可能会面临的威胁了。
在Web2.0中，常用的威胁分类模型是STRIDE，它将威胁分为六类：欺诈、篡改、抵赖、信息泄漏、拒绝服务和权限的提升。
这个方法在Web3.0中需要稍作修改。例如在DeFi项目中，源代码是在区块链上验证的，所有交易信息和存储数据都是公开的，所以“信息泄露”的威胁并没有那么大。
威胁模型分析最后的结果将会生成一个安全检查表，用以指导安全审计，并可更加全面的评估系统安全状况。
静态分析和形式化验证
我们通过端到端安全解决方案以及运用CertiK丰富的审计经验和技术底蕴来为Web3.0提供安全服务。
包含在端到端安全解决方案内的工具和服务均依托于一个庞大数据库——这些数据来自CertiK数以千计的审计历史和挖掘的超过个漏洞。
其中，我们的安全工具会在源代码和字节码层面对代码进行静态测试，识别不安全的代码模式并生成图表以提供对智能合约的可视化分析。
随着机器学习与智能合约风险环境的不断变化、威胁情报库和智能合约漏洞库的不断积累，这些安全工具也将随之进步。
除了静态分析外，我们还通过形式化验证来确保项目代码的安全，并确保程序运行符合其预期的规范。
形式化验证，是一种验证计算机程序是否按照预期运行的数学证明方法。
它将程序的属性和预期行为表达成为数学公式，然后使用自动化工具来检查这些公式是否成立。该过程有助于确保其程序符合预期，其主要发现包括逻辑问题、重入风险、缺乏访问控制、溢出/下溢和gas优化等等。
但最终产生的结果需要经过审计专家的人工验证，以保证结果的准确。
人工审计
安全工具的确非常强大但是也有其相应的局限性，这也是我们经验丰富的工程师团队发挥作用的地方。
人工审计的内容包括对代码进行极为细致的逐行检查，这是整个审计过程中最为耗时的步骤。
人工审计可以分为两个部分：微观审计和宏观审计。
微观审计包括分析代码以了解所有功能，在这个过程中我们经常会发现代码的问题。这一审计部分涉及到的技术包括分析每个参数、变量和字段，审计函数访问控制和修改状态变量，以及对类似的函数进行比较。
而宏观审计是通过了解项目的调用/合约层次，搜索状态变量和函数的出现位置，以及检查不同的假想场景来识别全局漏洞。
例如那些关键性漏洞的诱因通常不只局限于单一的函数，而是可能由位于代码不同部分、多个功能之间的不正确交互导致。
上文我们提到了架构审计和从威胁建模结果中得出的“安全检查表”，人工审计的过程也将参考这些结果。
在人工代码审计过程中，审计员将同时采用黑客和开发者的视角。黑客的思维方式将被用来发现那些可能被利用的潜在漏洞，而开发者的思维方式将被用来验证执行情况并识别代码中的不足，如低效的gas使用和缺乏的代码模块化。
在必要情况下，我们还会将单元测试纳入人工审计。
单元测试是根据每个项目的不同特点为其量身定制的安全评估，包括验证项目组件是否正确地响应特定的输入、输出和边缘案例。
如果单元测试被成功运行，那么就意味着代码的确是在按照预期规范运行。
针对大型项目，CertiK将安排多位审计员作为一个团队进行审计，建立审计计划并分配相应职责，定期举行会议以讨论审计进度和结果，并在必要时协同完成工作。除此之外，也将为项目与审计团队之间建立一个便捷的沟通渠道，以便第一时间就项目审计相关内容进行沟通。
CertiK的审计方法整合了各项安全技术，包括静态分析、形式化验证和人工审计，以确保项目代码库的安全。这种全面的方法可将安全漏洞发生的风险降到最低，为项目赋予对其代码正确性和安全性的充分信心。
审计报告和代码修复
我们的审计报告从项目的类型、生态系统和审计范围的描述开始，对项目的安全状况进行了详细的分析。这些报告解释了我们用于评估项目安全性的方式和审计方法。
而为了让读者更容易理解报告中的安全评级和术语，在报告的附录部分，我们提供了有关审计的定义和其他信息，这些信息包括图表和审计员注释。所做的具体测试（如形式化验证）将在报告中专门提及，解释其执行过程和最终的结果。
我们提供的每个风险「Finding」都包括对项目中发现的问题进行识别、分类和提供的建议，以及对这些内容的详细解释。
每个挖掘出的风险「Finding」均包括标题和数据（如类别、严重程度、文件位置和解决状态）。
接下来的四个版块准确地详述了安全注意事项：
Description（描述）：定义了风险漏洞的背景并概述了其安全影响。
Scenario（情景）：介绍了触发一个漏洞或者造成项目故障的步骤及其前提。
ProofofConcept（概念验证）：包括了漏洞利用脚本和说明，以及用于在客户端重现漏洞时的预期日志输出。
Re