Empirical Notes on the Interaction Between Continuous Kernel Fuzzing and Development

Fuzzing has been studied and applied ever since the 1990s. Automated and continuous fuzzing has recently been applied also to open source software projects, including the Linux and BSD kernels. This paper concentrates on the practical aspects of continuous kernel fuzzing in four open source kernels. According to the results, there are over 800 unresolved crashes reported for the four kernels by the syzkaller/syzbot framework. Many of these have been reported relatively long ago. Interestingly, fuzzing-induced bugs have been resolved in the BSD kernels more rapidly. Furthermore, assertions and debug checks, use-after-frees, and general protection faults account for the majority of bug types in the Linux kernel. About 23% of the fixed bugs in the Linux kernel have either went through code review or additional testing. Finally, only code churn provides a weak statistical signal for explaining the associated bug fixing times in the Linux kernel.Comment: The 4th IEEE International Workshop on Reliability and Security Data Analysis (RSDA), 2019 IEEE International Symposium on Software Reliability Engineering Workshops (ISSREW), Berlin, IEE

Proceedings of 11th International Conference on Availability, Reliability and Security (ARES)

In contemporary software development projects and computing tasks, security concerns have an increasing effect, and sometimes even guide both the design and the project's processes. In certain environments, the demand for the security becomes the main driver of the development. In these cases, the development of the product requires special security arrangements for development and hosting, and specific security-oriented processes for governance. Compliance with these requirements using agile development methods may not only be a chance to improve the project efficiency, but can in some cases, such as in the case discussed in this paper, be an organizational requirement. This paper describes a case of building a secure identity management system and its management processes, in compliance with the Finnish government's VAHTI security instructions. The building project was to be implemented in accordance to the governmental security instructions, while following the service provider's own management framework. Project itself was managed with Scrum. The project's steering group required the use of Scrum, and this project may be viewed as a showcase of Scrum's suitability to multi-teamed, multi-site, security standard-compliant work. We also discuss the difficulties of fulfilling strict security regulations regarding both the development process and the end product in this project, and the difficulties utilizing Scrum to manage a multi-site project organization. Evaluation of the effects of the security work to project cost and efficiency is also presented. Finally, suggestions to enhance the Scrum method for security-related projects are made.</p

Aligning Security Objectives With Agile Software Development

Success of the software development process is defined by its ability to transform the business objectives into requirements, and these further into features and functionality. In addition to business objectives, software development also has security objectives requiring security engineering activities. In contrast to the iterative and incremental software development process, software security engineering is defined by sequential life cycle models: security and business objectives are thus implemented using conflicting approaches. To identify the incompatibilities between the methodologies, in this study the security engineering activities are mapped into common agile software development practises, processes and artifacts. Security engineering activities from Microsoft SDL, the ISO Common Criteria and OWASP SAMM security development lifecycle models are mapped into common agile processes, practises and artifacts. The organizational and technical aspects of the mapping are considered primarily from the point of view of achieving the security objectives set for the software engineering process: setting security requirements for design, their implementation and verification, and releasing secure software through efficient software security development process.acceptedVersionPeer reviewe