Fix-it: An extensible code auto-fix component in Review Bot

Static and dynamic program analysis techniques are important research areas in software security. Static analysis helps us locate vulnerabilities in a software by looking at the source code. Dynamic analysis helps us reason about the behavior of the software from information gathered at run-time. In this thesis, we are focusing on data flow analysis and heap analysis which are key static and dynamic program analysis techniques respectively.
\n
\nIn the first part of this thesis, we aim at detecting vulnerabilities in Android applications which have capability leaks. The security of the Android platform relies mainly on sandboxing applications and restricting their capabilities such that no application, by default, can perform any operations that would adversely impact other applications, the operating system, or the user. However, a recent research reported that a genuine but vulnerable application may leak its capabilities. When being leveraged, other applications can gain extra capabilities which they are not granted originally. We present DroidChecker, an Android application analyzing tool which searches for the aforementioned vulnerability in Android applications. DroidChecker uses interprocedural control flow graph searching and static taint checking to detect exploitable data paths in an Android application. We analyzed more than 1100 Android applications using DroidChecker and found 6 previously unknown vulnerable applications including the renowned Adobe Photoshop Express application. We also developed a malicious application that exploits the previously unknown vulnerability found in the Adobe Photoshop Express application. We showed that the malicious application, which is not granted any permissions, can access contacts on the phone with just a few lines of code.
\n
\nIn the second part of this thesis, we explore the use of heap analysis to extract software birthmarks. There are techniques like code obfuscation and watermarking which can make the source code of a program difficult to understand by humans and prove the ownership of the program. However, code obfuscation cannot avoid the source code being copied and a watermark can be defaced. A birthmark is a group of unique characteristics a program possesses that can be used to identify the program. We propose two novel dynamic birthmark systems based on the run-time heap. A dynamic birthmark is one that is extracted when the program is executing. Since it is based on the run-time behavior of the program, semantics-preserving transformations of the code like obfuscation cannot defeat dynamic birthmarks. In this regard, dynamic birthmarks are more robust compared with static birthmarks.
\n
\nTo the best of our knowledge, these are the first birthmark systems using heap analysis as the underlying technique. The basic idea is to take snapshots of the heap while the program is running. From the snapshots, heap graphs are constructed to model the referencing structure between objects. After going through some filtering and referencing processes, they become the birthmarks. The two birthmark systems have been devised to extract birthmarks for Java programs and JavaScript programs respectively. While the underlying ideas of the two birthmark systems are similar, the differences in nature of the two programming languages led to different implementation designs.

A secure software demands effective techniques for vulnerability detection during its development cycle. The practice of detecting security flaws before the deployment phase eliminates the risks that vulnerabilities may impose for the company. Static analysis and dynamic analysis techniques offer two complimentary approaches for checking vulnerabilities. Static analysis involves the scanning of source code or binary eliminating the need of executing it. This approach is fast and has no run time overhead. However, static analysis are quite imprecise and generate huge false positives and false negatives. On the other hand, dynamic analysis involves the running of the software. The problem of false positives and negatives is less in case of dynamic analysis because they analyze by running the test cases. But this approach requires large number of test cases to ensure a certain confidence level in detecting security bugs. This paper describes a methodology which integrates the two approaches in a complimentary manner. It adopts the strengths of the two and eliminates their weaknesses. We are currently dealing with buffer overflow vulnerability with pointer aliasing. However the idea can be extended to other vulnerabilities also for e.g memory related errors, race conditions( Time of Check to Time to Use vulnerability), dangling pointer vulnerability, integer errors etc.

Peer code review is an effective method to reduce the number of defects and maintain source code integrity. Peer re-views in most of the Open Source Software (OSS) communities are conducted via mailing list, which are difficult to manage at times. Code review tools aim to ease the review process and keep track of the review requests. In this paper, we describe preliminary results of our study to evaluate code review process using a popular open source code review tool (ReviewBoard) in OSS communities. Some of our study findings are similar to the findings of previous studies on code reviews. In the projects under our study, we found that, most of the revisions are not submitted for peer review. More than 80% of the review requests are responded by two or less number of reviewers. Top committers of the projects are also top contributors of code reviews. Most of the review requests get prompt feedback within a day; however, some requests might wait for feed-back for a long time. Most importantly, we have identified some interesting directions for future research.

Static analysis is one of the techniques used today to analyze source codes and minimize the issue of software vulnerability. Static analysis has the ability to observe all possible software paths in an application through the scrutiny of a web application’s source code. Among those paths, some may be considered feasible paths, which refer to any paths that the test cases can execute. The detection of feasible paths in the results of a static analysis helps to minimize the false positive rate. However, the detection of feasible paths can be challenging, especially for programs that have multiple conditions in the same branch. The aim is to ensure that each feasible path is detected only once (not duplicated). This paper proposes an approach based on minimal static single assignment (MSSA) form and symbolic execution to detect feasible paths. The proposed approach starts by converting the source code into an abstract syntax tree (AST), followed by converting the AST to minimal SSA representation, which helps to decrease the number of instructions in the SSA form. An algorithm was built to examine all of the instructions of the SSA form, identify whole paths in the source code, and extract constraints along each path. A path weight method (PWM) is proposed in this work to avoid detecting duplicated feasible paths. The satisfiability modulo theory (SMT) solver was used to check the satisfiability of each path condition. The proposed approach was tested on seven well-known test programs that have been used in related studies and 10 large scale programs. The experimental results indicate that the proposed method (PWM) can avoid detecting duplicated feasible paths, and the proposed approach reduced the time required for generating the paths compared to that in related studies.

The article discusses the issues of risk management at all stages of the life cycle of nuclear power plants. The definition and classification by types of risks that arise during the stages of the life cycle and operation of difficult objects such as nuclear power plants. Risk is anything that has the potential to affect each stage of a facility’s life cycle, performance, longevity, safety, or project budget. Thus, risk management is the process of identifying, classifying, prioritizing and planning risks. This article not only discusses the identification and classification by types of risks that arise during the construction and operation of such complex facilities as nuclear power plants, but also describes the methods for assessing and managing risks, taking into account the specifics of the construction of nuclear power facilities. There are two methods of risk assessment: quantitative and qualitative. The article describes such Quantitative methods as “Scenario Technology”, “Method - Sensitivity Analysis”, “Diagramming Technique - Tree Analysis”, as well as such Qualitative risk assessment methods as “Assessment of the probability of risk and its impact”, “Evaluation Matrix probability/risk of impact”, “Probability and impact”, “Risk classification and assessment of risk urgency. As a result of the analysis of existing risk management methods at all stages of the life cycle, the following conclusions were drawn: Risk identification can occur at any stage of the life cycle of a nuclear power plant, even after completion of construction work and delivery of the project. The maximum number of risks for all stages of the NPP life cycle should be identified at the stage of Sitting and design. The article proposes the format of the risk register table, provides a risk classification scheme, and develops a risk management flow chart at the stages of the NPP life cycle.

Code review is an important part of the software development process. Recently, many open source projects have begun practicing code review through “modern” tools such as GitHub pull-requests and Gerrit. Many commercial software companies use similar tools for code review internally. These tools enable the owner of a source code change to request individuals to participate in the review, i.e., reviewers. However, this task comes with a challenge. Prior work has shown that the benefits of code review are dependent upon the expertise of the reviewers involved. Thus, a common problem faced by authors of source code changes is that of identifying the best reviewers for their source code change. To address this problem, we present an approach, namely cHRev , to automatically recommend reviewers who are best suited to participate in a given review, based on their historical contributions as demonstrated in their prior reviews. We evaluate the effectiveness of cHRev on three open source systems as well as a commercial codebase at Microsoft and compare it to the state of the art in reviewer recommendation. We show that by leveraging the specific information in previously completed reviews (i.e.,quantification of review comments and their recency), we are able to improve dramatically on the performance of prior approaches, which (limitedly) operate on generic review information (i.e., reviewers of similar source code file and path names) or source coderepository data. We also present the insights into why our approach cHRev outperforms the existing approaches.

Static analysis technology is used to find programming errors before run time. Unlike dynamic analysis technique which looks at the application state while it is being executed, static analysis technique does not require the application to be executed. In this paper, we classify security vulnerability patterns in source code and design a model to express various security vulnerability patterns by making use of pushdown automata. On the basis of the model, it is possible to find a security vulnerability by making use of Abstract Syntax Tree (AST) based pattern matching technique in parsing level.

Malware classification plays an important role in tracing the attack sources of computer security. However, existing static analysis methods are fast in classification, but they are inefficient in some malware using packing and obfuscation techniques; the dynamic analysis methods have better universality for packing and obfuscation, but they will cause excessive classification cost. To overcome these shortcomings, in this paper, we propose a classification system Malscore based on the probability scoring and machine learning, which sets the probability threshold to concatenate static analysis (called Phase 1) and dynamic analysis (called Phase 2). The convolutional neural networks with spatial pyramid pooling were used to analyze the grayscale images (static features) in Phase 1, and the variable n-grams and machine learning were used to analyze the native API call sequences (dynamic features) in Phase 2. Malscore combined static analysis with dynamic analysis not only accelerated the static analysis process by taking advantage of the CNN in image recognition but also appeared to be more resilient to obfuscation by the dynamic analysis. Different from other static and dynamic analysis techniques, when malware is detected, due to the fact that malware will most likely be labeled only by static analysis, we could reduce the overheads by dynamically analyzing a few malware that has less obvious features or greater confusion in static analysis. We performed experiments on 174607 malware samples from 63 malware families. The result showed that Malscore achieved 98.82% accuracy for malware classification. Furthermore, Malscore was compared with the method of using static and dynamic analysis. The preprocessing and test time represented a reduction of 59.58% and 61.70%, respectively.

Due to the constant evolution of technology, each day brings new programming languages, development paradigms, and ways of evaluating processes. This is no different with source code metrics, where there is always new metric classes. To use a software metric to support decisions, it is necessary to understand how to perform the metric collection, calculation, interpretation, and analysis. The tasks of collecting and calculating source code metrics are most often automated, but how should we monitor them during the software development cycle? Our research aims to assist the software engineer to monitor metrics of vulnerability threats present in the source code through a reference prediction model, considering that real world software have non-functional security requirements, which implies the need to know how to monitor these requirements during the software development cycle. As a first result, this paper presents an empirical study on the evolution of the Linux project. Based on static analysis data, we propose low complexity models to study flaws in the Linux source code. About 391 versions of the project were analyzed by mining the official Linux repository using an approach that can be reproduced to perform similar studies. Our results show that it is possible to predict the number of warnings triggered by a static analyzer for a given software project revision as long as the software is continuously monitored.

Affect Recognition in Code Review: An In-situ Biometric Study of Reviewer’s Affect

This demo presents DTS (software defects testing system), a tool to catch defects in source code using static testing techniques. In DTS, various defect patterns are defined using defect patterns state machine and tested by a unified testing framework. Since DTS externalizes all the defect patterns it checks, defect patterns can be added, subtracted, or altered without having to modify the tool itself. Moreover, typical interval computation is expanded and applied in DTS to reduce the false positive and compute the state of defect state machine. In order to validate its usefulness, we perform some experiments on a suite of open source software whose results are briefly presented in the last part of the demo.

Code review has been widely acknowledged as a key quality assurance process in both open-source and industrial software development. Due to the asynchronicity of the code review process, the system's codebase tends to incorporate external commits while a source code change is reviewed, which cause the need for rebasing operations. External commits have the potential to modify files currently under review, which causes re-work for developers and fatigue for reviewers. Since source code changes observed during code review may be due to external commits, rebasing operations may pose a severe threat to empirical studies that employ code review data. Yet, to the best of our knowledge, there is no empirical study that characterises and investigates rebasing in real-world software systems. Hence, this paper reports an empirical investigation aimed at understanding the frequency in which rebasing operations occur and their side-effects in the reviewing process. To achieve so, we perform an in-depth large-scale empirical investigation of the code review data of 11 software systems, 28,808 code reviews and 99,121 revisions. Our observations indicate that developers need to perform rebasing operations in an average of 75.35% of code reviews. In addition, our data suggests that an average of 34.21% of rebasing operations tend to tamper with the reviewing process. Finally, we propose a methodology to handle rebasing in empirical studies that employ code review data. We show how an empirical study that does not account for rebasing operations may report skewed, biased and inaccurate observations.

Empirical analysis of security-related code reviews in npm packages

Research on money management practices followed by selected homemakers was conducted among purposively selected 150 homemakers 50 each from beginning, expanding and contracting stage of family life cycle. Personal interview method with prescheduled questionnaire was conducted to collect information on financial practices followed in family living. The data were analysed statistically by applying Z test and correlation co-efficient test. It was observed from the study that purchasing lists were prepared by more number of homemakers from beginning and expanding stage of family life cycle. More than eighty per cent of the homemakers from beginning (86%), expanding (98%) and contracting (90%) stages of family life cycle felt necessity of maintaining the account of expenses. It was observed that in beginning and expanding stages of family life cycle the homemakers involved in majority of purchases and payments were more as compared to the homemakers from contracting stage of family life cycle.

Cybersecurity risks are increasing in frequency and complexity, but many organizations struggle to plan and implement adequate protections at all stages of the software development life cycle (SDLC). Security is frequently added at the end of development (afterthought), and making effective use of safeguard space is difficult for IT leaders. The purpose of this study is to produce an all‐encompassing framework to adopt and ensure security throughout each phase of the SDLC, from planning through maintenance. The aim is to minimize vulnerabilities and improve the resilience of software by making “security by design” a structure that not only adopts security elegantly as a living document but also is built to be part of the development process. This study adopted a mixed‐methods approach. The initial stage of inquiry involved a systematic literature review (SLR) to identify common cybersecurity issues associated with each SDLC phase. The SLR was followed by an empirical survey of 71 software professionals from a variety of organizations. The survey was designed to gather perceived threats, current practices, and challenges associated with software development for survey participants' organizations. The data collected were analyzed and reviewed statistically, through chi‐square tests and ANOVA, to profile the variance relative to the size of the organization, geographic region, and experience level of the practitioner. The results noted several high‐risk challenges across the SDLC: underfunded security controls, imprecise requirements, insecure architecture, software bugs (i.e., injection vulnerabilities), inadequate testing, misconfigured production environments, and unreliable maintenance. The proposed framework provides cybersecurity mitigation techniques for each stage of the SDLC, such as leveraging security‐oriented design patterns, secure coding policies (i.e., input validation and authentication protocols), robust testing (i.e., penetration testing and code review), and continuous monitoring after deployment. The implementation of these measures leads to a significant risk reduction in the overall organizational security posture. The framework is a formalized end‐to‐end approach to secure software development by embedding security throughout the cycle. Embedding security as a part of the process versus an afterthought at every stage of the cycle creates a risk reduction impact. This integrated approach also provides organizations with the opportunity to foresee and mitigate events earlier in the cycle, along with general compliance mandates (i.e., GDPR, HIPAA, and PCI‐DSS), to provide more resilient, trustworthy software systems.