Author: Maxgrok
TLDR; Smart contract engineers are required to be more aware of security issues than regular software engineers. They use multiple tactics to address security issues and continually address them throughout the lifecycle of smart contract development.
- Smart Contract Engineers keep up to date with the latest security trends and hacks via Q&A websites (47%), blockchain forums (60%), and research papers (53%) [p. 1416].
- Seventy-two percent of smart contract engineers surveyed used more than one security strategy in smart contract development, including code review, code style checking, reuse of code from reliable sources, and integration of fuzzing into the development lifecycle.
- The most commonly used tools for smart contract security were Mythril (19%), Oyente (12%), SmartCheck (14%), and Slither (12%).
- Future work may seek to do three things:
- (1) systematize smart contract security approaches for the industry;
- (2) identify common smart contract libraries for reuse of snippets of validated and debugged code;
- (3) investigate various blockchains and coding tools through comparative analysis lenses for platform-level vulnerabilities.
Core Research Question
For smart contract engineers, what security practices are common throughout the lifecycle of smart contract development?
Citation
Z. Wan, X. Xia, D. Lo, J. Chen, X. Luo, and X. Yang, “Smart Contract Security: A Practitioners’ Perspective,” 2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE), 2021, pp. 1410-1422, doi: 10.1109/ICSE43902.2021.00127.
Background
- The intended audience of this survey was smart contract auditors who are curious about general tactics. It was not intended to be a rigorous deep dive into methods and software development lifecycles.
- Smart contracts are an appealing decentralized application technology for enabling computation on top of blockchains in response to off-chain events.
- Smart contracts consist of executable code that enforces the terms of an agreement between untrusted parties on a blockchain.
- Smart contracts are plagued with security issues. For example, The DAO was hacked for USD $34 million worth of Ether. (For more information on the latest hacks, please visit the rekt.news site.). Researchers have proposed language-based security, static analysis, and runtime verification to address security issues.
- Academic research, before this article, did not cover practitioners’ tactics for addressing those security concerns.
- Using a mixed-methods approach, the authors conducted 13 qualitative interviews with smart contract engineers and deployed a quantitative survey of 156 smart contract engineers to gather intel on their security practices during development.
Summary
Smart contracts are executable code built on top of blockchains. They are extremely useful for executing agreements between untrusted parties, and promise to be a key enabler of social automation in the 21st century. However, smart contracts remain rife with security bugs that can result in very costly exploits. Smart contract engineers care about protecting their users as well as their companies’ reputation for secure code. The security issue mitigation tactics used most commonly are code reviews, code reuse from reliable sources, and fuzzing tools incorporated into engineers’ continuous integration/continuous development process.
Keeping up to date with security issues is a challenge. The most common sources of information for the latest security news according to the paper are blockchain forums, question and answer websites, and research papers.
Practitioners are using more than one tactic for securing their smart contracts, but are in need of a way to systematize an industry standard approach to security within their development process, as none currently exists. Future work may seek to do three things: (1) systematize smart contract security approaches for the industry, (2) provide common smart contract libraries reused and snippets of helpful code, and (3) investigate the different blockchains as well as different tools through comparative analysis lenses.
Methods
There were two methods used: qualitative interviews (16 participants) and a survey (156 participants) deployed.
- Qualitative Interview Methodology:
- Three categories of questions were asked:
- (1) Asked demographic questions
- (2) Asked open-ended questions about security awareness and practices of smart contract development.
- (3) Asked interviewees to discuss their sources for security-related knowledge, strategies, and tools for smart contract security management.
- Qualitative interviews used to open card sort and determine a list of statements and potential answers for the developing survey questions.
- Survey Methodology:
- Includes multiple-choice and free-text answer questions. Multiple-choice questions derived from qualitative interviews.
- (1) Asked demographic questions
- Do you have experience with smart contracts?
- What best describes the primary blockchain platform you currently work on? Potential answers were: (1) public blockchain (2) consortium blockchain, (3) private blockchain, and (4) other.
- Used 5-point Likert Scale ( strongly disagree, disagree, neutral, agree, strongly agree) to rank the importance of each questions in examining the following categories:
- the importance of security for smart contracts
- security motivators and deterrents
- efforts towards security of smart contracts
- experience of security problems with smart contracts
- sources of security knowledge related to smart contracts
- strategies for addressing smart contract security
- tools used to detect security vulnerabilities in smart contracts
- (1) Asked demographic questions
- Includes multiple-choice and free-text answer questions. Multiple-choice questions derived from qualitative interviews.
Results
- Who took the survey?
- Most respondents were based in China (61 participants) and the United States (16 participants).
- They averaged two years experience with smart contracts per respondent.
- Most respondents to the survey worked on public blockchains (80) such as Ethereum.
- Results are divided into 3 categories:
- (1) Perceptions of Smart Contract Security,
- (2) Security Practices in Smart Contract Development,
- (3) Effect of Blockchain Platforms on Security Perceptions and Practices
These following are the results gained divided into the above 3 categories.
- RQ1: Perceptions of Smart Contract Security:
- Importance of Security
- 85% rated security very important
- 69% rated security extremely important
- Security Motivators
- “I care about smart contract security because…”
- protect users
- protect the reputation of their companies
- “I care about smart contract security because…”
- Security Deterrents
- 40% responded they had had at least one out of three potential security problems:
- vulnerabilities in unshipped code
- vulnerabilities in shipped code
- security breaches
- Security problems occurred when?
- Before code shipped (22%)
- After code shipped (19%)
- Security breach after code shipped (10%)
- 40% responded they had had at least one out of three potential security problems:
- Sources of Security Knowledge
- blockchain forums (60%)
- research papers (53%)
- question and answer website (47%)
- support from professional security experts (47%)
- Importance of Security
- RQ2: Security Practices in Smart Contract Development
- Efforts toward Security
- 29% of time overall developing smart contracts
- 14 respondents indicated that no time was spent on security.
- Strategies for Handling Smart Contract Security
- Efforts toward Security
-
-
- 72% of respondents use more than one tactic for security mitigation
- 72% rely on code review often or very often
- 61% do code style checking
- 58% reuse code from reliable sources
- 28% incorporate fuzzing into the development lifecycle
- Free text answers included:
- Security By Design
- Programming Languages
- Dependency Management
- Learning from Past Experience
- Seeking Support from Experts
- Tools to Address Smart Contract Security
- 54% adopt smart contract security tools in their development
- 45% rely on security plugins in IDEs
- 19% use Mythril
- 12% use Oyente
- 14% use SmartCheck
- 12% use Slither
-
- RQ3: Effect of Blockchain Platforms on Security Perceptions and Practices
- Security Motivators
- practitioners of public blockchains are more motivated to address smart contract security concerns than those of consortium or private blockchains.
- Security Deterrents
- practitioners of public blockchains are more likely to take responsibility for addressing smart contract security
- Security Efforts across Stages
- Practitioners of public blockchains spend more effort towards security throughout the six stages of the development lifecycle
- Security Strategies
- public blockchain practitioners tend to perform code reviews more frequently than consortium or private blockchains
- Security Motivators
Discussion and Key Takeaways
- Smart contracts are more prone to attacks than regular software.
- More frequent code reuse specifically exposes more security risks than in regular software development.
- Most smart contract engineers use more than one method of securing their contracts throughout the lifecycle of their development.
Implications and Follow-Up
- Future work may be standardization and operationalizing the process of building security into smart contracts for practitioners.
- Future studies may include code snippets and smart contract libraries with helpful examples and tools to facilitate library updates.
- Future studies could investigate the differences between blockchains, as well as examine and detail the differences between different tools used for smart contract security.
Applicability
- As a smart contract engineer, more than one method of security smart contracts throughout the lifecycle of development should be used.
- Incorporate code reuse, code review, and fuzzing tools into your development cycle for security best practices, according to this study.
- Security tools most commonly used by smart contract engineers are Mythril, Slither, Oyente, and SmartCheck.
- Be mindful of blockchain platform limitations, language design limitations, and smart contract specific potential attacks as outlined in codified references such as the SWC Registry or the DASP registry.