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 will be 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 interactions between components, handling external inputs, importing libraries, implementing novel ideas, complying with code standards, and using 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 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. 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 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/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. In contrast, 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, 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 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 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.
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. 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 then walks through the state and steps in which an exploit or malfunction would occur. The exploit script and instructions are included in the “Proof of Concept” section, along with the expected logged output, so clients can reproduce the vulnerability. The final “Recommendation” section concludes the findings by providing actionable mitigation steps. These sections provide detailed and targeted information to improve the reader’s understanding of the findings. The remediation phase is an ongoing dialogue between the client and auditors to further improve the project's security. 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 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.
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.
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 that 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 the project's developers receive actionable steps to address vulnerabilities, enhancing the project's overall security. 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 secure projects further. Network monitoring is provided 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 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.
Appendix
