Audits play a crucial role in safeguarding the security and stability of blockchain projects. The team of expert auditors at CertiK bring a wealth of experience to the table, having successfully completed audits on over 3,500 projects, uncovered over 60,000 findings, and secured more than $300 billion of assets. The auditing process at CertiK is thorough, as our experts meticulously examine a project's design, architecture, and source code to identify any vulnerabilities or weaknesses. With our specialized security expertise and advanced toolkit, CertiK leads the industry in providing a wide range of audit services, from basic tokens to the most complex DeFi protocols and entire blockchain infrastructures.

But how exactly do we conduct our audits? This article outlines our auditing methodology and highlights key auditing features.

Our audit process begins by obtaining the source code and setting up a tailored environment. Auditors review project documentation and perform threat modeling before using in-house tools and manual review to uncover security vulnerabilities and design flaws. A report is then presented to the client with findings and recommendations. The final report highlights the improvements made to the project as a result of our auditing efforts and demonstrates how a CertiK audit secures a Web3 project against critical vulnerabilities.

Environment Setup

We support more than ten major blockchain ecosystems and smart contract programming languages. While some languages and projects may require a complicated setup process, this issue is mitigated through the use of pre-configured virtual machine environments. Code added to the environment will be checked for successful compilation and deployment capabilities. The environment enables auditors to run code and perform tests to gain hands-on understanding of the project.

Architecture Review

Determining the project architecture is crucial for understanding the security-critical components and parts of the system. 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 detailed architecture of the project. However, in many cases, these architectural artifacts are missing, and auditors must perform architecture extraction to determine the architecture.

Architecture extraction involves examining the interactions between components, the handling of external inputs, the import of libraries, the implementation of novel ideas, compliance with code standards, and the usage 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, such as lending protocols with components for deposits, loans, fees, income, a price oracle, and liquidation. However, for poorly organized or unconventional projects, auditors may need to manually determine the component structure and relationships through function-by-function and source-file analysis.

It is also important 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 due to the failure to identify and fix the vulnerability. 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:

Once the security requirements have been established, it's time to consider the possible threats. A commonly used model in Web 2.0 to categorize threats is STRIDE, which divides threats into six categories: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. This methodology can be slightly modified for Web 3.0 applications. For instance, 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 60,000 previous findings from more than 3,500 completed audits and identified incidents. Tools test code statically, at both the source code and bytecode levels, and are capable of identifying insecure code patterns and generating diagrams to provide insight into the 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 check that these formulas are true. Key findings from the tools encompass logic issues, reentrancy risks, lack of access controls, overflow/underflow, and gas optimization, among others. 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. The manual review can be divided into two parts: micro-auditing and macro-auditing. Micro-auditing involves analyzing code to understand each function, and this process often reveals bugs. Techniques for micro-auditing include analyzing each argument, variable, and field, reviewing function access levels and state field modifications, and comparing similar functions. On the other hand, macro-auditing involves identifying global vulnerabilities by understanding the project's call/contract hierarchy, searching for state field and function occurrences, and 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.

The process is guided by the architectural review and the "checklist" derived from the threat modeling results. The auditor will adopt both a hacker's and a developer's perspective during the manual code audit. The hacker's mindset will be utilized to uncover any potential vulnerabilities that may be exploited, while the developer's mindset will be used to verify the implementation and identify inefficiencies in the code such as inefficient gas usage and lack of code modularity.

Unit testing will be 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, by providing tailored assessments for the features of each project. The successful completion of tests provides assurance that the code operates according to its intended specifications. For large projects, multiple auditors will be required to complete the work. Auditors will work as a team to establish a plan and assign responsibilities for each person's role in the project. Regular meetings will be held to review progress, discuss findings, and collaborate as necessary. A communication channel will also be established for the purpose of facilitating communication between the client and the audit team.

Our approach to auditing integrates various techniques, including 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 is included that provides definitions and additional information regarding the audit including diagrams and auditor notes. Specific testing done, such as formal verification, will be included in dedicated sections explaining the processes performed and results gathered.

The findings we provide include detailed explanations that identify, categorize, and provide 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. Four distinct written sections accurately detail security considerations. The "Description" section first defines the finding’s context and overviews the security implications. The "Scenario" section follows by walking through the state and steps where an exploit or malfunction would occur. The exploit script and instructions are included in the “Proof of Concept” section with the expected logged output for clients to reproduce the vulnerability. The final “Recommendation” section concludes the findings by providing actionable mitigation steps. These sections provide detailed and targeted information to improve reader’s understanding of the finding. The remediation phase is an ongoing dialogue between the client and auditors that aims to further improve the security of a project. The initial security assessment is provided to the client, who then responds with updated source code or comments. The findings are subsequently updated to reflect any changes made to the code and are published in an updated report. This process repeats until the client is satisfied with the final security assessment. The report is published to clients and publicly available on the Security Leaderboard where community members can view how projects are improving their security rating using CertiK audits and security services.

Summary

In addition to auditing, our security engineers also participate in incident responses, security research, publishing educational and technical blog posts, speaking at conferences, capture the flag competitions, and internal training. They have a diverse range of skills and experience, which gives them a professional understanding of security. They keep themselves updated with the latest industry standards and best practices through ongoing education and research.

CertiK audits have several key features that set them apart from other auditing services. Our custom environments allow auditors to run proprietary tools and custom tests. This ensures that the project's security is thoroughly tested, and any potential vulnerabilities are identified. The level of expertise our auditors have ensures manual review scrutinizes code at the highest level. This ensures that potential issues are identified, even in complex codebases. Finally, CertiK's reports are fully customized to provide solutions to the identified findings. This means that the project's developers are provided with actionable steps to address any vulnerabilities, enhancing the overall security of the project. The purpose of CertiK's audit services is to provide a comprehensive security rating of the project’s code.

While audits provide a baseline security assessment of a project’s code, additional CertiK services further enhance project security. CertiK services such as penetration testing and bug bounties provide extra testing services to further secure projects. Network monitoring is offered through Skynet and 24/7 incident response to protect against active threats. Community transparency is enhanced through the Security Leaderboard and KYC for Web3 project teams. 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 get a better understanding of 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.

Appendix

Read more: https://www.certik.com/resources/blog/VMoH7PVZnTdIqEHK2ZJFc-how-we-audit-a-comprehensive-guide-to-certiks-auditing-methodology

Get the latest news here: Cointime channel — https://t.me/cointime_en