No full-text available
To read the full-text of this research,
you can request a copy directly from the authors.
When Are OSS Developers More Likely to Introduce Vulnerable Code Changes? A Case Study
Abstract
We analyzed peer code review data of the Android Open Source Project (AOSP) to understand whether code changes that introduce security vulnerabilities, referred to as vulnerable code changes (VCC), occur at certain intervals. Using a systematic manual analysis process, we identified 60 VCCs. Our results suggest that AOSP developers were more likely to write VCCs prior to AOSP releases, while during the post-release period they wrote fewer VCCs. © IFIP International Federation for Information Processing 2014.
... Early work describes case studies of then emerging open source projects such as Linux [20], Mozilla [21], and FreeBSD [22]. Due to freely accessible code and commits, open source repositories are a common source for vulnerability research, e. g., by matching Common Vulnerabilities and Exposures (CVEs) [23], [24], tracking vulnerability evolution over time or events [25]- [28], or for evaluating static analysis tools [29]- [32]. Both Deligiannis et al. and Bai et al. analyzed drivers in the Linux Kernel [33], [34]. ...
... The user is blocked to prevent the future damages. The security services required for Top Secret levels are as follows [22][23][24]: Reporting and auditing to investigate events and detect unauthorized activities. ...
Self-organizing software generation teams are increasing due to the more innovation and convivence these networks provide. This article focuses on the security evaluation of the open-source software development (OSSD) team. A newly generated formula for assessing the network security of a collaborative network is proposed and evaluated. For this purpose, we take advantage of graph theory criteria. Using this measure, if the developer’s network is vulnerable in some parts, the guideline can be used for attracting/strengthening the ties in OSSD.
... As shown in Fig. 6, 'Construction' received the second highest attention (29 %) in which sub-category of 'Secure Architecture' has significantly higher numbers of studies (10 out of 14). The topics discussed in this area include the characteristics of security bugs [40,58], vulnerable code change in OSS, [9,11,12], secure system design [15,47,55] and adoption of security tools [16,33]. ...
Despite the security community's emphasis on the importance of building secure open source software (OSS), the number of new vulnerabilities found in OSS is increasing. In addition, software security is about the people that develop and use those applications and how their vulnerable behaviors can lead to exploitation. This leads to a need for reiteration of software security studies for OSS developments to understand the existing security practices and the security weakness among them. In this paper, a systematic review method with a sociotechnical analysis approach is applied to identify, extract and analyze the security studies conducted in the context of open source development. The findings include: (1) System verification is the most cited security area in OSS research; (2) The socio-technical perspective has not gained much attention in this research area; and (3) No research has been conducted focusing on the aspects of security knowledge management in OSS development.
We introduce Vulture, a new approach and tool to predict vulnerable components in large software systems. Vulture relates a software project's version archive to its vulnerability database to find those components that had vulnerabilities in the past. It then analyzes the import structure of software com- ponents and uses a support vector machine to learn and predict which imports are most important for a component to be vulnerable. We evaluated Vulture on the C++ codebase of Mozilla and found that Vulture correctly identifies about two thirds of all vulnerable components. This allows developers and project managers to focus their testing and inspection efforts: "We should look at nsXPInstallManager more closely, because it is likely to contain yet unknown vulnerabilities."
Open source software is often considered to be secure. One factor in this confidence in the security of open source software lies in leveraging large developer communities to find vulnerabilities in the code. Eric Raymond declares Linus' Law "Given enough eyeballs, all bugs are shallow." Does Linus' Law hold up ad infinitum? Or, can the multitude of developers become "too many cooks in the kitchen", causing the system's security to suffer as a result? In this study, we examine the security of an open source project in the context of developer collaboration. By analyzing version control logs, we quantified notions of Linus' Law as well as the "too many cooks in the kitchen" viewpoint into developer activity metrics. We performed an empirical case study by examining correlations between the known security vulnerabilities in the open source Red Hat Enterprise Linux 4 kernel and developer activity metrics. Files developed by otherwise-independent developer groups were more likely to have a vulnerability, supporting Linus' Law. However, files with changes from nine or more developers were 16 times more likely to have a vulnerability than files changed by fewer than nine developers, indicating that many developers changing code may have a detrimental effect on the system's security.