Auditing has always played a vital role in ensuring the security and stability of blockchain projects.
CertiKs team of audit experts has extensive experience and has so far been recognized by 4,000 corporate customers, uncovered more than 70,000 code vulnerabilities, and protected more than $360 billion in digital assets.
CertiKs audit process is comprehensive and thorough, with our security experts scrutinizing a projects design, architecture, and source code for vulnerabilities or risks.
With our security expertise and industry-leading end-to-end security solutions, CertiK continues to lead the security field of the Web3.0 industry, providing security audits from the most basic tokens to the most complex DeFi protocols and even the overall architecture of the blockchain Serve.
But there must be users wondering how we conduct auditing, what is the auditing method, and what are the key auditing features?
Read on, this article can give the answer. The first step in our audit process is to obtain the source code and build a custom environment.
The second step is to review project documents and conduct threat model analysis, followed by internal tools and human audits to find security gaps and design flaws.
The third step is to submit an initial review report containing the identified risks and their recommendations for remediation.
The fourth step is to issue a final audit report, which will describe in detail the help the audit work brought to the project, and show how CertiK audit experts assisted the project in avoiding key Web3.0 vulnerabilities.
Environment configuration
At present, CertiKs auditing and end-to-end security solutions have covered most of the ecosystems currently on the market, and support almost all mainstream programming languages. The ecological chain provides security technical support.
Although projects written in some programming languages may require a very complicated configuration process, this problem can be solved to a certain extent by using a pre-configured virtual machine environment-import the code into the configured environment and check whether it can Successfully compiled and deployed, the environment is set up to enable security experts to run code and write tests to gain a deeper understanding of the project.
Architecture Audit
Determining the projects architecture is critical to understanding key components and parts of the system and safety.
A thorough understanding of the architecture is also essential for effective threat model analysis.
Ideally, the project team will provide a white paper and technical documents outlining the detailed architecture of the project.
In many cases, however, these schema files are missing and auditors must perform schema extraction to determine the schema.
Architecture extraction includes checking interactions between components, handling of external inputs, import of libraries, implementation of new ideas, adherence to coding standards, and support for concurrency.
For common project types such as lending protocols with deposits, loans, fees, income, price oracles, and liquidation components, it may be straightforward to leverage tools to generate call graphs and storage layout graphs to aid in the visualization process.
However, for poorly organized or unconventional projects, auditors may need to manually determine component structures and their relationships by analyzing function and source files one by one.
It is also important to determine whether a project is an original design or a fork of another project. Because the fork will most likely inherit vulnerabilities from its original project -PancakeBunnyThe protocol was hit by a flash loan attack that cost over $40 million, and its source code was forked by multiple other projects, which suffered the same attack due to a failure to identify and fix the vulnerability. But a thorough security audit could have found this vulnerability to avoid such an attack.
Threat Model Analysis
Threat model analysis includes a description of a projects key assets, resources, and security requirements, and it develops a list of potential vulnerabilities and security threats.
Abstract descriptions are established during an architectural audit, and security requirements can be identified by asking and answering questions based on the system architecture. For example, in a governance system, try asking the following questions:
Who can create proposals?
What are the requirements to create a proposal?
What percentage of votes does a proposal need to pass?
How long is the validation period for proposals?
What voting token and mechanism is the project using?
What configurations can a privileged account modify?
Once your security needs have been identified, its time to consider the threats you might face.
In Web2.0, the commonly used threat classification model is STRIDE, which divides threats into six categories: fraud, tampering, repudiation, information leakage, denial of service, and privilege escalation.
This method needs to be slightly modified in Web3.0. For example, in DeFi projects, the source code is verified on the blockchain, and all transaction information and storage data are public, so the threat of information leakage is not that great.
The final result of the threat model analysis will generate a security checklist to guide the security audit and evaluate the security status of the system more comprehensively.
Static Analysis and Formal Verification
We provide security services for Web3.0 through end-to-end security solutions and use CertiKs rich audit experience and technical background.
The tools and services included in the end-to-end security solution are backed by a vast database of thousands of audit histories and more than 70,000 vulnerabilities discovered by CertiK.
Among them, our security tools will statically test the code at the source code and bytecode level, identify unsafe code patterns and generate graphs to provide visual analysis of smart contracts.
These security tools will evolve as the machine learning and smart contract risk environment continues to change, and threat intelligence and smart contract vulnerability libraries continue to accumulate.
In addition to static analysis, we also use formal verification to ensure the safety of the project code and ensure that the program runs according to its expected specifications.
Formal verification is a mathematical proof method for verifying that a computer program works as expected.
It expresses the properties and expected behavior of programs as mathematical formulas, and then uses automated tools to check whether these formulas hold. The process helps ensure their programs behave as expected, with key findings including logic issues, reentrancy risks, lack of access controls, overflow/underflow and gas optimization, and more.
However, the final results need to be manually verified by audit experts to ensure the accuracy of the results.
manual audit
Security tools are indeed powerful but have their limitations, and this is where our team of experienced engineers come into play.
The content of manual audit includes extremely detailed line-by-line inspection of code, which is the most time-consuming step in the entire audit process.
Manual auditing can be divided into two parts: micro auditing and macro auditing.
Micro-auditing involves analyzing the code to understand all functionality, and in the process we often find problems with the code. The techniques covered in this part of the audit include analyzing each parameter, variable, and field, auditing function access controls and modifying state variables, and comparing similar functions.
The macro audit is to identify global vulnerabilities by understanding the call/contract hierarchy of the project, searching for where state variables and functions occur, and checking different hypothetical scenarios.
For example, the causes of critical vulnerabilities are usually not limited to a single function, but may be caused by incorrect interactions between multiple functions located in different parts of the code.
We mentioned above the architecture audit and the security checklist derived from the threat modeling results, and the manual audit process will also refer to these results.
During a manual code audit, the auditor will take the perspective of both the hacker and the developer. The hacker mindset will be used to find potential vulnerabilities that could be exploited, while the developer mindset will be used to verify execution and identify deficiencies in the code, such as inefficient gas usage and lack of code modularity.
We also incorporate unit testing into human audits where necessary.
Unit testing is a security assessment tailored to each projects unique characteristics, including verifying that project components respond correctly to specific inputs, outputs, and edge cases.
If the unit tests run successfully, it means that the code is indeed working according to the expected specification.
For large projects, CertiK will arrange multiple auditors to conduct audits as a team, establish an audit plan and assign corresponding responsibilities, hold regular meetings to discuss audit progress and results, and work together when necessary. In addition, a convenient communication channel will be established between the project and the audit team, so as to communicate about the content of the project audit in the first place.
CertiKs audit methodology integrates security techniques, including static analysis, formal verification, and human audits, to ensure the security of a projects codebase. This comprehensive approach minimizes the risk of security breaches, giving projects full confidence in the correctness and security of their code.
Audit reports and code fixes
Our audit report provides a detailed analysis of the security status of the project, starting with the description of the type of project, the ecosystem and the scope of the audit. These reports explain the methodology and audit methodology we use to assess project security.
To make it easier for readers to understand the safety ratings and terminology in the report, in the appendix section of the report, we provide definitions and other information about the audit, including charts and auditor notes. The specific tests performed (such as formal verification) will be specifically mentioned in the report, explaining the process of their execution and the final results.
Each risk Finding we provide includes identifying, categorizing and providing recommendations for problems found in the project, as well as a detailed explanation of these contents.
Each mined risk Finding includes a title and data such as category, severity, file location, and resolution status.
The next four sections precisely detail the security considerations:
Description: Defines the context of the risk vulnerability and outlines its security impact.
Scenario: Introduces the steps and prerequisites that trigger a vulnerability or cause a project failure.
Proof of Concept: Contains the exploit script and instructions, as well as the expected log output for reproducing the vulnerability on the client side.
Recommendations: Summarizes all findings by providing actionable solutions or fixes.
These sections provide detailed and targeted information for the readers understanding.
During the repair phase, the project team will continue to communicate with the audit team to further improve the security of the project.
The initial review report is issued to the project team, which can then respond with source code updates or comments. We will update the evaluation results based on the responses submitted by the project team, and note the changes they made to the code in the final review report.
write at the end
write at the end
In addition to audit services, CertiKs security engineers are also multi-field skills in threat incident response, security research, publishing educational technology analysis, participating in conferences, capture the flag competitions and internal training. These diverse skills and experiences help to gain a deeper understanding of the security field , and gain a deep understanding of the latest industry standards and best practices through ongoing education and research.
CertiKs audit has several key features that differentiate it from other audit services:
① Our custom environment allows audit experts to run proprietary tools and custom tests. This will ensure that the security of the project is thoroughly and thoroughly tested.
② The professional level of our audit experts can ensure that manual audits can perform detailed code inspections at the highest level. So we can uncover potential vulnerabilities in even the most complex code bases.
③ CertiKs audit report is fully customized to provide risk solutions for the project team. Developers of a project can gain actionable steps to address risks and vulnerabilities, improving the overall security of the project.
The purpose of CertiK Audit Services is to provide a comprehensive security assessment of a projects code. This therefore meant that although the project code received a basic security assessment, there was also a strong need for CertiKs security solutions to further enhance security.
CertiKs end-to-end security solution includes penetration testing, bug bounties, and additional testing services to further ensure the security of projects.
Skynet Skynet systemAnd 24*7 threat incident response can provide projects with on-chain monitoring to prevent malicious exploitation and threats.
Safety Leaderboardand the Web3.0 project teamsKYC due diligenceCan improve community transparency and trust.
CertiKs end-to-end security solution not only provides comprehensive security for projects in static and on-chain operating environments, but also builds trust within the community, allowing users to better understand the risks of the projects they are interacting with— — This is why we make our audit reports public.
It is our mission to improve security standards and transparency across the Web 3.0 industry, some of which are reflected in this article. We expect the future of Web3.0 to be healthy and safe, and we will help it achieve this goal step by step.
