Vulnerability analysis of Linux distributions and Docker container images

Abstract. Docker containers are an increasingly popular alternative for virtual machines, and they are widely used in small-scale and large-scale organizations alike. Containers are usually based on Linux distributions and vulnerabilities in these distributions affect all applications built upon these containers. The purpose of this study was to analyse the current security state of selected Linux distributions and provide insight about the overall security of Docker container usage. The goal of this study was to recognize what components and component versions were used in different OS distributions and how vulnerable these components were. The amounts and severities of vulnerabilities were compared between different OS distributions. Changes in critical and high severity vulnerabilities were compared between container distribution versions. The lifetimes and types of fixed critical and high severity vulnerabilities were determined. Along with Docker containers corresponding ISO distributions were analysed for comparison. Analysis of ISO and container distributions of Linux-based Debian, Ubuntu, and CentOS were conducted with Black Duck Binary Analysis (BDBA) software. BDBA is used to analyse the binary code of the distributions. Analysis results contain information about identified components, their versions, and vulnerabilities associated with them. As a result, Debian, Ubuntu, and CentOS container distributions were considered secure. The observed container maintenance strategies differed between distributions: Debian and Ubuntu containers were updated periodically (approximately monthly), whereas CentOS container updates were tied to Linux ISO image updates — i.e., official releases. The number of critical vulnerabilities were low on all lately released containers. Fixed vulnerabilities between container releases varied a lot in age and severity. Even though containers are based on ISO distributions, different versions of same components were used in them making their vulnerability profile potentially different. In all distributions, software rotting was observed, and it is suggested that only latest versions of maintained distributions should be used, if there is no specific reason to not do so

Dual licensing in open source software markets

Dual licensing has proved to be a sustainable business model for various commercial software vendors employing open source strategies. In this paper we study the main characteristics of dual licensing and under which conditions it represents a profitable commercial strategy. We show that dual licensing is a form of versioning, whereby the software vendor uses the open source licensing terms in order to induce commercial customers to select the proprietary version of the software. Furthermore, we show that the software vendor prefers dual licensing to a fully proprietary strategy when the customers are very sensitive to the reciprocal terms of the open source license

A Common Software Configuration Management System for CERN SPS and LEP Accelerators and Technical Services

Software configuration management activities are crucial to assure the integrity of current operational and the quality of new software either being developed at CERN or outsourced. The functionality of the present management system became insufficient with large maintenance overheads. In order to improve our situation, a new software configuration management system has been set up. It is based on Razor, a commercial tool, which supports the management of file versions and operational software releases, along with integrated problem reporting capabilities. In addition to the basic tool functionality, automated procedures were custom made, for the installation and distribution of operational software. Policies were developed and applied over the software development life cycle to provide visibility and control. The system ensures that, at all times, the status and location of all deliverable versions are known, the state of shared objects is carefully controlled and unauthorised changes prevented. It provides a managed environment for software development, in various domains of the SPS and LEP CERN accelerators, and the technical services, automating code and lifecycle management. This paper outlines the reasons for selecting the chosen tool, the implementation of the system, the problems solved and the final goals achieved

Stack Overflow: A Code Laundering Platform?

Developers use Question and Answer (Q&A) websites to exchange knowledge and expertise. Stack Overflow is a popular Q&A website where developers discuss coding problems and share code examples. Although all Stack Overflow posts are free to access, code examples on Stack Overflow are governed by the Creative Commons Attribute-ShareAlike 3.0 Unported license that developers should obey when reusing code from Stack Overflow or posting code to Stack Overflow. In this paper, we conduct a case study with 399 Android apps, to investigate whether developers respect license terms when reusing code from Stack Overflow posts (and the other way around). We found 232 code snippets in 62 Android apps from our dataset that were potentially reused from Stack Overflow, and 1,226 Stack Overflow posts containing code examples that are clones of code released in 68 Android apps, suggesting that developers may have copied the code of these apps to answer Stack Overflow questions. We investigated the licenses of these pieces of code and observed 1,279 cases of potential license violations (related to code posting to Stack overflow or code reuse from Stack overflow). This paper aims to raise the awareness of the software engineering community about potential unethical code reuse activities taking place on Q&A websites like Stack Overflow.Comment: In proceedings of the 24th IEEE International Conference on Software Analysis, Evolution, and Reengineering (SANER

Extracting Build Changes with BUILDDIFF

Build systems are an essential part of modern software engineering projects. As software projects change continuously, it is crucial to understand how the build system changes because neglecting its maintenance can lead to expensive build breakage. Recent studies have investigated the (co-)evolution of build configurations and reasons for build breakage, but they did this only on a coarse grained level. In this paper, we present BUILDDIFF, an approach to extract detailed build changes from MAVEN build files and classify them into 95 change types. In a manual evaluation of 400 build changing commits, we show that BUILDDIFF can extract and classify build changes with an average precision and recall of 0.96 and 0.98, respectively. We then present two studies using the build changes extracted from 30 open source Java projects to study the frequency and time of build changes. The results show that the top 10 most frequent change types account for 73% of the build changes. Among them, changes to version numbers and changes to dependencies of the projects occur most frequently. Furthermore, our results show that build changes occur frequently around releases. With these results, we provide the basis for further research, such as for analyzing the (co-)evolution of build files with other artifacts or improving effort estimation approaches. Furthermore, our detailed change information enables improvements of refactoring approaches for build configurations and improvements of models to identify error-prone build files.Comment: Accepted at the International Conference of Mining Software Repositories (MSR), 201