PrAIoritize: Learning to Prioritize Smart Contract Bugs and Vulnerabilities

Smart contract vulnerabilities and bugs have become a key concern for software engineers, as they can lead to significant financial losses, reputational damage, and legal issues. Therefore, prioritizing bug fixing for smart contracts is critical to maintaining trust. Due to the lack of tracking tools, prioritizing smart contract-reported bugs is done manually, which is a tedious task, limits bug triaging, and needs specialized knowledge. Towards this end, we propose PrAIoritize; an automated approach for predicting smart contract bug priorities that assist software engineers in prioritizing highly urgent bug reports. PrAIoritize consists of two main phases: 1) automatic labeling, which involves the automatic construction of a smart contract keyword lexicon and the automatic assignment of priority levels to unlabeled bug reports; 2) model construction, which involves feature engineering and designs layers of feed-forward neural networks (FFNNs) and bidirectional long short-term memory (BiLSTM) with multi-class classification to better capture the features of the textual descriptions of bugs and predict their priority levels. The model then is trained using smart contract bug reports collected from two data sources: open-source software (OSS) projects available on GitHub and NVD vulnerability database. Our evaluation demonstrates significant improvement over state-of-the-art baselines and commonly used pre-trained models (e.g. BERT) for similar classification tasks, with 5.75%-35.29% increase in F-measure, precision, and recall

An Integrated Modeling Framework for Managing the Deployment and Operation of Cloud Applications

Cloud computing can help Software as a Service (SaaS) providers to take advantage of the sheer number of cloud benefits such as, agility, continuity, cost reduction, autonomy, and easy management of resources. To reap the benefits, SaaS providers should create their applications to utilize the cloud platform capabilities. However, this is a daunting task. First, it requires a full understanding of the service offerings from different providers, and the meta-data artifacts required by each provider to configure the platform to efficiently deploy, run and manage the application. Second, it involves complex decisions that are specified by different stakeholders. Examples include, financial decisions (e.g., selecting a platform to reduces costs), architectural decisions (e.g., partition the application to maximize scalability), and operational decisions (e.g., distributing modules to insure availability and porting the application to other platforms). Finally, while each stakeholder may conduct a certain type of change to address a specific concern, the impact of a change may span multiple models and influence the decisions of several stakeholders. These factors motivate the need for: (i) a new architectural view model that focuses on service operation and reflects the cloud stakeholder perspectives, and (ii) a novel framework that facilitates providing holistic as well as partial architectural views, and generating the required platform artifacts by fragmenting the model into artifacts that can be easily modified separately. This PhD research devises a novel architecture framework, "The 5+1 Architectural View Model", for cloud applications, in which each view corresponds to a different perspective on cloud application deployment. The architectural framework is realized as a cloud modeling framework, called "StratusML", which consists of a modeling language that uses layers to specify the cloud configuration space, and a transformation engine to generate the configuration space artifacts. The usefulness and practical applicability of StratusML to model multi-cloud and multi-tenant applications have been demonstrated though a representative domain example. Moreover, to automate the framework evolution as new concerns and cloud platforms emerge, this research work introduces also a novel schema matching technique, called "Liberate". Liberate supports the process of domain model creation, evolution, and transformations. Liberate helps solve the vendor lock-in problem by reducing the manual efforts required to map complex correspondences between cloud schemas whose domain concepts do not share linguistic similarities. The evaluation of Liberate shows its superiority in the cloud domain over existing schema matching approaches

Dissecting Smart Contract Languages: A Survey

Blockchain is a distributed ledger technology that gained popularity for enabling the transformation of cryptocurrency among peers without mediation by a centralized third-party authority. Smart contracts expand the applications of blockchain technology and have played a role in its widespread adoption. Smart contracts are immutable digital programs that are deployed on blockchains to codify agreements between parties. Existing smart contract implementations have faced challenges, including security vulnerabilities, leading to significant losses and concerns. This has stimulated a wave of attempts to improve Smart Contract Languages (SCLs) to overcome implementation challenges and ensure code quality, producing many languages with diverse features. Scholars have made some attempts to classify SCLs and clarify the process of selecting an SCL, but to the best of our knowledge, no comprehensive survey of existing SCLs has been published. Our work surpasses earlier efforts by evaluating a significantly larger set of SCLs, in greater depth, to ease the process of SCL selection for blockchain research and implementation. In this paper, we (1) propose a robust framework for comparing existing SCLs, (2) analyze and discuss 36 SCLs, addressing issues beyond those used to construct the comparison framework, and (3) define new parameters for future research and development of SCLs. The survey provides a guide for those who intend to select or use an SCL to implement smart contracts, develop new SCLs, or add new extensions to the existing SCLs

Smart Contract Upgradeability on the Ethereum Blockchain Platform: An Exploratory Study

Context: Smart contracts are computerized self-executing contracts that contain clauses, which are enforced once certain conditions are met. Smart contracts are immutable by design and cannot be modified once deployed, which ensures trustlessness. Despite smart contracts' immutability benefits, upgrading contract code is still necessary for bug fixes and potential feature improvements. In the past few years, the smart contract community introduced several practices for upgrading smart contracts. Upgradeable contracts are smart contracts that exhibit these practices and are designed with upgradeability in mind. During the upgrade process, a new smart contract version is deployed with the desired modification, and subsequent user requests will be forwarded to the latest version (upgraded contract). Nevertheless, little is known about the characteristics of the upgrading practices, how developers apply them, and how upgrading impacts contract usage. Objectives: This paper aims to characterize smart contract upgrading patterns and analyze their prevalence based on the deployed contracts that exhibit these patterns. Furthermore, we intend to investigate the reasons why developers upgrade contracts (e.g., introduce features, fix vulnerabilities) and how upgrades affect the adoption and life span of a contract in practice. Method: We collect deployed smart contracts metadata and source codes to identify contracts that exhibit certain upgrade patterns (upgradeable contracts) based on a set of policies. Then we trace smart contract versions for each upgradable contract and identify the changes in contract versions using similarity and vulnerabilities detection tools. Finally, we plan to analyze the impact of upgrading on contract usage based on the number of transactions received and the lifetime of the contract version

Exploring Security Practices in Infrastructure as Code: An Empirical Study

Cloud computing has become popular thanks to the widespread use of Infrastructure as Code (IaC) tools, allowing the community to conveniently manage and configure cloud infrastructure using scripts. However, the scripting process itself does not automatically prevent practitioners from introducing misconfigurations, vulnerabilities, or privacy risks. As a result, ensuring security relies on practitioners understanding and the adoption of explicit policies, guidelines, or best practices. In order to understand how practitioners deal with this problem, in this work, we perform an empirical study analyzing the adoption of IaC scripted security best practices. First, we select and categorize widely recognized Terraform security practices promulgated in the industry for popular cloud providers such as AWS, Azure, and Google Cloud. Next, we assess the adoption of these practices by each cloud provider, analyzing a sample of 812 open-source projects hosted on GitHub. For that, we scan each project configuration files, looking for policy implementation through static analysis (checkov). Additionally, we investigate GitHub measures that might be correlated with adopting these best practices. The category Access policy emerges as the most widely adopted in all providers, while Encryption in rest are the most neglected policies. Regarding GitHub measures correlated with best practice adoption, we observe a positive, strong correlation between a repository number of stars and adopting practices in its cloud infrastructure. Based on our findings, we provide guidelines for cloud practitioners to limit infrastructure vulnerability and discuss further aspects associated with policies that have yet to be extensively embraced within the industry.Comment: 50 pages, 13 figures, 10 table

iContractBot: A chatbot for smart contracts’ specification and code generation

Pre-print (Óritrýnt handrit)Recently, Blockchain technology adoption has expanded to many application areas due to the evolution of smart contracts. However, developing smart contracts is non-trivial and challenging due to the lack of tools and expertise in this field. A promising solution to overcome this issue is to use Model-Driven Engineering (MDE), however, using models still involves a learning curve and might not be suitable for non-technical users. To tackle this challenge, chatbot or conversational interfaces can be used to assess the non-technical users to specify a smart contract in gradual and interactive manner. In this paper, we propose iContractBot, a chatbot for modeling and developing smart contracts. Moreover, we investigate how to integrate iContractBot with iContractML, a domainspecific modeling language for developing smart contracts, and instantiate intention models from the chatbot. The iContractBot framework provides a domain-specific language (DSL) based on the user intention and performs model-to-text transformation to generate the smart contract code. A smart contract use case is presented to demonstrate how iContractBot can be utilized for creating models and generating the deployment artifacts for smart contracts based on a simple conversationWe acknowledge the support of the Icelandic Centre for Research (Rannís) , [funding reference number 218202-051]

EnHMM: On the Use of Ensemble HMMs and Stack Traces to Predict the Reassignment of Bug Report Fields

Bug reports (BR) contain vital information that can help triaging teams prioritize and assign bugs to developers who will provide the fixes. However, studies have shown that BR fields often contain incorrect information that need to be reassigned, which delays the bug fixing process. There exist approaches for predicting whether a BR field should be reassigned or not. These studies use mainly BR descriptions and traditional machine learning algorithms (SVM, KNN, etc.). As such, they do not fully benefit from the sequential order of information in BR data, such as function call sequences in BR stack traces, which may be valuable for improving the prediction accuracy. In this paper, we propose a novel approach, called EnHMM, for predicting the reassignment of BR fields using ensemble Hidden Markov Models (HMMs), trained on stack traces. EnHMM leverages the natural ability of HMMs to represent sequential data to model the temporal order of function calls in BR stack traces. When applied to Eclipse and Gnome BR repositories, EnHMM achieves an average precision, recall, and F-measure of 54%, 76%, and 60% on Eclipse dataset and 41%, 69%, and 51% on Gnome dataset. We also found that EnHMM improves over the best single HMM by 36% for Eclipse and 76% for Gnome. Finally, when comparing EnHMM to Im.ML.KNN, a recent approach in the field, we found that the average F-measure score of EnHMM improves the average F-measure of Im.ML.KNN by 6.80% and improves the average recall of Im.ML.KNN by 36.09%. However, the average precision of EnHMM is lower than that of Im.ML.KNN (53.93% as opposed to 56.71%).Comment: Published in Proceedings of the 28th IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER 2021), 11 pages, 7 figure

SLO-ML:A Language for Service Level Objective Modelling in Multi-cloud applications

Cloud modelling languages (CMLs) are designed to assist customers in tackling the diversity of services in the current cloud market. While many CMLs have been proposed in the literature, they lack practical support for automating the selection of services based on the specific service level objectives of a customer's application. We put forward SLO-ML, a novel and generative CML to capture service level requirements. Subsequently, SLO-ML selects the services to honour the customer's requirements and generates the deployment code appropriate to these services. We present the architectural design of SLO-ML and the associated broker that realises the deployment operations. We evaluate SLO-ML using an experimental case study with a group of researchers and developers using a real-world cloud application. We also assess SLO-ML's overheads through empirical scalability tests. We express the promises of SLO-ML in terms of gained productivity and experienced usability, and we highlight its limitations by analysing it as application requirements grow