Incident management is a classical topic in cyber security. Recently, the European Union (EU) has started to consider also the relation between cyber security incidents and cyber security crises. These considerations and preparations, including those specified in the EU’s new cyber security laws, constitute the paper’s topic. According to an analysis of the laws and associated policy documents, (i) cyber security crises are equated in the EU to large-scale cyber security incidents that either exceed a handling capacity of a single member state or affect at least two member states. For this and other purposes, (ii) the new laws substantially increase mandatory reporting about cyber security incidents, including but not limited to the large-scale incidents. Despite the laws and new governance bodies established by them, however, (iii) the working of actual cyber security crisis management remains unclear particularly at the EU-level. With these policy research results, the paper advances the domain of cyber security incident management research by elaborating how European law perceives cyber security crises and their relation to cyber security incidents, paving the way for many relevant further research topics with practical relevance, whether theoretical, conceptual, or empirical.

Different security issues are a common problem for open source packages archived to and delivered through software ecosystems. These often manifest themselves as software weaknesses that may lead to concrete software vulnerabilities. This paper examines various security issues in Python packages with static analysis. The dataset is based on a snapshot of all packages stored to the Python Package Index (PyPI). In total, over 197 thousand packages and over 749 thousand security issues are covered. Even under the constraints imposed by static analysis, (a) the results indicate prevalence of security issues; at least one issue is present for about 46% of the Python packages. In terms of the issue types, (b) exception handling and different code injections have been the most common issues. The subprocess module stands out in this regard. Reflecting the generally small size of the packages, (c) software size metrics do not predict well the amount of issues revealed through static analysis. With these results and the accompanying discussion, the paper contributes to the field of large-scale empirical studies for better understanding security problems in software ecosystems.

Context: Software security engineering provides the means to define, implement and verify security in software products. Software security engineering is performed by following a software security development life cycle model or a security capability maturity model . However, agile software development methods and processes, dominant in the software industry, are viewed to be in conflict with these security practices and the security requirements. Objective: Empirically verify the use and impact of software security engineering activities in the context of agile software development , as practiced by software developer professionals. Method: A survey ( N = 61 ) was performed among software practitioners in Finland regarding their use of 40 common security engineering practices and their perceived security impact, in conjunction with the use of 16 agile software development items and activities. Results: The use of agile items and activities had a measurable effect on the selection of security engineering practices. Perceived impact of the security practices was lower than the rate of use would imply: This was taken to indicate a selection bias, caused by e.g. developers’ awareness of only certain security engineering practices, or by difficulties in applying the security engineering practices into an iterative software development workflow. Security practices deemed to have most impact were proactive and took place in the early phases of software development. Conclusion: Systematic use of agile practices conformed, and was observed to take place in conjunction with the use of security practices. Security activities were most common in the requirement and implementation phases. In general, the activities taking place early in the life cycle were also considered most impactful. A discrepancy between the level of use and the perceived security impact of many security activities was observed. This prompts research and methodological development for better integration of security engineering activities into software development processes, methods, and tools.

Context: Security work in software development is generally under-prioritized. Software developers are not aware of security engineering practices, or find them external to the software development process. To the management, security work presents itself in the form of reactive testing performed out of necessity, incurring only costs in terms of time and resources. The long-term benefits of the security work are more difficult to demonstrate and the security investment harder to justify.

To achieve a level of security that is just right, software development projects need to strike a balance between security and cost. This necessitates making such decisions as to what security activities to perform in development and which security requirements should be given priority. Current evidence indicates that in many agile development projects, software security is dealt with in a more or less "accidental" way based on individuals' security awareness and interest. This approach is unlikely to lead to an optimal security level for the product. This paper suggests Security Intention Recap Meetings as a recurring organisational tool for evaluating current practices regarding the security intentions of a software project, and to make decisions on how to move forward. These meetings involve key decision makers in the project, such as the product owner and the project manager, with the purpose of making security decisions visible and deliberate and to monitor their results

Combining security engineering and software engineering is shaping the software development processes and shifting the emphasis of information security from the operation environment into the main information asset: the software itself. To protect software and data assets, software development is subjected to an increasing amount of external regulation and organizational security requirements. To fulfill these requirements, the practitioners producing secure software have plenty of models, guidelines, standards and security instructions to follow, but very little scientific knowledge about effectiveness of the security they take.

Engineering methods are essential in software development, and form a crucial element in the design and implementation of software security. Security engineering processes and activities have a long and well-standardized history of integration with software development methods. The inception of iterative and incremental software development methods raised suspicions of an inherent incompatibility between the traditional non-agile security processes and the new agile methods. This suspicion still affects the attitude towards agile security. To examine and explore this myth, this study presents a literature review of a selected set of agile secure software development methods. A systematic literature method was used to find the definitive set of secure agile software development methods, of which a core set of 11 papers was selected for analysis, and the security activities documented in the methods were extracted. The results show a wide and well-documented adaptation of security activities in agile software development, with the observed activities covering the whole security development life cycle. Based on the analysis, the inherent insecurity of the agile software development methods can be declared to be a mere myth.

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.