Deep learning (DL) has been a common thread across several recent techniques for vulnerability detection. The rise of large, publicly available datasets of vulnerabilities has fueled the learning process underpinning these techniques. While these datasets help the DL-based vulnerability detectors, they also constrain these detectors' predictive abilities. Vulnerabilities in these datasets have to be represented in a certain way, e.g., code lines, functions, or program slices within which the vulnerabilities exist. We refer to this representation as a base unit. The detectors learn how base units can be vulnerable and then predict whether other base units are vulnerable. We have hypothesized that this focus on individual base units harms the ability of the detectors to properly detect those vulnerabilities that span multiple base units (or MBU vulnerabilities). For vulnerabilities such as these, a correct detection occurs when all comprising base units are detected as vulnerable. Verifying how existing techniques perform in detecting all parts of a vulnerability is important to establish their effectiveness for other downstream tasks. To evaluate our hypothesis, we conducted a study focusing on three prominent DL-based detectors: ReVeal, DeepWukong, and LineVul. Our study shows that all three detectors contain MBU vulnerabilities in their respective datasets. Further, we observed significant accuracy drops when detecting these types of vulnerabilities. We present our study and a framework that can be used to help DL-based detectors toward the proper inclusion of MBU vulnerabilities.

The npm registry is one of the pillars of the JavaScript and Type-Script ecosystems, hosting over 1.7 million packages ranging from simple utility libraries to complex frameworks and entire applications. Each day, developers publish tens of thousands of updates as well as hundreds of new packages. Due to the overwhelming popularity of npm, it has become a prime target for malicious actors, who publish new packages or compromise existing packages to introduce malware that tampers with or exfiltrates sensitive data from users who install either these packages or any package that (transitively) depends on them. Defending against such attacks is essential to maintaining the integrity of the software supply chain, but the sheer volume of package updates makes comprehensive manual review infeasible. We present Amalfi, a machine-learning based approach for automatically detecting potentially malicious packages comprised of three complementary techniques. We start with classifiers trained on known examples of malicious and benign packages. If a package is flagged as malicious by a classifier, we then check whether it includes metadata about its source repository, and if so whether the package can be reproduced from its source code. Packages that are reproducible from source are not usually malicious, so this step allows us to weed out false positives. Finally, we also employ a simple textual clone-detection technique to identify copies of malicious packages that may have been missed by the classifiers, reducing the number of false negatives. Amalfi improves on the state of the art in that it is lightweight, requiring only a few seconds per package to extract features and run the classifiers, and gives good results in practice: running it on 96287 package versions published over the course of one week, we were able to identify 95 previously unknown malware samples, with a manageable number of false positives.

Prefetching web pages is a well-studied solution to reduce network latency by predicting users' future actions based on their past behaviors. However, such techniques are largely unexplored on mobile platforms. Today's privacy regulations make it infeasible to explore prefetching with the usual strategy of amassing large amounts of data over long periods and constructing conventional, "large" prediction models. Our work is based on the observation that this may not be necessary: Given previously reported mobile-device usage trends (e.g., repetitive behaviors in brief bursts), we hypothesized that prefetching should work effectively with "small" models trained on mobile-user requests collected during much shorter time periods. To test this hypothesis, we constructed a framework for automatically assessing prediction models, and used it to conduct an extensive empirical study based on over 15 million HTTP requests collected from nearly 11,500 mobile users during a 24-hour period, resulting in over 7 million models. Our results demonstrate the feasibility of prefetching with small models on mobile platforms, directly motivating future work in this area. We further introduce several strategies for improving prediction models while reducing the model size. Finally, our framework provides the foundation for future explorations of effective prediction models across a range of usage scenarios.

Noise in software patches impacts their understanding, analysis, and use for tasks such as change prediction. Although several approaches have been developed to identify noise in patches, this issue has persisted. An analysis of a dataset of security patches for the Tomcat web server, which we further expanded with security patches from five additional systems, uncovered several kinds of previously unreported noise which we call nonessential casualty changes. These are changes that themselves do not alter the logic of the program but are necessitated by other changes made in the patch. In this paper, we provide a comprehensive taxonomy of casualty changes. We then develop CasCADe, an automated technique for automatically identifying casualty changes. We evaluate CasCADe with several publicly available datasets of patches and tools that focus on them. Our results show that CasCADe is highly accurate, that the kinds of noise it identifies occur relatively commonly in patches, and that removing this noise improves upon the evaluation results of a previously published change-based approach.

Software vulnerabilities expose a system to security breaches. In this paper, we focus on vulnerabilities rooted in a system's architecture. Specifically, we describe our attempt at developing ways of depicting and detecting architectural vulnerabilities. Our guiding observation was that vulnerabilities that belong to the same category result in commonalities in the source code. This observation led us to hypothesize that it is possible to define patterns that can be used to detect similar vulnerabilities. To test this hypothesis, we collected a dataset of vulnerabilities reported for the Tomcat web server that spanned 20 different categories and 90 unique vulnerabilities. We represented each individual vulnerability with a Program Dependence Graph (PDG) and employed two approaches we believed to be especially promising based on the results they yielded when applied to similar problems. The first approach relied on graph-theory research to identify shared subgraphs in vulnerability PDGs. The second approach performed a multi-level hierarchical clustering on the PDGs to account for cases in which vulnerabilities of the same category exhibit more than one pattern. In the end, neither approach yielded successful results: the former was too computationally expensive to be practically applicable and had limited applicability, while the latter generated patterns that performed poorly when applied on real examples of vulnerabilities. Even though the two approaches were ultimately unsuccessful, we report on several important lessons that emerged from this endeavor.

UI testing is tedious and time-consuming due to the manual effort required. Recent research has explored opportunities for reusing existing UI tests from an app to automatically generate new tests for other apps. However, the evaluation of such techniques currently remains manual, unscalable, and unreproducible, which can waste effort and impede progress in this emerging area. We introduce FrUITeR, a framework that automatically evaluates UI test reuse in a reproducible way. We apply FrUITeR to existing test-reuse techniques on a uniform benchmark we established, resulting in 11,917 test reuse cases from 20 apps. We report several key findings aimed at improving UI test reuse that are missed by existing work.

Architectural security tactics (e.g., authorization, authentication) are used to achieve stakeholders' security requirements. Security tactics allow the system to react, resist, detect and recover from attacks. Flaws in the adoption of these tactics into the system's architecture, an incorrect implementation of security tactics, or deterioration of tactic implementations over time can introduce severe vulnerabilities that are exploitable by attackers. Therefore, in this work, we present the Common Architectural Weakness Enumeration (CAWE), a catalog of known weaknesses rooted in the design or implementation of security tactics which can result in tactical vulnerabilities. We categorized all known software weaknesses as tactic-related and non-tactic related. This way, our CAWE catalog enumerates common weaknesses in a security architecture that can lead to tactical vulnerabilities. From our CAWE catalog, we found 223 different types of tactical vulnerabilities. In this work, we also used this catalog to study tactical vulnerabilities in three large-scale open source projects: Chromium, PHP, and Thunderbird. In a detailed analysis, we identified the most occurring vulnerability types on these projects. From this study we observed that (i) Improper Input Validation and Improper Access Control were the most occurring vulnerability types in Chromium, PHP and Thunderbird and (ii) "Validate Inputs" and "Authorize Actors" were the security tactics mostly affected by these tactical vulnerabilities. Moreover, in a qualitative analysis of 632 tactical vulnerabilities and their fixes in these systems, we characterized their root causes and investigated the way the original developers of each system fixed these vulnerabilities. From this qualitative analysis, we found 44 distinct root causes that lead to these tactical vulnerabilities. The results of this study not only show how architectural weaknesses in systems have created severe vulnerabilities, but also provide recommendations driven by empirical data for addressing such security problems. (C) 2018 Elsevier Inc. All rights reserved.

Finding and preventing software vulnerabilities re-quires analyzing their root causes. Numerous cases of vulnerabilities are caused by architectural decisions, or lack thereof. Solutions for issues such as user authentication are crafted at the architectural level, and they are linked to many instances of vulnerabilities. Despite this, there are few studies conducted that try to explore the connection between the architectures of systems, their evolution and vulnerabilities. Moreover, there is a gap in empirical knowledge on how to conduct such studies. In this paper, we aim to close that gap by providing guidelines on how to conduct studies that focus on architecture and vulnerabilities by proposing architecture recovery techniques, metrics to represent architecture change, generating representative datasets and ways to interpret results. To do this, we conducted a pilot study with Tomcat and several of its vulnerabilities.

Through a set of well-defined interfaces, plug-and-play architectures enable additional functionalities to be added or removed from a system at its runtime. However, plug-ins can also increase the application's attack surface or introduce untrusted behavior into the system. In this paper, we (1) use a grounded theory-based approach to conduct an empirical study of common vulnerabilities in plug-and-play architectures; (2) conduct a systematic literature survey and evaluate the extent that the results of the empirical study are novel or supported by the literature; (3) evaluate the practicality of the findings by interviewing practitioners with several years of experience in plug-and-play systems. By analyzing Chromium, Thunderbird, Firefox, Pidgin, WordPress, Apache OfBiz, and OpenMRS, we found a total of 303 vulnerabilities rooted in extensibility design decisions and observed that these plugin-related vulnerabilities were caused by 16 different types of vulnerabilities. Out of these 16 vulnerability types we identified 19 mitigation procedures for fixing them. The literature review supported 12 vulnerability types and 8 mitigation techniques discovered in our empirical study, and indicated that 5 mitigation techniques were not covered in our empirical study. Furthermore, it indicated that 4 vulnerability types and 11 mitigation techniques discovered in our empirical study were not covered in the literature. The interviews with practitioners confirmed the relevance of the findings and highlighted ways that the results of this empirical study can have an impact in practice.

Tracing Vulnerabilities Across Product Releases Adriana Sejfia, M.S. Rochester Institute of Technology, 2018 Supervisor: Dr. Mehdi Mirakhorli When a software development team becomes aware of a vulnerability, it generally only knows that the last version of that software product is vulnerable. However, today most software products have more than one version being actively used at a time. Garnering information on which versions contain a vulnerability, and which do not, is crucial for the users, to know which versions of a software product are safe to use, and also for the developers, to know where to apply the patch. The patch, i.e. the fix of the vulnerability, contains valuable information in the form of changes made to the known vulnerable code to fix it. This information could be leveraged to analyze the presence of this known vulnerability across releases of a software product. The problem of tracing vulnerabilities in different releases has been addressed in two separate research projects. Both of these projects rely on the changed

To satisfy security requirements, software architects often adopt security tactics. These architectural tactics provide mechanisms for resisting, detecting, reacting to and recovering from attacks. Consequently, flaws in the implementation of security tactics or their deterioration during software evolution and maintenance can introduce severe vulnerabilities that could be exploited by attackers. However, we currently lack an in-depth understanding of the types and impact of vulnerabilities related to security tactics. Therefore, in this paper, we conduct a first-of-its-kind in-depth case study involving three large-scale open-source systems. We investigate the most common types of vulnerabilities associated with security tactics, how frequently they may occur over time, and how fixing them differs from fixing vulnerabilities that are not related to security tactics. Key findings are (i) most tactic-related vulnerabilities were related to the tactics "Validate Inputs" and "Authorize Actors", (ii) vulnerabilities related to tactics have a similar distribution over time and software releases as vulnerabilities that are not related to tactics, (iii) fixing tactic-related vulnerabilities is not necessarily more complex than fixing vulnerabilities that are not related to security tactics. This study highlights the importance of ensuring an appropriate implementation of security-related design decisions in code to avoid vulnerabilities rooted in the architecture.