Security vulnerabilities are major defects in software implementation that allow malicious uses to undermine its integrity by triggering crashes, stealing information, or even taking control of the software and its underlying system. Despite the extensive research on vulnerabilities themselves, few studies have been performed on understanding the relations between security vulnerabilities and other bugs, which have attracted attention due to some recently found important vulnerabilities. In this paper, we present an exploration study on the vulnerability-bug relations in two important software projects: Firefox as the representative of browsers, and Red Hat as the representative of operating systems. In the study, we automatically extracted dependencies among vulnerability and bugs and manually investigated the character of such dependencies.

Among various bug reports (BRs), security bug reports (SBRs) are unique because they require immediate concealment and fixes. When SBRs are not identified in time, attackers can exploit the vulnerabilities. Prior work identifies SBRs via text mining, which requires a predefined keyword list and trains a classifier with known SBRs and non-security bug reports (NSBRs). The former approach is not reliable, because (1) as the contexts of security vulnerabilities and terminology of SBRs change over time, the predefined list will become out-dated; and (2) users may have insufficient SBRs for training. We introduce a semi-supervised learning-based approach, Sais, to adaptively and reliably identify SBRs. Given a project's BRs containing some labeled SBRs, many more NSBRs, and unlabeled BRs, Sais iteratively mines keywords, trains a classifier based on the keywords from the labeled data, classifies unlabeled BRs, and augments its training data with the newly labeled BRs. Our evaluation shows that Sais is useful for identifying SBRs.

Despite the advancement in software build tools such as Maven and Gradle, human involvement is still often required in software building. To enable large-scale advanced program analysis and data mining of software artifacts, software engineering researchers need to have a large corpus of built software, so automatic software building becomes essential to improve research productivity. In this paper, we present a feasibility study on automatic software building. Particularly, we first put state-of-the-art build automation tools (Ant, Maven and Gradle) to the test by automatically executing their respective default build commands on top 200 Java projects from GitHub. Next, we focus on the 86 projects that failed this initial automated build attempt, manually examining and determining correct build sequences to build each of these projects. We present a detailed build failure taxonomy from these build results and show that at least 57% build failures can be automatically resolved.

Nowadays, due to the frequent technological innovation and market changes, software libraries are evolving very quickly. Backward compatibility has always been one of the most important requirements during the evolution of software platforms and libraries. However, backward compatibility is seldom fully achieved in practice, and many relevant software failures are reported. Therefore, it is important to understand the status, major reasons, and impact of backward incompatibilities in real world software. This paper presents an empirical study to understand behavioral changes of APIs during evolution of software libraries. Specifically, we performed a large-scale cross-version regression testing on 68 consecutive version pairs from 15 popular Java software libraries. Furthermore, we collected and studied 126 real-world software bugs reports on backward incompatibilities of software libraries. Our major findings include: (1) 1,094 test failures / errors and 296 behavioral backward incompatibilities are detected from 52 of 68 consecutive version pairs; (2) there is a distribution mismatch between incompatibilities detected by library-side regression testing, and bug-inducing incompatibilities; (3) the majority of behavioral backward incompatibilities are not well documented in API documents or release notes; and (4) 67% of fixed client bugs caused by backward incompatibilities in software libraries are fixed by client developers, through several simple change patterns made to the backward incompatible API invocation.

Regression performance testing is an important but time/resource-consuming phase during software development. Developers need to detect performance regressions as early as possible to reduce their negative impact and fixing cost. However, conducting regression performance testing frequently (e.g., after each commit) is prohibitively expensive. To address this issue, in this paper, we propose PerfRanker, the first approach to prioritizing test cases in performance regression testing for collection-intensive software, a common type of modern software heavily using collections. Our test prioritization is based on performance impact analysis that estimates the performance impact of a given code revision on a given test execution. Evaluation shows that our approach can cover top 3 test cases whose performance is most affected within top 30% to 37% prioritized test cases, in contrast to top 65% to 79% by 3 baseline techniques.

Network access is one of the most common features of Android applications. Statistics show that almost 80% of Android apps ask for network permission and thus may have some network-related features. Android apps may access multiple servers to retrieve or post various types of data, and the code to handle such network features often needs to change as a result of server API evolution or the content change of data transferred. Since various network code is used by multiple features, maintenance of network-related code is often difficult because the code may scatter in different places in the code base, and it may not be easy to predict the impact of a code change to the network behavior of an Android app. In this paper, we present an approach to statically summarize network behavior from the byte code of Android apps. Our approach is based on string taint analysis, and generates a summary of network requests by statically estimating the possible values of network API arguments. To evaluate our technique, we applied our technique to top 500 android apps from the official Google Play market, and the result shows that our approach is able to summarize network behavior for most apps efficiently (averagely less than 50 second for an app). Furthermore, we performed an empirical evaluation on 8 real-world maintenance tasks extracted from bug reports of open-source Android projects on Github. The empirical evaluation shows that our technique is effective in locating relevant network code.

Application-level network-traffic classification is important for many security-related tasks in network management. With the knowledge of which application certain network traffic belongs to, the network managers are able to allow/block certain applications in the network (whitelisting/blacklisting), or to locate known malicious applications in the network. To support application level network-traffic classification, the network managers require a network-signature for each possible applications in the network, so that they can match these signatures with the network traffic at runtime to identify the ownership of the traffic. The traditional approaches to generating network-signatures for applications require either manual inspection of the application or accumulated annotated network traffic of the application. These approaches are not efficient enough nowadays, given the recent emergence of mobile application markets, where hundreds to thousands of mobile apps are added everyday. In this paper, we present a fully automatic tool called NTApps to generate network signatures for the mobile apps in android market. NTApps is based on string analysis, and generates network signatures by statically estimating the possible values of network API arguments.

In modern software development, software localization is a key process to support distribution of software products to the global market.During software localization, developers typically convert all user-visible strings, resource files, and other culture-related elements to the local versions that are well accepted by local users.Despite the popularity of software localization, there have been few studies on the its current status in software practice, such as the proportion of localized projects, the most popular locales, and more importantly, the quality of software localization.In this paper, we present an empirical study on the status of software localization in open source projects.We find from that, popularity of software localization varies a lot in different User Interface (UI) frameworks and domains.Furthermore, we surprisingly find that only about 60% of string keys are actually translated on average in localized top software projects and software localization often span a long period of time in the software development history.