HACKEN SMART CONTRACT AUDIT METHODOLOGY

Crypto projects should realize the scope of risks associated with smart contracts and know how to address them. The most common threats related to smart contracts are operational, implementation, and design risks. 

No changes can be introduced into a smart contract once it is deployed. 

How does the Smart Contract Audit Help? – Best Practices

Most developers need guidance on how to write secure and high-quality smart contracts. 

The value of Hacken audit methodology for developers:

• Understanding of the audit process and its phases.
• Recommendations on how to ensure secure development of a project. 
• Explanation of the mistakes made by a project.
• Provision of best practices of how to develop a safe code.

Smart Contract Audit is the most robust security solution for the development phase and contract upgrades.

One of the key competitive advantages of Hacken is our transparency. In this material, we would like to share with you a brief overview of the Hacken smart contract audit methodology. Clients should be fully aware of the score of services they get when applying for a smart contract security audit. 

Smart Contract Audit Process – 6 Steps

#1 Preparation for a Smart Contract Audit 

Preparation for an audit is as necessary as the audit itself. 

During the preparation, customers review their projects to make sure everything they have planned is correctly implemented. At this stage, clients themselves can detect many issues. 

To get maximum value from the audit, clients should make the following:

• Prepare functional requirements for the project.
• Prepare a technical description of the project.
• Set up the development environment of the project.
• Prepare unit tests.
• Ensure that code follows best practices and security standards

Functional requirements

Answer the following question: “What do we want to achieve via these smart contracts?”

Functional requirements need to be clear, simple, and unambiguous. 

User stories can be useful as well.

Technical description

Information about the used languages and technologies, deployment instructions, instructions on how to run tests, etc. Non-functional requirements can also be included in this section.

Setup development environment of the project

A development environment for the project should be configured by the Customer. Truffle, Hardhat, or any other comprehensive development environment can be used. A customer should provide a proper description of the environment. An example of the project environment configuration can be found here.

Unit tests

The code should be covered with unit tests. Test coverage should be 100%, with both positive and negative cases covered. Test cases that imitate the usage of contracts by multiple users should be provided to ensure that contracts will not be vulnerable to DoS attacks and that operations of one user do not affect the other unless it is a part of the requirements. The test should be executed on the emulated VM without the need to run local VM’s or connect to testnets.

We recommend using TDD during the development process. 

Security standards

The Customer should ensure that the code is compliant with standards provided by the Ethereum Enterprise Alliance.

#2 Tools for Code review and analysis

Code review and analysis are performed by 2 separate auditors who don’t share results with each other during the initial phase of an audit. Additional review is performed by a lead auditor. All steps of this process:

• Overall review
• Scan by automated tools
• Funds and data flow diagrams
• Line-to-line review
• Checked items
• Analysis of received data

Overall review

2 auditors read the code to understand its structure and purpose and examine functional and technical requirements as well as other documents provided by clients. The main outcome of this step is a high-level description of the code provided by auditors that is used internally during the next steps of the audit.

Scan by automated tools

Automated tools are used to search for simple issues and find more information about smart contracts under review. The following tools are used: 

• Slither – Static analysis of Solidity source code for security vulnerabilities and best practices. 
• Mythril – Reversing and bug hunting framework for the Ethereum blockchain.
• Solgraph – Generates a DOT graph that visualizes the function control flow of a Solidity contract and highlights potential security vulnerabilities.
• Echidna – program designed for fuzzing/property-based testing of Ethereum smart contracts.
• And other proprietary tools.

Funds and data flow diagrams

Auditors visualize all possible states of the contract and all its interactions with other contracts. All changes in data and funds flow should be displayed on those diagrams. 

During this step, some issues can be found and recorded by auditors and they can better understand smart contracts before line-to-line review.

BPMN and UML diagrams are used to visualize funds and data flows

Line-to-line review

Auditors thoroughly read each line of the code and record issues such as the ones described in SWC. We also look for possible data manipulations, access violations, flash loans, and other manipulations that can be performed through the interaction with other contracts. This step also includes validation of the code according to code-style guides and best practices. 

Checked Items

Auditors provide verification of the following items:

#	Item	Type	Description
1	Default Visibility	SWC-100SWC-108	Functions and state variables visibility should be set explicitly. Visibility levels should be specified consciously.
2	Integer Overflow and Underflow	SWC-101	If unchecked math is used, all math operations should be safe from overflows and underflows.
3	Outdated Compiler Version	SWC-102	It is recommended to use a recent version of the Solidity compiler.
4	Floating Pragma	SWC-103	Contracts should be deployed with the same compiler version and flags that they have been tested thoroughly.
5	Unchecked Call Return Value	SWC-104	The return value of a message call should be checked.
6	Access Control & Authorization	CWE-284	Ownership takeover should not be possible. All crucial functions should be protected. Users could not affect data that belongs to other users.
7	SELFDESTRUCT Instruction	SWC-106	The contract should not be self-destructible while it has funds belonging to users.
8	Check-Effect- Interaction	SWC-107	Check-Effect-Interaction pattern should be followed if the code performs ANY external call.
9	Assert Violation	SWC-110	Properly functioning code should never reach a failing assert statement.
10	Deprecated Solidity Functions	SWC-111	Deprecated built-in functions should never be used.
11	Delegatecall to Untrusted Callee	SWC-112	Delegatecalls should only be allowed to trusted addresses.
12	DoS (Denial of Service)	SWC-113SWC-128	Execution of the code should never be blocked by a specific contract state unless it is required.
13	Race Conditions	SWC-114	Race Conditions and Transactions Order Dependency should not be possible.
14	Authorization through tx.origin	SWC-115	tx.origin should not be used for authorization.
15	Block values as a proxy for time	SWC-116	Block numbers should not be used for time calculations.
16	Signature Unique Id	SWC-117SWC-121SWC-122EIP-155	Signed messages should always have a unique id. A transaction hash should not be used as a unique id. Chain identifier should always be used.
17	Shadowing State Variable	SWC-119	State variables should not be shadowed.
18	Weak Sources of Randomness	SWC-120	Random values should never be generated from Chain Attributes or be predictable.
19	Incorrect Inheritance Order	SWC-125	When inheriting multiple contracts, especially if they have identical functions, a developer should carefully specify inheritance in the correct order.
20	Calls Only to Trusted Addresses	EEA-Level-2 SWC-126	All external calls should be performed only to trusted addresses.
21	Presence of unused variables	SWC-131	The code should not contain unused variables if this is not justified by design.
22	EIP standards violation	EIP	EIP standards should not be violated.
23	Assets integrity	Custom	Funds are protected and cannot be withdrawn without proper permission.
24	User Balances manipulation	Custom	Contract owners or any other third party should not be able to access funds belonging to users.
25	Data Consistency	Custom	Smart contract data should be consistent all over the data flow.
26	Flashloan Attack	Custom	When working with exchange rates, they should be received from a trusted source and not be vulnerable to short-term rate changes that can be achieved by using flash loans. Oracles should be used.
27	Token Supply manipulation	Custom	Tokens can be minted only according to rules specified in a whitepaper or any other documentation provided by the customer.
28	Gas Limit and Loops	Custom	Transaction execution costs should not depend dramatically on the amount of data stored on the contract. There should not be any cases when execution fails due to the block gas limit.
29	Style guide violation	Custom	Style guides and best practices should be followed.
30	Requirements Compliance	Custom	The code should be compliant with the requirements provided by the Customer.
31	Environment Consistency	Custom	The project should contain a configured development environment with a comprehensive description of how to compile, build and deploy the code.
32	Secure Oracles Usage	Custom	The code should have the ability to pause specific data feeds that it relies on. This should be done to protect a contract from compromised oracles.
33	Tests Coverage	Custom	The code should be covered with unit tests. Test coverage should be 100%, with both negative and positive cases covered. Usage of contracts by multiple users should be tested.
34	Stable Imports	Custom	The code should not reference draft contracts, that may be changed in the future.

Each item can have one of the following statuses: Passed, Failed, Not Related.

#3 Testing

If unit tests are configured for the project, auditors check coverage and write their own test cases if required. Ideally, code coverage should encompass all positive and negative cases. Some issues can be reproduced with the invalid config of dependency contracts. Auditors create such configs and run corresponding tests. 

If unit tests are not configured, auditors deploy smart contracts on the local network and check all required cases. 

Some sophisticated issues require complex exploiting contracts. Usually, if it is unclear how the issue can be exploited, auditors provide the sample attacking contracts. 

#4 Reporting 

Both auditors review their findings and audit artifacts and share results with each other. All disputable points in the code are discussed internally with the team. Auditors prepare materials for the report. Lead auditor reviews all materials prepared by the two other auditors and performs his own code review. Most possible issues are already documented at this step.

After all code review, analysis, and tests, auditors prepare a report with the following structure:

• Introduction
• Scope
• Executive Summary
• Severity Definitions
• Findings
• Recommendations
• Disclaimers

#5 Bug fixing

All issues are reported to the Customer in a draft report. If some points are unclear, we can provide more descriptions of issues or explain everything on a call.

The customer can receive one free remediation check when:

• No more than 15% of all code has been changed. 
• The fixes have been introduced within 10 business days
• The code structure has not been changed. Except for the situation when a recommendation was provided by auditors.
• The customer describes all changes introduced to the code.
• The code contains only fixes of issues described in the Audit overview section of the report.

After all fixes are validated, the final report is provided to the customer.

#6 Scoring

The score contains several metrics: 

• Documentation quality (D)
• Code quality (C)
• Architecture quality (A)
• Security level (S)

Each metric has its own weight in the total score. The score has a decimal value with 1 decimal point. The score may vary between 0.0 and 10.0.

Maximum weights of each metric:

• D – 1.0
• C – 1.0
• A – 1.0
• S – 7.0

Documentation quality

The project code should be provided with corresponding documentation. Functional and technical requirements are required. 

Functional and technical requirements’ total weight is 5.0 each. The weight in the overall score is 1.0.

Code quality

The code should follow official language style guides and be covered with unit tests. If most of the code follows those guides, the score is 3. Partially follows – 2.5. Not follows – 0.0.

Test coverage has a maximum weight of 7.

The weight in the overall score is 1.0. 

Architecture quality

Smart contracts of the project should follow the best practices. 

Clean and clear architecture and well-configured development environment – 10.

The weight in the overall score is 1.0.

Security level

The most important metric of the score. 

Issues have 4 levels of severity: critical, high, medium, and low. Only actual issues are considered in the score calculation. Actual issues have the following statuses: “new” and “reported” (previously “acknowledged”).

Each critical, high, and medium issue decreases the score:

• Minus 10 per critical.
• Minus 5 per each high.
• Minus 1 per each medium.

The minimum score is 0, maximum is 10.

The weight in the total score is 7.0.

Total Score Calculation

The total score calculation formula is D+C+A10+S710

Overall, a smart contract audit is an essential form of security testing for Web 3.0 projects allowing them to win users’ trust and confidence that their assets are in safety. Hacken smart contract audit methodology has been developed with regard to the deep expertise of our security engineers. We keep on improving this methodology to deliver a better quality of security services to clients. Only when cybersecurity grows faster than malicious hacking, then we can say “Web 3.0 is becoming a safer place”.