Available online at www.sciencedirect.

com

Procedia Computer Science 00 (2018) 000–000

www.elsevier.com/locate/procedia

The 14th International Conference on Emerging Ubiquitous Systems and Pervasive Networks
(EUSPN 2023)
November 7-9, 2023, Almaty, Kazakhstan

ContractArmor: Attack Surface Generator for Smart Contracts

Ferda Özdemir Sönmeza,∗, William J. Knottenbelta
a Imperial College of London, Department of Computing, South Kensington Campus, London, SW7 2AZ, UK

Abstract
This paper presents an ongoing study of a novel attack surface generator tool for smart contracts developed in Solidity. The tool
leverages a rule-based engine and ChatGPT API for security analysis. The rule-based engine provides numerical values and key
variables and functions for further analysis, while ChatGPT handles complex queries. However, ChatGPT may generate similar
responses for more general questions, irrespective of the given contract code. The tool combines both approaches to identify and
mitigate potential security vulnerabilities in Solidity-based smart contracts. The effectiveness of the tool is evaluated on real-world
smart contracts, and its potential for detecting and preventing common attack vectors is demonstrated.

© 2018 The Authors. Published by Elsevier B.V.

This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/)
Peer-review under responsibility of the Conference Program Chairs.

Keywords: Attack Surface; Rule-Based Analysis; ChatGPT; GPT-3; DaVinci; Security Analysis; Smart Contract

1. Introduction

An attack surface is a term used to describe the points of entry or vulnerabilities in a system that an attacker can
exploit to gain unauthorized access or perform malicious activities. The attack surface can be thought of as the sum of
all the interfaces through which an attacker can potentially enter or disrupt a system. It includes all the possible attack
vectors such as attack vectors related to network connections, software components, user interfaces, and data storage.
In general, the larger the attack surface, the greater the risk of a security breach. Therefore, it is important for orga-
nizations to identify and assess the attack surface of their systems in order to reduce the risk of attack. This involves
identifying all the components, interfaces, and data flows in a system, and assessing the potential risks associated with
each. Attack surface analysis is an important part of the overall security process. It can help organizations understand
the potential threats and vulnerabilities of their systems, and inform decisions about the selection of appropriate se-
curity controls or the allocation of security resources. By reducing the attack surface, organizations can minimize the
number of potential attack vectors and make it more difficult for attackers to gain unauthorized access.

∗ Corresponding author. Tel.: +0-000-000-0000 ; fax: +0-000-000-0000.

E-mail address: f.ozdemir-sonmez@imperial.ac.uk

1877-0509 © 2018 The Authors. Published by Elsevier B.V.

This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/)
Peer-review under responsibility of the Conference Program Chairs.
2 Author name / Procedia Computer Science 00 (2018) 000–000

The concept of attack surface is also crucial when it comes to decentralized autonomous organizations (DAOs).
Decentralized Autonomous Organizations (DAOs) are built using smart contracts and can encapsulate decentralized
applications (dApps), while also being dApps themselves. In a broader sense, attack surface calculation includes the
identification of both hardware and software components. However, in the case of dApps having blockchain-supported
smart contracts, the authors’ thinking is that the identification of an attack surface can be limited to delving into details
of software components. This is due to the existence of hardware components consisting of a distributed network with
computing devices belonging to different individuals or groups. The focus can be extended by identifying the types
of blockchain, such as public, private, and consortium, as well as the number and types of users interacting with the
dApps along with the analysis of software components.
Examining the code of a smart contract is an industry-standard approach to improving its security and privacy.
The outputs generated can be used for further security analysis, though it is important to keep in mind that smart
contracts rely on distributed networks to operate, and any weakness or vulnerability in the network can be exploited
by attackers. Therefore, while code examination can help to improve the security and privacy of smart contracts and
their associated dApps [27] and DAOs [4], it is important to also consider other aspects of the system, such as network
architecture, wallets, and authentication and access control, to ensure comprehensive security measures.
In summary, understanding and assessing the attack surface of smart contracts is critical to reducing the risk of
attack and improving the overall security posture of blockchain supported software. By identifying potential vulnera-
bilities and attack vectors, organizations can take proactive measures to secure their smart contracts and protect their
assets from attackers.
Smart contracts typically have components in two categories: off-chain and on-chain components. Off-chain com-
ponents refer to the code running outside of the blockchain network, while on-chain components refer to the code
running on the blockchain network. While the generation of off-chain attack surfaces can be conducted using tradi-
tional methods, such as using static analysis [19], or threat modeling [3] tools for off-chain platforms, the generation
of on-chain attack surfaces should be specific to the smart contracts and even can be more specialized for differ-
ent blockchain technologies. To generate the on-chain attack surface, it is essential to consider the unique features
of smart contracts, such as their decentralized and autonomous nature, as well as their ability to execute complex
business logic.
This paper introduces a novel tool, ContractArmor. This is part of an ongoing academic investigation, and the
results presented here represent initial experimental findings. Further refinement and validation will be conducted in
future iterations of the study. This tool encapsulates a rule based engine to examine smart contract codes for specific
code features and a communicator module which enables Q/A (Question/Answer) towards OpenAI ChatGPT
The rest of the paper is organised as follows. Section 2 provides a background on attack surface concept and
its specific meaning for smart contracts. Section 3 is dedicated to the proposed system design and implementation.
Section 4 describes the experiments and results. Finally, Section 5 concludes.

2. Background

2.1. Attack Surface

The attack surface of a system refers to the potential entry points or vulnerabilities that an attacker can exploit
to gain unauthorized access, manipulate data, or disrupt the system’s operation. While ”Attack Surface” term has
been emerged via Microsoft’s Trustworthy Computing discussions [20] and has been part of Security Development
Lifecycle (SDL) [22], it is origin goes beyond that. The term was first used informally in an MSDN Magazine article
by Howard[7] as a measure or computer risk assessments. Attack surfaces were initially used to identify the security
risks of Windows operating systems. These measurements depended on ad-hoc methods and would require security
experts who have in-depth knowledge on the targeted systems. A variety of definitions have been emerged for attack
surfaces in time. At the same time, as the use of this method has become more common, different approaches have
emerged to automate it.
 Author name / Procedia Computer Science 00 (2018) 000–000 3

2.2. Attack Surface Generation

There are various ways of generating attack surfaces for different kinds of systems/applications some of which are
listed below.
Manual inspection and analysis of the system’s architecture, components, and interfaces: This involves a thorough
examination of the system’s structure and its various components, their functionality, and how they interact with each
other [6]. This approach can be used for both small and large projects. For large projects, manual inspection would
potentially include manual inspection of automatically generated reports or graphs [5].
Threat modeling: Threat modeling is a structured approach to identify, analyze, and prioritize potential threats
and vulnerabilities of a system. It is usually done early in the development process to inform design decisions and
security requirements. This approach is useful for both small and large systems and is widely used in software devel-
opment [16]. Fuzz testing: Fuzz testing involves feeding random or malformed input to a system to trigger unexpected
behavior or crashes. This approach is particularly effective in identifying vulnerabilities in network protocols, file
formats, and web applications. It is widely used in software development and security testing [15]. Penetration test-
ing: Penetration testing involves simulating a real-world attack on a system to identify vulnerabilities and assess the
effectiveness of existing security controls. This approach is typically used for large systems and is often conducted
by third-party security experts [28]. Red teaming: Red teaming involves simulating an attack on a system to identify
vulnerabilities and test the effectiveness of the organization’s defensive capabilities. This approach is typically used
for large organizations and involves a team of experienced security professionals. [25] Reverse engineering: Reverse
engineering involves analyzing a system’s code or firmware to understand its behavior and identify vulnerabilities.
This approach is particularly useful in identifying vulnerabilities in embedded systems, such as IoT devices and in-
dustrial control systems [11]. Threat intelligence: Threat intelligence involves gathering and analyzing information
about potential threats and vulnerabilities to a system. This approach is particularly useful for large organizations with
complex systems and networks [10]. Social engineering: Social engineering involves exploiting human vulnerabilities
to gain access to a system or network. This approach is particularly effective in bypassing security controls and is often
used to detect potential risks of phishing attacks and other types of social engineering attacks [23]. Baseline testing:
Baseline testing involves establishing a baseline of normal system behavior and then monitoring for deviations from
that baseline. This approach is useful in detecting abnormal behavior that may be indicative of a security breach [33].
Automated vulnerability scanning: Automated vulnerability scanning involves using software tools to scan a system
for known vulnerabilities. This approach is particularly useful in identifying vulnerabilities in large systems and is
often integrated into continuous integration/continuous deployment (CI/CD) pipelines [26].

2.3. Attack Surface Analysis for Smart Contracts

The security threats towards blockchain related systems include but not limited to threats towards the blockchain
structure, threats towards consensus system, threats towards wallet systems, and threats towards smart contracts[1].
Attack surface analysis is critical in identifying and mitigating security risks in software systems, particularly in
decentralized systems like smart contracts, which are often publicly available on the blockchain. Smart contracts,
which are self-executing contracts with the terms of the agreement between buyer and seller being directly written into
code, are gaining popularity for their ability to automate business processes and transactions without intermediaries.
However, the decentralized nature and open-source code of smart contracts make them vulnerable to various types of
attacks, including reentrancy attacks, overflow attacks, and logic errors, among others.
Among the security best practices for smart contracts, auditing has a great importance. However, since manual
auditing is a time taking process, developers may ignore this step entirely, or auditing may not be given due consid-
eration and time, launching projects with security issues[29]. Using secure, known libraries as a part of code design
is another popular best practice, which is very useful. OpenZeppelin [30] is the most well-known company which
provides open source smart contracts. Other alternatives include but not limited to DappSys [31], and HQ20 [17].
This approach has an significant effect in creating secure contracts, diminishing the attack surfaces.
Use of automatized tools for security analysis of smart contracts is also inevitable and very useful to identify
the security problems. These tools can be grouped into multiple categories. There are dynamic analysis tools which
are used after deployment. The tools in this category include transaction visualization and monitoring tools and on-
chain defense tools provided that the contracts uses predefined API sets. There are also pre-deployment security
4 Author name / Procedia Computer Science 00 (2018) 000–000

Fig. 1. System components

analysis tools. Static code analyzer tools is the most important and popular group because it aids finding the security
problems or risks before going in live. This is particularly important for smart contracts because once deployed,
the modifications that can be made would be limited and may not be practical if not impossible depending on the
implementation details. Several tools related to smart contract vulnerability analysis relying on static code analysis
are Verisol [9], Oyente‘[21], Slither [14], and Mythril [24]. These tools work with either Solidity code or bytecode.
These tools can be used individually or as part of a framework that encapsulates and processes outputs from multiple
tools, as described in [32]. The various results offered by existing tools can be utilized for conducting an attack surface
analysis on individual or multiple smart contracts. The tool presented in this study belongs to the same category and
can be used to supplement the results of other tools.
Recently, some studies focused directly on generating attack surfaces or attack detection for smart contracts. Block-
Eye [34] is a one these experimental studies which focus on specifically on Oracle usage. It works in two phases, in
the first phase it uses symbolic analysis to find out use of Oracles, in the second phase a transition monitoring tool is
used to to detect Oracle related transitions. Seraph [35] is another prototype which uses symbolic execution over the
compiled contracts.
Contribution of the current study to the field involves the integration of a rule-based engine and a state-of-the-
art auto-regressive language model. Although there have been recent attempts to utilize ChatGPT for smart contract
vulnerability detection [36], [37], this paper not only focuses on a single study but also on a series of questions. This
approach provides insight into the capabilities of ChatGPT for various questions with different levels of difficulty and
answer types that require varying levels of creativity. Furthermore, this paper attempts to train ChatGPT for specific
question types and provides feedback on the results of these efforts. The combination of rule based engine and the use
of ChatGPT enables the system to provide both deterministic responses and human-like responses, offering a more
comprehensive experience and the ability to use both response types simultaneously. The approach improves upon
existing models by leveraging the strengths of both rule-based and AI-based systems, resulting in a more effective and
flexible approach.

3. Proposed System

The prototyped attack surface detection tool for smart contracts is implemented using the Python language and has
a clear purpose of identifying software features that could be associated with risks. It is important to note that this
tool is not intended to be used as a detailed security analysis tool for smart contracts but can be evolved towards that
direction. The attack surface definition for this tool is divided into three groups. The first group includes components
that are accessible in an unauthorized manner, with a focus on identifying vulnerabilities related to function and
variable visibilities. In addition to grouping functions and variables based on their visibilities, the tool also presents
variables with address type separately. This is because these variables play a crucial role in accessing other smart
contracts or exchanging assets, and any vulnerabilities associated with them that could lead to serious consequences.
The second group aims to identify the use of critical functions and data types such as cryptocurrencies and tokens.
The third group aims to answer more complex questions. In summary, it focuses on: the visibility of functions, the
visibility of variables, the use of specific variables types (such as addresses), the use of security critical functions, the
transfer of assets, the use of deprecated functions, the use of tokens and cryptocurrencies, the use of mathematical
functions, and identification of more complex risks such as Reentracy.
As a result of the examination, the tool also aims to provide: 1-existing implementation details in the code that
specifically address or prevent security problems, and how effective they are, 2- existing measures taken to prevent
unauthorized access to data or functions, and how effective they are, 3- recommendations to improve the security and
reliability of the code.
 Author name / Procedia Computer Science 00 (2018) 000–000 5

Fig. 2. Fine tuning inputs

By focusing on these critical components, the proposed tool can help developers identify potential risks and take
appropriate measures to mitigate them. It provides a comprehensive analysis of the smart contracts’ attack surface
and help developers identify potential vulnerabilities. The figure 1 shows the top-level system components of the
implemented prototype.

3.1. Technical Details

•Pre-processing: No pre-processing was performed on the source code other than filtering the Solidity files among
a larger set of files. However, as a future work, removal of unnecessary code parts such as comments can be tried which
would reduce the number of tokens in the first place. •Rule-based examination: For rule-based examination, Solidity-
parser package has been used along with predefined rules to snap security critical code properties. In the first version,
functions and variables are focused leaving events for future releases. The first version builds the structure which
enables checking various rules towards the code. Initial release has simple checks, in later releases more complex
rules would be implemented on top of the current structure by also including detailed examination of events. •Training:
The model is based on GPT-3 which is an auto-regressive language model released in 2020 that uses deep learning
to produce human-like text responses. GPT-3 was already trained using about 45TB of data from different datasets.
•Refinement: At the start of the process, the authors decided on a set of questions which has been refined later so
as to allow focus on the current code and not general knowledge. In the future releases, the question set will be
further refined by changing some questions from open-ended to multiple-choice type. •Fine-tuning At the start of
the implementation no fine-tuning was made on the model itself. Afterwards, a small fine-tuning data set is created
focusing on repeatedly incorrect or meaningless answers. This set is used to further pre-train the GPT-3 Davinci model
before the Q/A session. •Input fine-tuning Due to token length limitations of OpenAI, some input tuning, Figure 2, is
also made to stay in the limits, while providing enough information for the Q/A session to last.
Current questions set is created with an aim to provide sufficient information to continue on further security analy-
sis. As a future work, a dynamic set of questions can be created through using outputs from the rule-based examination.
This approach may help to fine-tune the response set and obtain more accurate and targeted results.

4. Experiments and Results

As a part of experiments, the tool is used to analysis several projects. Only the summary of the results from
examining open source Wormhole Project’s source code is presented due to size restrictions of the paper. Wormhole
project consisted of 59 Solidity files, with one or more contracts in each file. The full set of examined contracts and
automatically generated results are available on https://github.com/author1/ContractArmor. By using the rule based
analysis we were able to identify security critical functions and variables for the given contract set. By using OpenAI
API, we were able to generate detailed responses to these questions. However, depending on the complexity of the
required analysis, the quality and the correctness of the responses are varied. While the overall analysis helps us to
6 Author name / Procedia Computer Science 00 (2018) 000–000

gain a deeper understanding of the smart contract code and identify potential areas of concern, due to reliability issues,
particularly related to ChatGPT generated answers, the analysis results should be taken in caution.
Table 1 shows the full question set and Table 2 presents the summary of an informal evaluation of the answers given
to these questions. No structured or rigorous method is taken for the answers analysis, rather an intuitive approach
is taken to evaluate automatically generated responses. Two criteria are chosen as below. Although, lengths of the
answers are also critical regarding the usability and the depth and breadth of the knowledge presented, this criteria
is excluded in the initial evaluations. Because the length is immensely dependent on the selected parameters, such as
temperature, max-token, frequency, and existence penalties on each call. These parameters were changed during the
experiments and need to be further improved along with the question sets.:

• ‘Correctness of Answers’ evaluates the accuracy and reliability of the information provided in the answers. It is
an essential parameter for evaluating the quality of answers, as accuracy is crucial in security analysis.
• ‘Usefulness of Answers’ evaluates the practical value of the information provided in the answers. It assesses
whether the answers are relevant, applicable, and beneficial to the question or problem being investigated.

As described in Table 2 some of these answers are not correct or meaningful. As a future work, this prototype will
be improved to include more training related to security problems of smart contracts. Some other models, such as
GPT-4 [18] will also be used as they become accessible in the future.
Examination of the results show that: •ChatGPT could answer some of the simple questions such as Q6, Q7
and Q8 with some degree of correctness. This maybe further improved by creation of training data specific to these
question types. •However, repeatedly failed to answer another simple question Q1, counting all the inherited contracts
separately for a source file. •Fine-tuning data prepared focused on a limited set of questions. For example, for Q1, we
were able to teach how to count and name the smart contracts from a file (which we already could do via our rule-based
processing). •The authors also tried to fine-tune for questions Q4, Q5, and Q9 providing variations of sample code
parts related to these. However, the results are very low quality due to insufficient training data set which causes under-
fitting. •After the fine tuning, we also encountered deteriorated quality on some responses, such as Q10 and Q11. The
reason for this is the incorrect approach to fine-tuning for these question types which require general research without
looking for anything specific unlike Q4 and Q5. •The answers to questions like Q12 were correct before fine-tuning
but not specifically associated with given code but included general practices, after fine tuning, the answers became
more code related but less meaningful. •Answers to questions such as Q2, Q3, Q10, and Q11 had low quality in
all trials even after refinements. Thus, the authors decided to divide those questions into multiple questions which
also include multi-choice question types. For example for Q2, refined questions included: A)‘Are there any inherited
contracts?’, B)‘Are there any library functions used in the contract?’, C)‘What is the purpose of this smart contract
code? You may choose multiple options: a) Acts as an adaptor b) Acts as a bridge between multiple chains c) Defines
structures for use by other contracts d) Defines a cryptocurrency or token e) Contains complex business requirements
f) Serves as a factory contract g) Acts as an interface/template for other contracts h) Automates the execution of
legal agreements i) Manages the distribution of rewards or incentives j) Implements a decentralized autonomous
organization (DAO) k) Provides a secure and transparent way to track and verify supply chain information l) Enables
prediction markets m) Facilitates the exchange of digital assets or non-fungible tokens (NFTs) n) Enables the creation
of a decentralized social network o) Establishes reputation or identity systems p) Supports DeFi applications q) Acts
as a storage contract to store data.’ •Constructing training data for ChatGPT’s supervised training on complex issues is
challenging, requiring multiple smart contract variations. Data for a few options on question C was created. However, a
multi-choice format with numerous options was unsuitable for ChatGPT.•The current experiments showed that GPT-3
is not trained enough to make detailed analysis on smart contracts in Solidity language and lacks necessary knowledge
on language terminology, structures, and best practices. •Independent of the questions, specially on high temperature
runs which leads highly creativity for the AI model, the model creates new questions and answers them automatically.
In general, the answers are not either correct or useful, however, the creatively generated questions points out a totally
different use-case. The question sets given the source codes are beyond the thinking of human-beings and can improve
manual security auditing sessions. •Finally, the results showed that the model parameters should also be dynamically
changed (unlike current implementation) based on the examined source file size and content, question type, and the
desired level of complexity and length for each answer.
 Author name / Procedia Computer Science 00 (2018) 000–000 7

Table 1. Set of Questions

# Question
Q1 How many distinct smart contracts does this code contain?
Q2 What are the intended functions of the smart contracts in this code?
Q3 Are there any data or functions in this code that are not properly secured and may be vulnerable to unauthorized access or exploitation?
Q4 Is there any risk of a reentrancy attack in this code, where an untrusted contract could make multiple calls to a vulnerable contract, resulting
in unintended behavior?
Q5 Are there instances of unsafe self-destruct function use in the code, leading to potential security vulnerabilities?
Q6 Are there any mathematical functions used in this code that may be susceptible to integer overflow vulnerabilities or other security risks?
Q7 Are there any deprecated functions or features used in this code, and if so, what is the recommended alternative?
Q8 What cryptocurrencies or tokens are involved in this code, and what is their purpose?
Q9 Are there any external interfaces or protocols used in this code, and if so, what are they and how are they secured?
Q10 What measures have been taken to prevent unauthorized access to data or functions, and how effective are they?
Q11 Identify existing implementation details addressing security problems and assess their effectiveness?
Q12 Recommend improvements for code security and reliability based on best practices and industry standards?

Table 2. Evaluation of Answers

# Correctness of Answers Usefulness of Answers
Q1 The answers improved to be more correct after fine tuning. The answers are helpful but lengthy.
Q2 For this question both open ended and multi-choise responses are tried. Overall results are not very The answers were not useful.
correct.
Q3 ChatGPT identifies certain functions and data while inventing others. Its unique approach offers Somehow useful.
creative insights for manual auditing.
Q4 Due to low number of training data for this question ChatGPT makes up functions and a bit con- Provides partial guidance on reen-
fused although some of the comments are still correct. trancy mitigation, but not specific to
the code.
Q5 Same issue existed as in the previous question. ChatGPT makes up non-existent self-destruct func- Same as previous question.
tions.
Q6 No fine-tuning is made with the expectation of inherent capability to identify mathematical func- No useful answers were achieved.
tions. The answers are not correct, however, authors believe that the model can be trained for this
question type.
Q7 Same as previous question. Same as previous question.
Q8 The model can identify cryptocurrencies and tokens with a level of correction without the distinc- Somehow useful when it is correct.
tion of interfaces and contracts.
Q9 The model does not identify external calls in its current form but in authors’ opinion can be taught Currently, not useful.
to do so.
Q10 ChatGPT makes up protection systems that do not exist in the code and that are not even related to Not useful.
the Solidity language.
Q11 This question is difficult and ambiguous in its current form. This should be improved by dividing Not useful.
into multiple multi-choice questions.
Q12 The correctness varied and may not be specific to the given code. Answers are in general useful.
*The evaluation comments represent majority of the results not all.

5. Conclusion

In conclusion, this paper introduced a novel approach for gathering security analysis results with a focus on attack
surface generation for smart contracts. The deterministic results obtained from the experiments proved to be valuable
and can be further improved by adding more metrics. Although gathering AI-based results is a more complex and
time-consuming process, the implemented prototype and experiments provided valuable insights into how to structure
and refine question sets, conduct Q/A sessions, and fine-tune models for specific question types.
Additionally, the experiments demonstrated the capabilities of the current model for smart contract security analy-
sis, the challenges and requirements for fine-tuning, and the parameters needed to achieve improved results. As newer
AI models become available, these experiments can be repeated and improved upon with updated prototypes. Overall,
the findings of this paper provide a valuable contribution to the field of smart contract security analysis and can serve
as a starting point for future research.

Acknowledgements

Research supported by Brevan Howard Centre for Financial Analysis.

References

[1] Muhammad Saad, Jeffrey Spaulding, Laurent Njilla, Charles Kamhoua, Sachin Shetty, DaeHun Nyang, Aziz Mohaisen. (2019) ”Exploring the
attack surface of blockchain: A systematic overview.” arXiv preprint arXiv:1904.03487.
 8 Author name / Procedia Computer Science 00 (2018) 000–000

[2] Zhuoming Gu, Dan Lin, Jiajing Wu. (2022) ”On-chain analysis-based detection of abnormal transaction amount on cryptocurrency exchanges.”
Physica A: Statistical Mechanics and its Applications, 604: 127799.
[3] Wenjun Xiong, Robert Lagerström. (2019) ”Threat modeling–A systematic literature review.” Computers & Security, 84: 53–69.
[4] Shuai Wang, Wenwen Ding, Juanjuan Li, Yong Yuan, Liwei Ouyang, Fei-Yue Wang. (2019) ”Decentralized autonomous organizations: Con-
cept, model, and applications.” IEEE Transactions on Computational Social Systems, 6 (5): 870–878.
[5] Nuthan Munaiah and Andrew Meneely. “Beyond the Attack Surface.” (Year unknown).
[6] Ferda Özdemir Sönmez. “Security Qualitative Metrics for Open Web Application Security Project Compliance.” Procedia Computer Science,
vol. 151, pp. 998–1003, 2019.
[7] Michael Howard. (2004) ”Fending Off Future Attacks by Reducing Attack Surface. February 2003.” Was available via
http://msdn.microsoft.com/en-us/library/ms972812.aspx.
[8] Christopher Theisen, Nuthan Munaiah, Mahran Al-Zyoud, Jeffrey C Carver, Andrew Meneely, Laurie Williams. (2018) ”Attack surface defi-
nitions: A systematic literature review.” Information and Software Technology, 104: 94–103.
[9] Yuepeng Wang, Shuvendu K Lahiri, Shuo Chen, Rong Pan, Isil Dillig, Cody Born, Immad Naseer, Kostas Ferles. (2020) ”Formal verification
of workflow policies for smart contracts in azure blockchain.” In Verified Software. Theories, Tools, and Experiments: 11th International
Conference, VSTTE 2019, New York City, NY, USA, July 13–14, 2019, Revised Selected Papers 11, pp. 87–106. Springer.
[10] Sagar Samtani, Maggie Abate, Victor Benjamin, Weifeng Li. (2020) ”Cybersecurity as an industry: A cyber threat intelligence perspective.” In
The Palgrave Handbook of International Cybercrime and Cyberdeviance, pp. 135–154. Springer.
[11] Yangyang Geng, Yuqi Chen, Rongkuan Ma, Qiang Wei, Jie Pan, Jingyi Wang, Peng Cheng, Qingxian Wang. (2022) “Defending cyber-physical
systems through reverse engineering based memory sanity check.” IEEE Internet of Things Journal.
[12] Jacob G Oakley. (2019) ”Professional Red Teaming: Conducting Successful Cybersecurity Engagements.” Apress.
[13] Pete Rotella. (2018) “Software security vulnerabilities: baselining and benchmarking.” In Proceedings of the 1st International Workshop on
Security Awareness from Design to Deployment, pp. 3–10.
[14] Josselin Feist, Gustavo Grieco, and Alex Groce. “Slither: A Static Analysis Framework for Smart Contracts.” In Proceedings of the 2019
IEEE/ACM 2nd International Workshop on Emerging Trends in Software Engineering for Blockchain (WETSEB), pp. 8–15, 2019. IEEE.
[15] George Klees, Andrew Ruef, Benji Cooper, Shiyi Wei, Michael Hicks. (2018) ”Evaluating fuzz testing.” In Proceedings of the 2018 ACM
SIGSAC conference on computer and communications security, pp. 2123–2138.
[16] Adam Shostack. (2014) ”Threat modeling: Designing for security.” John Wiley & Sons.
[17] HQ20. (2023) ”HQ20.” HQ20. [Online]. Available from: https://github.com/HQ20 [Accessed 19th March 2023].
[18] Gerardo Adesso. (2022) ”GPT4: The ultimate brain.” Authorea Preprints. Authorea.
[19] Darko Stefanović, Danilo Nikolić, Dušanka Dakić, Ivana Spasojević, Sonja Ristić. (2020) “STATIC CODE ANALYSIS TOOLS: A SYSTEM-
ATIC LITERATURE REVIEW.” Annals of DAAAM & Proceedings, 7 (1).
[20] John Viega. (2011) ”Ten Years of Trustworthy Computing: Lessons Learned.” IEEE Security & Privacy, 9 (5): 3–4.
[21] Loi Luu, Duc-Hiep Chu, Hrishi Olickel, Prateek Saxena, and Aquinas Hobor. “Making Smart Contracts Smarter.” In Proceedings of the 2016
ACM SIGSAC Conference on Computer and Communications Security, pp. 254–269, 2016.
[22] Bruce Potter. (2009) ”Microsoft SDL threat modelling tool.” Network Security, 2009 (1): 15–18.
[23] Z. Wang, L.n Sun, and H. Zhu. “Defining Social Engineering in Cybersecurity.” IEEE Access, vol. 8, pp. 85094–85115, 2020. IEEE.
[24] Ayman Alkhalifah, Alex Ng, Paul A Watters, and ASM Kayes. “A Mechanism to Detect and Prevent Ethereum Blockchain Smart Contract
Reentrancy Attacks.” Frontiers in Computer Science, vol. 3, p. 598780, 2021. Frontiers Media SA.
[25] Jacob G. Oakley. Professional Red Teaming: Conducting Successful Cybersecurity Engagements. Apress, 2019.
[26] ASAM Al-Ghamdi. ”A survey on software security testing techniques.” International Journal of Computer Science and Telecommunications,
vol. 4, pp. 14–18, 2013.
[27] Lodovica Marchesi, Michele Marchesi, Roberto Tonelli. ”ABCDE—Agile block chain DApp engineering.” Blockchain: Research and Appli-
cations, vol. 1, no. 1-2, pp. 100002, 2020. Elsevier.
[28] Matt Bishop. ”About penetration testing.” IEEE Security & Privacy, vol. 5, no. 6, pp. 84–87, 2007. IEEE.
[29] Moralis. ”Tools and Best Practices for Smart Contract Security.” Moralis Blog, 2023. [Online]. Available from: https://moralis.io/
tools-and-best-practices-for-smart-contract-security/. [Accessed 19th March 2023].
[30] OpenZeppelin. OpenZeppelin, 2022. [Online]. Available from: http://www.openzeppelin.com. [Accessed 5th March 2022].
[31] Dappsys. ”Dappsys stable Ethereum building blocks.” Dappsys, 2023. [Online]. Available from: https://dappsys.readthedocs.io/en/
latest/#. [Accessed 19th March 2023].
[32] Akashdeep Bhardwaj, Syed Bilal Hussian Shah, Achyut Shankar, Mamoun Alazab, Manoj Kumar, Thippa Reddy Gadekallu. “Penetration
testing framework for smart contract blockchain.” Peer-to-Peer Networking and Applications, volume 14, pages 2635–2650, 2021. Springer.
[33] Pete Rotella. ”Software security vulnerabilities: baselining and benchmarking.” In Proceedings of the 1st International Workshop on Security
Awareness from Design to Deployment, pages 3–10, 2018.
[34] B. Wang, H. Liu, C.Liu, Z. Yang, Qian Ren, Huixuan Zheng, Hong Lei. ”Blockeye:Hunting for defi attacks on blockchain.” In Proceedings of
the 2021 IEEE/ACM 43rd International Conference on Software Engineering: Companion Proceedings (ICSE-Companion), pages 17–20.
[35] Zhiqiang Yang, Han Liu, Yue Li, Huixuan Zheng, Lei Wang, Bangdao Chen. “Seraph: enabling cross-platform security analysis for EVM and
Wasm smart contracts.” In Proceedings of the ACM/IEEE 42nd International Conference on Software Engineering: Companion Proceedings,
pages 21–24, 2020.
[36] Emanuele Antonio Napoli, Valentina Gatteschi. ”Evaluating ChatGPT for Smart Contracts Vulnerability Correction.” In 2023 IEEE 47th
Annual Computers, Software, and Applications Conference (COMPSAC), pages 1828–183.
[37] Isaac David, Liyi Zhou, Kaihua Qin, Dawn Song, Lorenzo Cavallaro, Arthur Gervais. ”Do you still need a manual smart contract audit?” arXiv
preprint arXiv:2306.12338, 2023.