Abstract. Security testing can broadly be described as (1) the testing of security requirements that concerns confidentiality, integrity, availability, authentication, authorization, nonrepudiation and (2) the testing of the software to validate how much it can withstand an attack. Agile testing involves immediately integrating changes into the main system, continuously testing all changes and updating test cases to be able to run a regression test at any time to verify that changes have not broken existing functionality. Software companies have a challenge to systematically apply security testing in their processes nowadays. There is a lack of guidelines in practice as well as empirical studies in real-world projects on agile security testing; industry in general needs a more systematic approach to security. The findings of this research are not surprising, but at the same time are alarming. The lack of knowledge on security by agile teams in general, the large dependency on incidental pen-testers, and the ignorance in static testing for security are indicators that security testing is highly under addressed and that more efforts should be addressed to security testing in agile teams.

It is claimed that integrating agile and security in practice is challenging. There is the notion that security is a heavy process, requires expertise, and consumes developers' time. These contrast with the agile vision. Regardless of these challenges, it is important for organizations to address security within their agile processes since critical assets must be protected against attacks. One way is to integrate tools that could help to identify security weaknesses during implementation and suggest methods to refactor them. We used quantitative and qualitative approaches to investigate the efficiency of the tools and what they mean to the actual users (i.e. developers) at Telenor Digital. Our findings, although not surprising, show that several barriers exist both in terms of tool's performance and developers' perceptions. We suggest practical ways for improvement.

International audienc

Currently, security requirements are often neglected in agile projects. Despite many approaches to agile security requirements engineering in literature, there is little empirical research available on why there is limited adoption of these techniques. In this paper we describe a case study on challenges facing adoption of the Protection Poker game; a collaborative and lightweight software security risk estimation technique that is particularly suited for agile teams. Results show that Protection Poker has the potential to be adopted by agile teams. Key benefits identified include good discussions on security and the development project, increased knowledge and awareness of security, and contributions to security requirements. Challenges include managing discussions and the time it takes to play, ensuring confidence in the results from playing the game, and integrating results in a way that improves security of the end-product.

The goal of secure software engineering is to create software that keeps performing as intended even when exposed to an active attacker. Threat modelling is considered to be a key activity, but can be challenging to perform for developers. Microsoft has tried to lower the bar through creating a threat modelling game called Elevation of Privilege (EoP), but anecdotal evidence suggests that it has seen little use in actual development projects. To learn more about challenges facing adoption of EoP, we performed a case study in a university setting comprising several agile development projects. The results show that the game aided in discussing and learning about software security, but the impact on development seems to have been limited. In addition, challenges related to game dynamics, relevance of hints on the cards, and the time needed to play the game, limits the acceptance of the game.