Article Preview
TopIntroduction
Agile methods were initially seen as ideal for non-critical product developments. However, during recent years there have been several initiatives for the adaptation of agile methods for domains also in critical areas, such as, medical devices (Fitzgerald, Stol, O'Sullivan, & O'Brien, 2013) (McHugh, McCaffery, & Coady, 2014) and money transfer systems (Baca, Boldt, Carlsson, & Jacobsson, 2015). That is, in situations where security risks are prominent characteristics. Despite these risks, most existing agile development methods hold an improvement-potential with regards to security aspects, e.g. the work by Cruzes et al. (Cruzes, Felderer, Oyetoyan, Gander, & Pekaric, 2017). As a result, security is often added afterwards or included in the process by way of external resources. While there exist alternatives, such as, discrete security methods (such as checklists, management standards, etc.) that can supplement agile methods, few of these integrate into agile methods in a seamless, quality-enhanced yet cost-efficient manner.
In traditional software development processes, a security officer (also known as the product owner of security) performs audits or acts as a security advisor to the developers usually handles all matters related to security. However, in an agile development process, where iterations are short and changes made by the minute, it is not always possible to include a security officer from the outside, neither to integrate complementary discrete security methods in the process.
In terms of security, a general drawback with agile methods is the lack of a complete and updated picture of how all of the software requirements are implemented, which often results in difficulties to grasp let alone analyze the risks. Moreover, security flaws are often either overlooked or handled in an insufficient way. Due to the general work method in agile development, it is typically not possible to integrate systematic risk analysis in such a way that usable yet probable results are yielded. It is therefore important to predict how different ways of adding security aspects to agile processes will improve the security of the final product, in order to make sure that any additional costs due to the addition of security aspects are motivated by increased product security.
The work in this paper uses quantitative measures from risk analyses on a software product developed using an agile software development process. Thus, the risks identified in the risk analyses are used as indicators of the software product’s security level, i.e. risk data was used as a way to estimate the end-product’s level of security. In addition, the risk analysis data also reflects the efficiency of the agile team members in identifying risks in the software, as well as addressing them at an early stage. Although there exist other indicators of the level of security in software being developed (e.g., measures from security test cases or code reviews) that also could be used, those are considered out of scope for the focus of this study. Further, there is also a correlation between software security and software quality that must be taken into account. More precisely, there is a need for cost-efficient processes, tools, and guidelines for developing security-critical software in an agile way. In this work, our first task and contribution is to find a way to systematically integrate security management (including risk analysis) in agile software development project while at the same time meeting all the other software requirements with both quality and cost-efficiency. While our second task is to evaluate the security effects of the enhanced agile process in the development of a security-critical software product in an industrial setting.