Software security has both an objective and a subjective component. A lot of the information available about that today is focused on the security vulnerabilities and their disclosure. It is less frequent that security breaches and failures rates are reported, even in open source projects. Disclosure of security problems can take several forms. A disclosure can be accompanied by a release of the fix for the problem, or not. The latter category can be further divided into ”voluntary” and ”involuntary” security issues. In widely used software there is also considerable variability in the operational profile under which the software is used. This profile is further modified by attacks on the software that may be triggered by security disclosures. Therefore a comprehensive model of software security qualities of a product needs to incorporate both objective measures, such as security problem disclosure, repair and, failure rates, as well as less objective metrics such as implied variability in the operational profile, influence of attacks, and subjective impressions of exposure and severity of the problems, etc. We show how a classical Bayesian model can be adapted for use in the security context. The model is discussed and assessed using data from three open source software projects. Our results show that the model is suitable for use with a certain subset of disclosed security faults, but that additional work will be needed to identify appropriate shape and scaling functions that would accurately reflect end-user perceptions associated with security problems.

Existing studies on problem reports in open source projects focus primarily on the analysis of the general category of problem reports, or limit their attention to observations on the number of security problem reports. To evaluate the security of a project, it is necessary to know not only how many security problem reports are logged but also how many are reported and how promptly they are corrected etc. In this paper, we study publicly disclosed security problem reports from eight releases of Fedora, nine releases of Ubuntu, four releases of RedHat Enterprise Linux (RHEL) and two releases of Suse Linux distributions, analyse and discuss which type of problem reports and how frequently they are reported, and how promptly they are corrected. Overall, Fedora and Suse show good results with high and medium severity security problem reports resolved without a backlog. On the other hand, RHEL and Ubuntu show less positive results with presence of backlogs.

Existing studies on the maintenance of open source projects focus primarily on the analyses of the overall maintenance of the projects and less on specific categories like the corrective maintenance. This paper presents results from an empirical study of bug reports from an open source project, identifies user participation in the corrective maintenance process through bug reports, and constructs a model to predict the corrective maintenance effort for the project in terms of the time taken to correct faults. Our study focuses on 72482 bug reports from over nine releases of Ubuntu, a popular Linux distribution. We present three main results: (1) 95% of the bug reports are corrected by people participating in groups of size ranging from 1 to 8 people, (2) there is a strong linear relationship (about 92%) between the number of people participating in a bug report and the time taken to correct it, (3) a linear model can be used to predict the time taken to correct bug reports.

To evaluate security in the context of software reliability engineering, it is necessary to analyse security problems, actual exploits, and their relationship with an understanding of the operational behaviour of the system. That can be done in terms of the effort involved in security exploits, through classic reliability factors such as calendar and inservice time, etc. Existing studies focus primarily on security problems and security exploits. Less attention has been given to the study of the relationship between security problems and security exploits. We present an analysis and classification of 43,710 vulnerabilities from the Open Source National Vulnerability Database and vulnerabilities for two specific products - Bugzilla and FEDORA. About 35% of the published vulnerabilities have been exploited. 34% of the vulnerabilities are disclosed as a result of an exploit and only 1.3% have been exploited after being publicly disclosed. We investigate a unifying approach, to understand security as a component of reliability. We focus on the disclosure and exploits of security problems with respect to calendar time and inservice time, and the impact of such exploits on the process of correcting the security problems, and discuss our approach using the collected data.

Software repositories provide abundance of valuable information about open source projects. With the increase in the size of the data maintained by the repositories, automated extraction of such data from individual repositories, as well as of linked information across repositories, has become a necessity. In this paper we describe a framework that uses web scraping to automatically mine repositories and link information across repositories. We discuss two implementations of the framework. In the first implementation, we automatically identify and collect security problem reports from project repositories that deploy the Bugzilla bug tracker using related vulnerability information from the National Vulnerability Database. In the second, we collect security problem reports for projects that deploy the Launchpad bug tracker along with related vulnerability information from the National Vulnerability Database. We have evaluated our tool on various releases of Fedora, Ubuntu, Suse, RedHat, and Firefox projects. The percentage of security bugs identified using our tool is consistent with that reported by other researchers.

Reliability analyses of software systems often focus only on the number of faults reported against the software. Using a broader set of metrics, such as problem resolution times and field software usage levels, can provide a more comprehensive view of the product. Some of these metrics are more readily available for open source products. We analyzed a suite of FEDORA releases and obtained some interesting findings. For example, we show that traditional reliability models may be used to predict problem rates across releases. We also show that security related reports tend to have a different profile than non-security related problem reporting and repair.

Aspect-oriented programming (AOP) provides new modularization of software systems by encapsulating cross-cutting concerns. AspectJ, an AOP language, uses abstractions such as pointcuts, advice, and aspects to achieve AOPpsilas primary functionality. Faults in pointcuts can cause aspects to fail to satisfy their requirements. Hence, testing pointcuts is necessary in order to ensure correctness of aspects. In mutation testing of pointcuts (a type of fault-based pointcut testing), the number of mutants (i.e., variations) for pointcuts is usually large due to the usage of wildcards. It is tedious to manually identify effective mutants that are of appropriate strength and resemble closely the original pointcut expression, reflecting the kind of mistakes that developers may make. To reduce developerspsila effort in this process, we have developed a new framework that automatically identifies the strength of each pointcut and generates pointcut mutants with different strengths. Developers can inspect the pointcut mutants and their join points for pointcut correctness or choose the mutants for conducting mutation testing. We conducted an empirical study on applying our framework on pointcuts from existing AspectJ programs. The results show that our framework can provide valuable assistance in generating effective mutants that are close to the original pointcuts and are of appropriate strength.

Software refactoring is the process of reorganizing the internal structure of code while preserving the external behavior. Aspect-Oriented Programming (AOP) provides new modularization of software systems by encapsulating crosscutting concerns. Based on these two techniques, aspect-oriented (AO) refactoring restructures crosscutting elements in code. AO refactoring includes two steps: aspect mining (identification of aspect candidates in code) and aspect refactoring (semantic-preserving transformation to migrate the aspect-candidate code to AO code). Aspect refactoring clusters similar join points together for the aspect candidates and encapsulates each cluster with an effective pointcut definition. With the increase in size of the code and crosscutting concerns, it is tedious to manually identify aspects and their corresponding join points, cluster the join points, and infer pointcut expressions. Therefore, there is a need to automate the process of AO refactoring. This paper proposes an automated approach that identifies aspect candidates in code and infers pointcut expressions for these aspects. Our approach mines for aspect candidates, identifies the join points for the aspect candidates, clusters the join points, and infers an effective pointcut expression for each cluster of join points. The approach also provides an additional testing mechanism to ensure that the inferred pointcut expressions are of correct strength. The empirical results show that our approach helps achieve a significant reduction in the total number of pointcut expressions to be used in the refactored code.