Towards Agile Cybersecurity Risk Management for Autonomous Software Engineering Teams

Abstract

In this study, a framework was developed, based on a literature review, to help managers incorporate cybersecurity risk management in agile development projects. The literature review used predefined codes that were developed by extending previously defined challenges in the literature—for developing secure software in agile projects—to include aspects of agile cybersecurity risk management. Five steps were identified based on the insights gained from how the reviewed literature has addressed each of the challenges: (1) risk collection; (2) risk refinement; (3) risk mitigation; (4) knowledge transfer; and (5) escalation. To assess the appropriateness of the identified steps, and to determine their inclusion or exclusion in the framework, a survey was submitted to 145 software developers using a four-point Likert scale to measure the attitudes towards each step. The resulting framework presented herein serves as a starting point to help managers and developers structure their agile projects in terms of cybersecurity risk management, supporting less overloaded agile processes, stakeholder insights on relevant risks, and increased security assurance.

1. Introduction

Risk is an inherent part of software development. Deadline, budget, and schedule overruns, along with misaligned stakeholders, are but a few examples of risks that are an integral part of development projects [1,2]. Within agile development, risks are implicitly addressed as a natural part of the method’s adaptive nature and applied along the project throughout its many iterations or sprints [2,3]. ‘Implicitly addressed’ in the sense that many of the agile methods in use today (e.g., Scrum, Kanban, Extreme Programming) do not outline specific activities to manage risks [3,4]. Instead, risks are typically managed in an ad hoc manner, based on the intuition and personal experience of project leaders [3,5]. While several formalised approaches to risk management have been proposed for different agile development methods (e.g., [1,5,6]), scant attention has been given to cyber-related security risks [7,8].

Cybersecurity refers to the protection of digital assets against risks (i.e., the probability of a threat agent exploiting a vulnerability) “that exist as a result of the use of the ICT [information and communication technologies] that forms the basis of cyberspace” ([9], p. 100) [10]. Cybersecurity is therefore critical to software development, as can be seen in software vulnerabilities like Heartbleed, Shellshock, Ghost, and Log4Shell, as a few recent examples [11,12], but also to manage unintentional or harmful outcomes of new technologies, such as artificial intelligence [13]. However, considering that the practice of identifying software vulnerabilities is fairly new compared to software development in general [7], an implicit risk management approach can open up for new, project-level cyber threats, that may not be identified in any iterations or sprints. Indeed, managing cybersecurity risks has been shown to require certain skills and knowledge that most developers do not have, and agile teams seldom employ externally [14,15]. A recent review of security integration in agile software development found that security experts were often unavailable, or the role undefined [16]. Cybersecurity risks in agile software projects may thus end up being handled by developers with little or no previous experience of cybersecurity. There are several indicators that additional research in this regard is needed, as cybersecurity risks in agile software development have been found to be managed on an accidental level, based on individuals’ security awareness and interest, rather than through a dedicated effort and structured process [17]. Furthermore, the need for an agile and lightweight cybersecurity risk management methodology is well aligned with modern software development methods such as DevOps, where time to market, and fast, reliable deliveries are the primary goals [18]; by utilising the agile (hence able to handle fast change of direction) approach, time and effort for addressing, prioritising and manage security risks may get more efficient.

1.1. Contribution

To further this research stream, this papers contribution is threefold. First, building upon the work of Oueslati et al. [14], five areas of challenges for developing secure software in agile projects are expanded upon to include cybersecurity risk management aspects and related challenges for people with little or no experience within cybersecurity. Second, the identification of possible solutions (or steps) to address the expanded cybersecurity challenges in agile development projects as gained from the literature review. Third, based on the characteristics of the identified steps, a lightweight, agile cybersecurity risk management framework—with particular consideration for retaining the flexibility of agile development—is proposed and evaluated.

1.2. Organisation

The paper is organised as follows. Section 2 introduces the agile software development practice, cybersecurity risk management, and discusses Oueslati et al.’s [14] five challenges. Section 3 presents the study approach, while Section 4 presents and discusses the findings of the review on cybersecurity risk management in agile software development as seen from the five challenges. It also accounts for the result, i.e., proposes a lightweight, agile cybersecurity risk management framework. Section 5 discusses the overall results including the framework design, and Section 6 concludes the study.

2. Background

2.1. Agile Software Engineering Practices

Agile software development practices have been around since the 1980s, e.g., methodologies such as Scrum [19]. In 2001, many of these frameworks and ideas were popularised by the creation of the Agile Manifesto [20], collecting agile values and principles, and nowadays are commonly used in software development practices, e.g., claimed in the Agile Report 2021 [21]. However, there is a complexity in how and to what extent agile software development is conducted within a company. The notion of hybrid development approaches where traditional methods and processes are combined with agile methods seems to be common and also gradually increasing [22]. At its core, agile practices build upon iterative phases with adaptive planning and requirement collecting, and early (fast) deliveries with a potential to quickly change scope, that can be addressed early in the development stage [20,23].

From the perspective of using Scrum as the underlying agile framework, the following description captures a basic agile setup [23]. In its most fundamental form, agile software development consists of a set of best practices where the scrum master (SM) is the main driver and enabler for the team, facilitating all agile activities (ceremonies). The product owner (PO) is an intermediary role between the software engineering team and the customer, acting as a link between the two in terms of requirements, planning and deliveries. The PO is the key driver (or use a requirement specialist) for collecting the customer’s requirements, and perform planning and prioritising activities accordingly with the team. Preferably, progress in the development phases are shown after each development iteration (called sprint). The backlog refinement session is a planned and recurring activity where the team and the PO go through the existing backlog (i.e., a list of tasks) and re-prioritise if necessary. Another reoccurring activity together with the PO is the sprint planning session, which happens in the end of every sprint including time estimating and re-organising existing backlog items in order to prepare for the next sprint. This ceremony is a tool for adaptation of quick changes and new priorities. Moreover, the retrospective is another ceremony done in conjunction with sprint planning, where the team reflects back on what happened in the previous sprint. The purpose is to identify things that went well or not, in order to adjust and work more efficient in the next sprint.

2.2. The Software Development Life Cycle

A Software Development Life Cycle (SDLC) is a process consisting of a set of phases during which software is designed, planned, implemented and deployed [24]. An iterative SDLC model may complement agile methodologies since agile practices can be used within the iterative software development processes, e.g., agile planning and execution of development tasks may run through cycles of coding and testing. Typically, an iterative SDLC may consist of an initial requirement phase followed by design-, development-, test-, deploy- and maintenance phases, respectively. These phases may differ in scope depending on what development methodologies are used (including tools for code versioning and continuous integration/deployment management), but in general, each phase should seamlessly deliver output to the subsequent phase [24].

2.3. Cybersecurity Risk Management

Risk management is herein focused on cyber-related threats and vulnerabilities, thus excluding areas such as bottlenecks in internal processes, budget fluctuations and lack of general competence and resource management. We refer to the former as cybersecurity risk management. Note that assessing cybersecurity maturity and meeting security regulations is also included, coupled with the threat and vulnerability perspective. A few examples of related frameworks are: NIST Risk Management Framework [25], with a general approach for risk assessment and cybersecurity management within a SDLC; ISO/IEC 27005:2018 [26], which is a standardisation with general guidelines for cybersecurity risk management, i.e., the security software engineering perspective is only a subset of the standard; and Security Engineering Risk Analysis (SERA) method [27], which integrates threat modelling and risk analysis. Although SERA is not exclusively for software engineering, but also considers system architecture, sociotechnical and cyberphysical aspects, the scenario-based approach integrates well with any type of threat modeling practice.

2.4. Five Challenges in Agile Risk Management

In their review, Oueslati et al. [14] identified a series of challenges related to agile development of secure software that they grouped into five categories. The five challenges have been revisited herein, but extended with additional references to include challenging aspects of cybersecurity risk management. The five challenges ($C_1$–$C_5$) are presented as follows.

2.4.1. Software Development Life Cycle

This challenge refers to the differences in process structure between agile software development and cybersecurity risk management. Considering cybersecurity risk management is often performed in a sequential, or ‘plan-driven’, fashion (identifying, analysing, controlling, and monitoring risk) [28], it does not always align well with the lightweight, change prone, and adaptive qualities of agile methods. Instead, cybersecurity risk management may overload the agile method since additional requirements introduced between sprints must be assessed [2,3,29,30]. Indeed, cybersecurity risk management activities can consume a lot of time [31,32], which has been reported as a potential stressor for practitioners with little or no previous experience within cybersecurity [33]. We denote this challenge as $C_1$.

2.4.2. Incremental Development

This challenge refers to maintaining an assessment of cybersecurity risks that is aligned with the incremental progression of agile projects. Continuous changes to code, directions, and features may also lead to inconsistencies between the development project and the management of cybersecurity risks [17,34]. For example, code that has been analysed for vulnerabilities and threats may fundamentally change over time as the project moves along, requiring a new assessment as changes are made. We denote this challenge as $C_2$.

2.4.3. Security Assurance

While code can, to some degree, be tested and evaluated for security vulnerabilities, and tools be used to map different types of threats, there is still a challenge to disseminate the resulting report to different audiences. For example, while cybersecurity risk management may benefit from threat analysis and modelling tools reporting to business unit management, these reports do not necessarily translate well into technical, software architecture objectives [35]. Similarly, it is not always evident to whom a developer should report new threats and vulnerabilities to, since it may not be clear who owns the security requirements [36]. As such, it remains a challenge to assure that the current development of a software has adequately addressed identified security risks. We denote this challenge as $C_3$.

2.4.4. Awareness and Collaboration

This challenge refers to formulating and establishing security requirements between customers and developers. Lists consisting of security requirements do not always fit within the agile workflow. For example, considering lists do not take the software context or project backlog into account [15], threats that only arise in certain contexts (e.g., through mistakes or “blind spots” in developers’ decision-making process [37]) might not be included in the list [38]. Nor is it evident what—if any—of the requirements on the list are relevant, to what extent, or where to be implemented [32]. Furthermore, even with highly relevant lists, such as the Open Web Application Security Project’s (OWASP) top 10 most common vulnerabilities, any type of requirements list implies addressing all of its items in the first development iteration [34]. Lastly, established cybersecurity requirements have also shown to cause stress among practitioners with little or no previous experience within cybersecurity, who may feel inadequate with regard to their skills if not familiar with the concepts listed [39]. We denote this challenge as $C_4$.

2.4.5. Security Management

This challenge refers to the incentive to develop more secure software and the return on investment. Putting additional efforts into making a software more secure will also increase its development cost (in terms of time and/or money), but the initiative does not always result in a more profitable product [40]. Furthermore, studies suggest that allocating more time and effort to security among developers is unlikely to be successful since developers are, most often, not software security experts [41,42]. It is therefore “quite unjustified to handover this critical task to individuals having limited knowledge and background of software security” ([16] [p. 64]). As a result, software security risks tend to be addressed late, with limited follow-up, and initiated by errors or compliance requirements—rather than as part of a formal, continuous risk management process [17]. We denote this challenge as $C_5$.

3. Method

The method applied in this study is divided into three phases, all of which were carried out by both authors in collaboration. First, a review of the literature on risk management in agile software projects to identify challenges and possible solutions to those challenges was conducted. Second, building upon the result of the review, the characteristics of the possible solutions identified were surveyed among developers as a first valuation of their relevance. Lastly, the characteristics were incorporated into a new framework towards agile cybersecurity risk management for autonomous software engineering teams.

3.1. Literature Review

The stages of the review were inspired by Levy and Ellis’ [43] review process and organised into two sequential activities: collect articles and extract relevant information; followed by analysing and reporting the findings.

3.1.1. Data Collection and Extraction

Articles were collected using IEEE Xplore, ACM Digital Library, and Google Scholar. The search strategy used included combinations of the terms “security” + “risk management” + “agile (software OR project OR development)”. Considering the space limitation, a maximum of 15 articles was set. Only the most relevant articles from the search strategy were considered, and the titles and abstracts of each article were therefore examined to verify for inclusion. After this initial screening, only articles that were written in English and that included aspects which fell within the definition of cybersecurity as given in Section 2.3 were kept. The remaining articles were then divided among the authors and read. Text that reflected upon any of the five challenges was extracted and grouped for the analysis and reporting activity [44]. In practice, this also meant the authors examined each extraction and discussed the motivation thereof to resolve any differences.

3.1.2. Analysis and Reporting

Considering the focus of the review—to gain insights into challenges and solutions of risk management in agile projects—a concept-centric approach [45] was used that consisted of the five challenges expanded upon in Section 2.4. The challenges thus acted as predefined codes (or themes, noted as $C_1$–$C_5$), forming a lens through which the articles were analysed. The extracted texts were re-read and sections that elaborated on one or more of the five challenges were “lifted out” and grouped together under their respective code. Lastly, the resulting text under each code was then discussed between the authors and synthesised into a coherent text that reflected the challenge and the potential solutions identified to it. This collaborative approach and comparative discussion made it possible to reach consensus and help prevent over interpreting the data.

3.2. Framework Development

The development of the framework was organized into two activities: survey the attitudes towards the characteristics of the possible solutions identified from the literature review; and analyse the data to sort the characteristics into steps following the SDLC and agile software practices.

3.2.1. Attitudes towards Identified Characteristics

The lack of validation has previously been reported as one of the biggest problems identified in cybersecurity risk management [46]. Subscribing to this concern, an online survey was developed. Note, however, that the purpose of the survey was not to generalise the result of the study or to compare populations. Rather, the survey was used as a first indication of a reality check based on the attitudes towards the characteristics of how each challenge could be addressed. That is to say, it served to provide a better understanding of the relevance towards the possible solutions of cybersecurity risk management challenges in agile projects that were identified in the literature review. As such, random sampling was not used. Instead, the survey was sent out to software developers in eight different companies (four consultancy based companies developing information systems, two organisations within bank and finance, and two government agencies in Sweden housing their own development departments), totalling 145 recipients.

Along with the survey, a consent form was included about the anonymity of the responses and the role of the data collected. No names were requested in the questionnaire. The questions consisted of five statements created from the challenges and proposed solutions as gained from the literature review. To increase validity of the survey, one additional, but opposing, statement was added for every question (resulting in 10 questions in total) in order to confirm coherent responses. The respondents could answer with behaviour and belief variables assessed on a four-point Likert scale: strongly disagree, disagree, agree, and strongly agree [47]. Included in the survey was also a self-assessment regarding the respondents experience with agile development, secure software development, cybersecurity and risk management, ranging from: not at all experienced, slightly experienced, very experienced, or extremely experienced.

3.2.2. Analysis and Sorting

The measured attitudes were used as an indicator, regarding whether or not the characteristics should be further developed into steps and included in the final framework. The threshold value for inclusion was set to >50% to account for possible ambiguity in the answers, whilst at the same time allowing for weak indicators. While the responses associated with each characteristic’s opposing question did not affect the threshold value for inclusion, it did serve as an indicator for inconsistencies in the answers. Any such inconsistencies were noted down and reflected upon in the result.

To strengthen the validity of the inclusion decisions, the respondents’ levels of experience were also taken into account. To do this, the respondents were sorted into two groups based on their self-assessment on cybersecurity and risk management experience, i.e., (1) very experienced and extremely experienced, and (2) slightly experienced and not at all experienced. Similarly, the threshold value was matched against the aggregated answers of agree and strongly agree. The survey answers were then examined. Any characteristics that reached an aggregated attitude higher than 50% from the experienced group were noted to be further developed into steps and included in the framework.

Insights from the challenges and possible solutions as identified in the review along with the associated attitudes thereof were then organised and sorted as components of the SDLC phases (as outlined in Section 2.2) and aligned with the agile software engineering practices (as described in Section 2.1). In practice, this meant the authors went back to the characteristics of how each challenge could be addressed, and formulated these into steps that took the values and flexibility of agile development into account. These steps were then sorted into the phases of the SDLC. As such, the resulting proposed framework was delimited to the six SDLC phases and the systems development team limited to the typical roles: system developers, QA engineers, SM, and PO.

4. Results

In the following section, the analysis of challenges and possible solutions to cybersecurity risk management in an agile development is first presented (an overview can be seen in

Table 1. Overview of articles reviewed where the $C_n$ columns shows which of the cybersecurity related challenges have been addressed, the survey column indicates if the study is validated with a survey study, case study type is either with students or professionals and RM methodology the used framework.

Paper	Year	${\mathit{C}}_1$	${\mathit{C}}_2$	${\mathit{C}}_3$	${\mathit{C}}_4$	${\mathit{C}}_5$	Survey	Case Study Type	RM Methodology
Nelson et al. [48]	2008	✓						Students, Industry	Using Scrum
Franqueira et al. [49]	2011	✓	✓		✓	✓			Using Scrum
Tomanek, Juricek [50]	2015	✓	✓			✓	✓		PRINCE2
Dorca et al. [51]	2016	✓				✓	✓	Industry	COBIT using Kanban
Maier et al. [52]	2017			✓	✓		✓	Industry	Using Scrum
Hammad, Inayat [53]	2018	✓	✓			✓		Students	Brainstorming
Odzaly et al. [54]	2018	✓	✓					Students	Agile Risk Tool
Ripolles et al. [55]	2018	✓	✓		✓		✓	Industry	Using agile practices
Hurtado et al. [56]	2019	✓	✓	✓	✓			Students	Gamification
Chaoucha et al. [1]	2019	✓	✓				✓		Using Scrum
Newton et al. [57]	2019	✓		✓	✓			Industry	Using agile practices
Tavares et al. [3]	2020	✓	✓				✓	Industry	Rm4Am
de Souza Lopes et al. [58]	2021	✓	✓		✓	✓		Students, Industry	RIMPRO
Hauck and Vieira [2]	2021	✓	✓			✓	✓		Using agile practices
Kagombe et al. [59]	2021		✓	✓	✓			Industry	Using Scrum

). Building on the characteristics on how the five challenges have been addressed, the attitudes towards these are then presented as gained from the survey (see Figure 1 and Figure 2). Finally, based on the identified characteristics, an agile cybersecurity risk management framework is proposed (see Section 4.7).

4.1. Software Development Life Cycle

All but two articles addressed $C_1$ (see Table 1), either by incorporating (or merging) risk management activities into current agile practices, or vice versa. Hence, primary risk assessment, identification, and security requirement activities were injected into iterations or sprints. Different approaches were noted, e.g., gamification practices in an agile, proactive manner [56], and in general part of standard agile (planning and daily/weekly) ceremonies [2,50,51]. Awareness and attitude towards security requirements as a team effort were also found to be a success factor in ‘shifting security left’, i.e., to encourage security testing early on to provide more time to address identified issues [57]. Nelson et al. [48] pointed out that agile in itself could be regarded as a risk driven process with continuous re-prioritisation of risks and an iterative approach to manage and mitigate risk elements, but that it is not to sufficient, and adjustments and new methodologies were introduced after the case study to strengthen the risk management part.

4.2. Incremental Development

Similarly to $C_1$, most articles addressed the challenge of risk assessment aligned with potential rapid change, however described in a variety of detail. For example, in Kagombe et al. [59], the authors recognised the challenges of keeping software product up to date with cybersecurity as it takes considerable time for security teams to develop requirements that must then be coordinated retroactively with the development team. To counter this, Kagombe et al. [59] propose a initial phase in the very first sprint where baseline security requirements are developed, if new cybersecurity risks appeared, they were discussed in sprint reviews and left for the PO to update the backlog.

4.3. Security Assurance

A few of the reviewed articles did elaborate on security assurance as part of agile software projects $C_3$—such as security testing, tests for vulnerabilities and conflicts with audit needs. For example, in [56], gamification was used as an underlying framework for security assurance. During the product engineering phase, test and coverage was addressed explicitly as an activity to consider. However, no explicit risk assessment processes described in detail how security testing should be conducted within the scope of risk management. In their study on critical success factors of secure software development in agile projects, Newton et al. [57] noted that risk management cannot be addressed in an ad hoc manner, but must be included both in the initial outset of a project and for each sprint or iteration thereafter to be able to adjust the planned workflow to address new risks. Similarly, Kagombe et al. [59] proposed conducting security validation of the software product in each retrospective, using a predefined system architecture that included security requirements as a baseline for comparison. While Maier et al. [52] proposed the use of automated static and dynamic code analysis to identify security vulnerabilities, where each bug is then added to a tracking system, like Jira. Both Newton et al. [57] and Maier et al. [52] recommend pair-programming as a way to overcome some of the challenges related to $C_3$.

4.4. Awareness and Collaboration

The challenges associated with the lack of security awareness and experience were addressed in a few articles [49,55,56,58]. The typical approaches were either building up a knowledge base or involve external security experts in cyberseurity activities. For example, bug bounty programs and penetration testing have, although being costly and time consuming, been proposed as solutions if the team does not possess the necessary baseline level of security skills and awareness within the agile teams [57]. In Kagombe et al. [59], a data flow diagram was developed in an early stage as a baseline of the project. Dependencies, security threats and vulnerabilities were then identified using lists such as OWASP top 10, and added to the baseline as ranked risks.

4.5. Security Management

About a third of the investigated frameworks had one or several methods for connecting the agile RM activities to stakeholder and/or upper management in terms of ROI and/or including (motivating) further risk assessment and mitigation, e.g., inviting a security expert from the stakeholder/client side after each iteration, planned activities for creating and presenting risk reports (when necessary) or continuous reporting to stakeholders via risk backlogs [2,49,50,51,53,58]. However, it is not clear if that would suffice as the basis for such strategic decisions on budget and continuation of further security activities. Although, estimations have indicated that an agile approach to risk management can decrease the expected time—and subsequently cost—spent [52].

4.6. Attitudes of Solutions Characteristics

The survey consisted of a self-assessment and statements derived from the characteristics of how each challenge in the previous section had been addressed was sent out to 145 recipients. Out of these, n = 41 (145) replied. The majority, or 66% of the respondents, had more than eight years of experience working as a developer, 29% had between 3–8 of experience, and 5% between 0–3 years. The security related self-assessment is outlined in Figure 1.

Statements regarding the attitudes of the five challenges are collected in Figure 2, where each challenge was addressed by two opposite statements in order to capture the attitudes as firm as possible. A visualization of the filtering of experiences is shown in Figure 3.

The statement structure and motivation was as follows:

• One possible solution of incorporating risk management into the rapid and dynamic nature of agile project ($C_1$) was characterised by injecting risk management activities early on and in an iterative fashion. As such, this characteristic was posed as two opposing statements that $C_1$-1) daily stand-ups should include a short walk-through of new, current, and unmitigated cybersecurity risks along with a quick, initial assessment, and that $C_1$-2) daily standups should only consider quick updates and getting to the point, there is no time to discuss cybersecurity risks.
• The challenge of continuously aligning identified risks with new code changes and features ($C_2$) was found to have been addressed by developing a form of reference model by which new features could be compared to. This was characterised as something that should occur early on in the project, and posed as two opposing statements that $C_2$-1) sprint planning is a good time to include the prioritisation of security requirements, and that $C_2$-2) security requirements should be managed separately and not included in sprint planning.
• Security testing to identify new vulnerabilities and conflicts with audit needs has been noted as one challenge within secure agile software development ($C_3$). Solutions towards this particular challenge was characterised by activities to be taken throughout the project. As such, this characteristics was posed as two opposing statements that $C_3$-1) backlog refinement is a good time to identify mitigation actions (e.g., new code changes to fix security risks), and that $C_3$-2) backlog refinement should not explore details for new changes (e.g., configurations or code changes).
• Suggested solutions to the lack of security awareness and experience within the development team ($C_4$) were to build up this know-how either internally or externally, as the project moved ahead. This characteristics was therefore posed as two opposing statements that $C_4$-1) sprint retrospective should document lessons learned from mitigated cybersecurity risks, and that $C_4$-2) sprint retrospectives should not spend time on documenting lessons learned.
• The challenge of when to report to stakeholders and management on cybersecurity risks was addressed by continuous reporting via backlogs. As such, this characteristics was posed as two opposing statements that $C_5$-1) all cybersecurity risks found should be collected and reported to stakeholders and management iteratively, and that $C_5$-1) only severe cybersecurity risks should be collected and reported to stakeholders and management when necessary (ad hoc).

The primary analysis of the survey results is concluded into a set of indicators. For $C_1$ the respondents leaned slightly towards a disagreeing attitude to include quick risk assessments during daily stand-up: 58.44% disagree and 41.56% agree in $C_1$-1. However, when filtering on respondents with experience in cybersecurity and risk management, i.e., only on very-, and extremely experienced respondents, the attitude leaned towards agreeing with 55%, and for the negative in $C_1$-2 60% disagreed to not include risk assessment. Therefore, we conclude that there is a weaker but positive indication to include a lightweight risk assessment activity during daily stand-ups. For inclusion of prioritization and management of security requirements, 90.25% had an agreeing attitude in $C_2$-1, thus a strong indicator to include such step into the framework. We note that no filtering on security and risk management experience is taken into account, as with $C_1$, due to the significant majority of agreement.

Attitudes towards $C_3$-1 showed that 68.29% agreed on including risk mitigation planning during backlog refinement, and at the same time the negative, i.e., $C_3$-2 showed that 63.41% agreed on not including other activities out of scope of backlog refinement. This slightly skewed difference could indicate a misunderstanding of the negative formulated question, but when filtering to respondents with experience in cybersecurity and risk management, $C_3$-2 shows 50% disagreement on including other activities, thus we interpret these proportions to include the risk refinement and risk mitigation steps in the framework. Regarding $C_4$, there was a clear majority of an agreeing attitude to include knowledge transfer activities during retrospectives, regardless of respondents experiences. For all respondents 63.42% agreed in $C_4$-1 and even 80.49% disagreed to not include lessons learned documentation in $C_4$-2, hence the inclusion of a knowledge transfer step into the framework is clearly indicated by the answers. Finally, 85.37% of all respondents indicated agreement towards including an iterative process of cybersecurity risk escalations rather than on an ad hoc basis, i.e., $C_5$-1. For $C_5$-2, 58.3% disagreed to escalate cybersecurity risks on an ad-hoc manner. We therefore conclude that an iterative risk escalation step should be included in the framework.

4.7. An Agile Cybersecurity Risk Management Framework

The proposed framework (depicted in Figure 4) is divided into five steps, each of which addresses one or more of the five challenges discussed in Section 2.4, with subsequent activities (see

Table 2. Defined steps of the proposed framework including output for each activity, and corresponding challenges that are addressed.

Framework Step	Activity	Output	Challenge
Risk collection	Daily stand-up	Defined RI	$C_1$
	1st risk assessment	Defined RI	$C_1,C_2$
Risk refinement	Backlog refinement	Prioritisation	$C_1,C_2,C_4$
	2nd risk assessment	Defined RI	$C_1,C_2,C_4$
	Requirement management	Requirements	$C_1,C_2$
	RI prioritisation	Prioritisation	$C_1,C_2$
Risk mitigation	Sprint planning	Prioritisation	$C_2,C_3$
	Task execution	Risk mitigation	$C_2,C_3$
Knowledge transfer	Retrospective	Knowledge	$C_4$
Escalation	Escalation to stakeholder	Prioritisation	$C_5$

). Based on the characteristics of the solutions identified for challenges $C_1$ and $C_2$, a first step in an agile cybersecurity risk management framework is proposed to include risk assessments, to be connected to daily and weekly ceremonies and thus directly impact requirement and development changes. However, to avoid security teams from developing requirements that are then coordinated retroactively with the development team [59], these early assessments are proposed to consist of only a first, initial collection and subjective prioritisation—not a full risk analysis and evaluation, which could otherwise overload the agile project [2,3,29,30]. As such, this first step is referred to as a Risk Collection. A deeper analysis of the early assessed risks is instead carried out later on, e.g., during the backlog refinement to allow for more natural re-prioritisation of mitigation work, and is therefore referred to as the Risk Refinement.

To counter the challenge of undocumented experience and knowledge ($C_4$), e.g., gained from the risk assessments, a session for discussing and documenting lessons learned related to cybersecurity during the retrospective is proposed, here referred to as the Knowledge Transfer. Similarly, to alert stakeholders and management on relevant risks to better delegate effort and resources ($C_5$), an iterative Escalation activity is included throughout the entire process to refrain from severe risk being addressed late and with limited follow-up [17].

Although the framework is team-centred, it consists of activities towards upper management and stakeholders as well. The framework uses the following terminology: Risk Item (RI), which refers to an identified and described risk; Risk Backlog (RB), which is the list of all RI’s for the team and will act as the primary documentation of the overall risk management; and Security Activity (SA), which refers to any type of activity that generates output to be used by the risk assessment framework, e.g., threat modelling exercises, code reviews, SAST reporting, or internal audits ($C_3$).

The frameworks steps are as follows.

Risk Collection:

This step consists of two activities: (1) a daily walk-through of new, current and unmitigated risks, and (2) a quick initial risk assessment, RI creation and prioritisation (a maximum of a few minutes of assessment). These activities should be extensions of the daily stand-up, i.e., a natural part of the daily synchronisation work. Input to these activities should be established SA that are parts of the SDLC, e.g., static code analysis tools, monitoring or code review exercises, thus any type of SA should feed data to these daily activities. Any risk assessment framework can be used for the risk assessment part of the step.

Risk Refinement:

This step consists of a weekly, or bi-weekly, walk-through of the cybersecurity RB and could be an extension of the regular backlog refinement ceremony, hence the PO is part of this step. This activity aims to create better understanding and overall prioritisation of the current RB. A second risk assessment of the RI:s should occur with a deeper analysis than the initial activity in the previous step. A first element of knowledge transferring may happen within this step. In this step, each RI should also be described with a mitigation proposal and aligned with requirements (or lead to new requirements that affect the ordinary backlog). This step should produce RI:s that are ready for the next sprint planning. Any risk assessment framework can be used for the risk assessment part of the step.

Risk Mitigation:

This step’s aim is to enforce risk mitigation tasks, e.g., executing explicit code changes, introduction of new processes or knowledge-sharing activities. From the previous step, these mitigation activities should be part of the sprint goal and committed to by the team as usual user stories. Each mitigation task should describe activity and testability, i.e., what to do and how to test (validate) it. To clarify, this step starts with the sprint planning and continues throughout the sprint where the mitigation tasks are completed. We note that specific SA may be executed due to dependencies for certain mitigation tasks, e.g., renewed (architecture) threat modelling or code reviews to ensure the mitigation solution is secure.

Knowledge Transfer:

This step could be merged with the ordinary sprint retrospective. The aim is to draw conclusions from the risk mitigation work, hence building knowledge. It should also enable space for further knowledge sharing, e.g., by inviting security experts and others, and walk-through the mitigation and solution of a risk; from this activity the team broadens the cybersecurity competence and any key-takeaways should be systematically documented in a shared team space. It should also include low intensity training in all areas of SA in the SDLC.

Escalation: 

A reporting activity to stakeholders and management with escalations is needed in an iterative manner. The team and PO provides a list of high risks to escalate to management and/or further assessment for RI:s that may have heavy impact on the budget or overall re-prioritisation. This step should be done frequently (at minimum weekly) and produce the top priority risks to share with management.

Table 2 summarises the proposed activities and sub-activities to be performed in each step including the expected output. For example, the risk collection step should output new defined RI:s (if there are any identified risks) and the risk refinement step should output further defined RI:s along with a prioritised RB and possibly new/changed security requirements. We underline that the explicit methods for finding, documenting and prioritising risks is not part of the framework itself, but rather to be chosen dependent on the underlying SDLC structure and already established SA practices. Any suitable risk assessment method could be used for the risk collection and refinement steps.

5. Discussion

In this study, we set out to identify how challenges associated with cybersecurity risk management in agile software projects have been addressed in the literature, and through these insights propose a framework for agile cybersecurity risk management. In our review, we found two primary approaches: some research explored the idea of incorporating agile practices into the existing risk management processes, e.g., [48,51], that is to say, using agile tools for handling risks. While others investigated specific risk management frameworks that were fused into already existing agile software development processes, e.g., [54,58,60]. Regardless, we could not identify if either approach is beneficial over the other in terms of addressing the five identified challenges. However, by building upon insights gained from these studies to address the challenges, our study extends previous research, but also complement previous reviews on agile risk management, such as Albadarneh et al. [61] and Tomanek and Juricek [50].

To get an indication of whether or not the characteristics of how the identified challenges could be addressed, statements based on these characteristics were formulated and served as the basis for surveying their relevance. These statements also served as the foundation for the proposed framework. As such, one limitation of the study is that the survey targeted the attitude towards the framework’s steps, but not the framework as a whole. Furthermore, considering the sample size, no statistical tests were used to find significant relationships from the respondents data. Instead, the survey was used to provide an external indicator on the steps appropriateness, but not to generalise the results. Future research is therefore recommended to further refine and validate the findings. To overcome some of the limitations of this study, qualitative studies (e.g., case-studies, observations, and interviews) are recommended to increase the scope of knowledge of cybersecurity in agile development teams (e.g., motivations, challenges, and enablers), but also to test and validate the proposed framework presented herein. In practice, this could lead to new insights on how, when, and whom should perform risk management activities in agile software development projects.

The resulting framework addresses the five identified challenges and incorporates insights gained from the review in five different steps: risk collection, risk refinement, risk mitigation, knowledge transfer, and escalation. The risk collection and risk refinement steps are designed to address $C_1$ and $C_2$, since all security activities are tightly connected to daily and weekly ceremonies and directly impact requirement and development changes (via re-prioritisation). Additionally, due to frequent assessment of risk impact in the risk refinement step, the team have a continuous attention on the risk mitigation work and can re-prioritise and change accordingly. The risk mitigation step therefore enforces clear definitions of mitigation activities and testability thereof. Hence, both $C_2$ and $C_3$ are addressed due to security tests and validation of requirements. The knowledge transfer step ensures the team focuses on lessons learned, and broadens the overall cybersecurity competence in a natural way, by extending the ordinary sprint retrospective, thus covering $C_4$. Finally, the escalation step is by all means the simplest form of escalation, but should be formalised as part of the framework for clarity. Since the escalation step is towards stakeholders and management, it directly address $C_5$.

6. Conclusions

We have proposed a team-centric cybersecurity risk management framework with frequent attention to risk and less administration in mind. The framework was developed to address five main cybersecurity risk management challenges for software developers, while supporting the agile development process. The framework resulted in five steps built from insights gained from a review of related literature, and further validated by a survey to software development professionals in both the public and private sector. The primary findings when constructing the framework were to include clear and iterative knowledge transfer activities, a natural fusion of risk assessment and planning, into existing sprint planning and backlog refinement sessions for lightweight purposes, and risk escalation to management in an iterative manner rather than an ad hoc basis. The review also showed that many of the existing agile risk management frameworks did not explicitly address cybersecurity risks in general, in terms of the two challenges of security assurance ($C_3$) and security management ($C_5$). Moreover, the proposed framework addresses cybersecurity risk management without adding to many additional layers of security practices; most activities are either extensions of already existing agile practices or smaller short-time level activities with high frequency, hence keeping a continuous attention to risks. Finally, we propose future research to validate the proposed framework of this study through, e.g., case-studies of practical application and testing by agile software development teams in a context where cybersecurity issues are relevant.