我们的审计方式：CertiK审计方法论综合指南

Key takeaways

• Our audit process runs from environment setup through architecture review, threat modeling, static analysis and formal verification, manual review, and finally reporting and remediation.
• Manual review is a line-by-line examination of the code and the most time-intensive step in the procedure. It divides into micro-auditing, which analyzes individual functions, and macro-auditing, which looks for global vulnerabilities.
• High-impact vulnerabilities are often not limited to a single function. They may result from incorrect interactions among multiple functions located in different parts of the code.
• Every finding includes a title and metadata, followed by four sections: Description, Scenario, Proof of Concept, and Recommendation.
• Audits provide a baseline security assessment of a project's code. Additional services — penetration testing, bug bounties, Skynet monitoring, 24/7 incident response, the Security Leaderboard, and KYC for Web3 — extend security beyond what an audit covers.

Environment Setup

We support more than ten major blockchain ecosystems and smart contract programming languages. While some languages and projects may require a complex setup process, this issue is mitigated by pre-configured virtual machine environments.

Code added to the environment is checked for successful compilation and deployment capabilities. The environment enables auditors to run code and perform tests to gain a hands-on understanding of the project.

Architecture Review

Determining the project architecture is crucial for understanding the system's security-critical components and parts. A thorough understanding of the architecture is also essential for effective threat modeling.

Ideally, the client will provide a whitepaper and technical documentation outlining the project's detailed architecture. However, in many cases, these architectural artifacts are missing, and auditors must perform architecture extraction to determine the architecture.

Architecture extraction involves examining:

1. Interactions between components
2. Handling of external inputs
3. Imported libraries
4. Implementation of novel ideas
5. Compliance with code standards
6. Use of concurrency

Tools can assist in visualization by generating call diagrams and storage layout diagrams.

The process can be straightforward for well-known project types — a lending protocol, for example, has components for deposits, loans, fees, income, a price oracle, and liquidation. For poorly organized or unconventional projects, auditors may need to determine the component structure and relationships manually, through function-by-function and source-file analysis.

Determining whether a project is a fork

It is also essential to determine if a project is an original design or a fork of another project. Forks may inherit vulnerabilities from the original project.

For example, the PancakeBunny protocol was attacked by a flash loan, resulting in a loss of over $40 million. The source code was forked by multiple other projects, leading to similar attacks because the vulnerability was not identified or fixed. A thorough security audit would have detected this vulnerability.

Threat Modeling

A Threat Model is a representation of a system that includes a description of its critical assets, resources, and security requirements, as well as a list of its potential vulnerabilities and possible security threats. The abstract description is established during the architecture review, and the security requirements can be determined by posing and answering questions about the system based on its architecture. For example, in a governance system, the following questions can be asked:

• Who can create proposals?
• What are the requirements for creating a proposal?
• What percentage of votes is required for a proposal to pass?
• How long is the validation period for proposals?
• What voting token and mechanism does the project utilize?
• What configurations can be modified by privileged roles?

Once the security requirements have been established, it's time to consider the possible threats. A commonly used model for categorizing threats in Web 2.0 is STRIDE, which divides threats into six categories: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege.

Adapting STRIDE for Web 3.0

This methodology can be slightly modified for Web 3.0 applications. In a DeFi project, the source code is verified on the blockchain, and all transaction information and storage data are public — so the threat of "Information Disclosure" is not as significant.

The outcome of the threat modeling process produces a security checklist that guides the security audit and ensures a thorough evaluation of the system's security posture.

Static Analysis and Formal Verification

We leverage our extensive experience and longevity through our suite of tools, which utilize a vast database of over 90,000 previous findings from more than 6,000 completed audits and identified incidents as of 2026-07-31.

Tools test code statically at both the source code and bytecode levels and can identify insecure code patterns and generate diagrams to provide insight into smart contracts. The tools improve as our database of findings grows with each audited project.

In addition to static analysis by tools, we secure client code through formal verification, ensuring that the program meets its desired specifications. Formal verification is a mathematical method of proving that a computer program functions as intended. It involves expressing the program's properties and expected behavior as mathematical formulas and then using automated tools to verify that these formulas hold.

Key findings from the tools encompass:

• Logic issues
• Reentrancy risks
• Lack of access controls
• Overflow and underflow
• Gas optimization

The findings generated by the tools are subjected to manual verification by auditors to eliminate false positives and enhance the clarity of the results.

Manual Review

Tools are indeed powerful; however, they also have their limitations. That is where our team of experienced engineers comes into play.

Manual review involves a meticulous line-by-line examination of the code and is the most time-intensive step in the procedure. It can be divided into two parts.

Micro-auditing

Micro-auditing involves analyzing code to understand each function, and this process often reveals bugs. Techniques include:

• Analyzing each argument, variable, and field
• Reviewing function access levels and state field modifications
• Comparing similar functions

Macro-auditing

Macro-auditing involves identifying global vulnerabilities by:

• Understanding the project's call and contract hierarchy
• Searching for state field and function occurrences
• Checking different what-if conditions

High-impact vulnerabilities are often not limited to a single function, but may result from incorrect interactions among multiple functions located in different parts of the code.

Two perspectives

The process is guided by the architectural review and the checklist derived from the threat modeling results. The auditor adopts both a hacker's and a developer's perspective during the manual code audit:

• The hacker's mindset is used to uncover any potential vulnerabilities that may be exploited.
• The developer's mindset is used to verify the implementation and identify inefficiencies in the code, such as inefficient gas usage and lack of code modularity.

Unit testing and team coordination

Unit testing is incorporated into manual review when deemed necessary. The purpose of unit tests is to validate the proper execution of a project's components in response to specific inputs, outputs, and edge cases, and to provide tailored assessments of each project's features. The successful completion of tests assures that the code operates according to its intended specifications.

For large projects, multiple auditors are required to complete the work. Auditors work as a team to establish a plan and assign responsibilities for each person's role in the project. Regular meetings are held to review progress, discuss findings, and collaborate as necessary. A communication channel is also established to facilitate communication between the client and the audit team.

Our approach to auditing integrates static analysis, formal verification, and manual review to ensure the security of the client's code base. This comprehensive approach minimizes the risk of security vulnerabilities, providing clients with confidence in the correctness and safety of their code.

Reporting and Remediation

Our audit reports provide a detailed analysis of a project's security posture, starting with an overview of the project's type, ecosystem, and scope. The reports explain our methodology and the auditing approach used to evaluate the project's security.

To assist readers in understanding our security ratings and terminology, an appendix provides definitions and additional information about the audit, including diagrams and auditor notes. Specific testing, such as formal verification, will be included in dedicated sections that explain the processes performed and the results gathered.

What each finding contains

The findings we provide include detailed explanations that identify, categorize, and offer recommendations for the issues found in a project. Each finding includes a title and metadata such as the category, severity, file location, and alleviation status, followed by four written sections:

1. Description — defines the finding's context and overviews the security implications.
2. Scenario — walks through the state and steps in which an exploit or malfunction would occur.
3. Proof of Concept — includes the exploit script and instructions, along with the expected logged output, so clients can reproduce the vulnerability.
4. Recommendation — concludes the finding by providing actionable mitigation steps.

These sections provide detailed and targeted information to improve the reader's understanding of the findings.

The remediation loop

The remediation phase is an ongoing dialogue between the client and auditors to further improve the project's security:

1. The initial security assessment is provided to the client.
2. The client responds with updated source code or comments.
3. The findings are updated to reflect any changes made to the code.
4. An updated report is published.

This process repeats until the client is satisfied with the final security assessment.

The report is published to clients and is publicly available on the CertiK Skynet, where community members can see how projects are improving their skynet ratings through CertiK audits and security services.

Summary

In addition to auditing, our security engineers participate in incident responses, security research, publish educational and technical blog posts, speak at conferences, compete in capture-the-flag competitions, and conduct internal training. They have a diverse range of skills and experience, which gives them a professional understanding of security. They stay up to date with the latest industry standards and best practices through ongoing education and research.

What sets our audits apart

CertiK audits have several key features that set them apart from other auditing services:

• Custom environments allow auditors to run proprietary tools and custom tests, ensuring the project's security is thoroughly tested and potential vulnerabilities are identified.
• The level of expertise our auditors have ensures that manual review scrutinizes code at the highest level, so potential issues are identified even in complex codebases.
• Fully customized reports provide solutions to the identified findings, meaning developers receive actionable steps to address vulnerabilities.

The purpose of CertiK's audit services is to provide a comprehensive security rating of the project's code.

What an audit covers, and what extends beyond it

While audits provide a baseline security assessment of a project's code, additional CertiK services further enhance project security:

The CertiK Security Suite provides comprehensive security for projects in both static and live environments, while building trust within the community.

That’s why we make our audit reports publicly available, so users can better understand the risks they may be taking on when getting involved with a Web3 project. It’s our mission to raise the standard of security and transparency across the industry, and this article detailing our auditing process is a part of that mission.

Conclusion

Our audit methodology combines three things that each cover what the others cannot: tooling that tests code statically at source and bytecode levels, formal verification that proves properties mathematically, and manual review by engineers who read the code line by line.

Manual review is the most time-intensive step for a reason. High-impact vulnerabilities are often not limited to a single function, but result from incorrect interactions among multiple functions located in different parts of the code — which is why micro-auditing and macro-auditing are both necessary.

And an audit is a baseline. It is a comprehensive security rating of a project's code, delivered with actionable findings and an ongoing remediation dialogue. Penetration testing, bug bounties, network monitoring, incident response, the Security Leaderboard, and KYC each extend security past the point where a code audit ends.

FAQ

Q: What steps does a CertiK audit involve? A: Environment setup, architecture review, threat modeling, static analysis and formal verification, manual review, and reporting and remediation.

Q: Which step takes the longest? A: Manual review. It involves a meticulous line-by-line examination of the code and is the most time-intensive step in the procedure.

Q: What is the difference between micro-auditing and macro-auditing? A: Micro-auditing analyzes code to understand each function, using techniques such as analyzing each argument, variable, and field; reviewing function access levels and state field modifications; and comparing similar functions. Macro-auditing identifies global vulnerabilities by understanding the project's call and contract hierarchy, searching for state field and function occurrences, and checking different what-if conditions.

Q: Why isn't automated tooling enough on its own? A: Tools are powerful but have limitations. High-impact vulnerabilities are often not limited to a single function and may result from incorrect interactions among multiple functions located in different parts of the code. Tool-generated findings are also subjected to manual verification by auditors to eliminate false positives.

Q: What is formal verification? A: A mathematical method of proving that a computer program functions as intended. It involves expressing the program's properties and expected behavior as mathematical formulas, then using automated tools to verify that these formulas hold.

Q: What does each finding in the report contain? A: A title and metadata such as category, severity, file location, and alleviation status, followed by four sections: Description, Scenario, Proof of Concept, and Recommendation.

Q: Can a project be audited without a whitepaper or technical documentation? A: Yes. In many cases these architectural artifacts are missing, and auditors perform architecture extraction to determine the architecture — which for poorly organized or unconventional projects may require manual function-by-function and source-file analysis.

Q: What should a forked project expect during an audit? A: Auditors determine whether a project is an original design or a fork, because forks may inherit vulnerabilities from the original project. The PancakeBunny example in this article shows what happens when a forked vulnerability is not identified or fixed.

Q: Are audit reports public? A: Yes. The report is published to clients and is publicly available on the Security Leaderboard, where community members can see how projects are improving their security ratings through CertiK audits and security services.

Q: Does an audit cover everything a project needs for security? A: Audits provide a baseline security assessment of a project's code. Penetration testing and bug bounties provide extra testing; Skynet network monitoring and 24/7 incident response protect against active threats; the Security Leaderboard and KYC for Web3 project teams support community transparency.

Appendix