We advocate a change of perspective in the question of agile secure software development and analyze what makes it di cult to address security needs in Scrum. The literature focuses on the integration of security activities into agile development processes. However, detailed prescriptions for security work would be misplaced in a generic management framework like Scrum. Therefore we take a closer look at the tensions between Scrum's way of organizing work and the characteristics of security requirements. Our previous work suggests that Scrum works well as a management model and security development requires iterations as in agile development, yet Scrum teams can fail to address security needs due to their low visibility, competing objectives, and Scrum's division of labor. Tensions arise as Scrum is optimized to ful ll explicit requirements and maximize business value, whereas security is often an implicit requirement with a di erent value proposition, which nevertheless requires substantial work and cannot be addressed by bug xing or quality assurance alone. As a consequence, promising research directions are the re ective discovery of security needs, the valuation and prioritization of security work, collaboration between Scrum teams and security experts, and veri cation and feedback mechanisms for security.
When agile software development entered the scene [
Agile frameworks like Scrum [
However, the most popular agile methodology, Scrum, is a management framework purposefully honed down to the essentials of roles, responsibilities, and collaboration. Scrum does and should not prescribe development work in detail, but rather aims to create an environment where development teams can self-organize and take responsibility for their work while being managed to the extent necessary for a project to succeed. The key to this management scheme is the delicate balance between the respective responsibilities and spheres of relative autonomy of the development team and the product owner. Organized collaboration between these roles, with the scrum master as a facilitator, aims to ensure that development moves in a productive direction at any time, this direction gets adjusted as requirements change or are better understood, and management antipatterns like micromanagement do not occur.
Our own previous work shows two opposite tendencies. On the one hand,
security requirements engineering needs iterations, because design decisions change
security properties and adversaries may adapt their behavior to available attack
opportunities [
In this paper we synthesize our previous work on security requirements and on security work in a Scrum team. We theorize about tensions between the characteristics of security requirements and security work on the one hand and the way Scrum manages development work on the other. Analyzing the de nition of Scrum, we nd three di erent ways of managing security work: as bug xing on demand, continuously as a quality requirement through the de nition of \done," or as prioritized and planned development work through the product backlog. We discuss the capabilities and limitations of these approaches and nd each of them inadequate. On-demand xing rarely leads to substantial security improvement. As a quality requirement, security has a complex relationship with development work and is di cult to verify. Security features in the backlog would be a suitable approach to many security concerns, but they compete with other requirements and also may need special expertise to design and implement e ectively.
We argue that research aiming to reconcile security engineering with agile development should consider not only the execution of security activities in an agile process, but also these challenges of managing security work in agile frameworks. Our analysis suggests four areas of security tasks that are worth investigating and supporting: the re ective discovery of security needs to create backlog items, the valuation and prioritization of security work, agile veri cation and feedback in the security dimension, and the collaboration of Scrum teams with external security experts and consultants.
Agile software development [
Agile frameworks like XP and Scrum implement the values and principles of
agile development, specifying management structures, processes, artifacts, and
practices. They organize development work in short, incremental iterations with
feedback loops and specify team activities focused on communication and
coordination. While Scrum is strictly focused on management aspects|roles,
interactions, artifacts|XP also prescribes practices like pair programming and unit
testing. Around these frameworks a range of practices [
While agile practices have been widely adopted and became the prevalent
paradigm of software development, they have also downsides. Agile
development pursues con icting goals di cult to balance, such as continuous delivery
of software and continuous learning [
Security experts tend to be skeptical about the ability of agile development to
produce secure software. Some evidence supports this view: security has a strong
non-functional, quality component [
Various proposals and investigations have appeared over time regarding
security activities in agile development processes [
Ben Othmane et al. [
Rindell et al. argue in a recent literature review [
To protect a system or software product against malicious attacks, its developers
have to avoid vulnerabilities that attackers might exploit. Vulnerabilities are
introduced inadvertently and it takes additional e ort to prevent or remove
them. They often appear in side-e ect behavior, which does not a ect normal
use and operations but can be triggered by attackers [
Understanding the security needs of a system under development is a
problem of requirements engineering, but security needs are not requirements like any
other. Security needs are shaped by three interdependent components [
Due to these interdependent aspects, security requirements cannot be elicited from stakeholders alone. The design and implementation of a development product itself is a major source of security needs. Architectural decisions, technology choices, and implementation detail lead to new or re ned security concerns.
The relationships between the three components are complicated. Simple oneto-one mappings between threats or security goals on the one hand and design choices on the other are rare. While implications may exist so that necessary security functions can be identi ed, it is often insu cient to implement only these functions|security is not only a set of features.
Security requirements comprise functional and non-functional aspects. To create a secure product, developers have to devise a security architecture, integrate a suitable set of security functions, and avoid defects that could be exploited to subvert the security architecture. Since such defects can appear almost anywhere, security is also not incremental. Further development can easily break a formerly secure product.
Many speci c security requirements have, therefore, a technical rationale
and only an indirect relationship to threats or security goals|they do not follow
straightforwardly from a threat or goal statement. Such requirements are likely
discovered by developers or security experts rather than by stakeholders, which
has been observed more generally for non-functional requirements [
While security is a cross-cutting concern, the set of security aspects to be
considered is non-uniform across development tasks. This can make it di
cult to use checklists and catalogs like the Common Weakness Enumeration
(CWE, http://cwe.mitre.org/) or the OWASP Application Security Veri
cation Standard (ASVS) [
Finally, security requirements engineering is subject to an epistemic
challenge: beyond a baseline of common problems it is di cult, if not impossible,
to know for certain how threats will react to the presence of a system. Security
work aims to prevent future damages [
Security is a secondary aspect to every part of the development cycle. In addition to the development tasks aiming to ful ll functional and other requirements, development teams have to make deliberate e orts to control the security properties of their product: Requirements: As a basis for design decisions, developers need to understand the operational environment of a system, pertinent threats and risks, the stakeholders' security goals, existing security policies, etc. The analysis of such information leads to assumptions to rely on and to priorities for further security engineering. Some security functions may already be requested at this stage.
Architecture: Developers need to devise a viable security architecture, combining security mechanisms such that they build on each other and are not easily subverted. The security architecture de nes aspects like trust relationships and the attack surface of a system.
Design: Security design concerns aspects like the selection of particular variants of a general type of security function (e.g., a speci c user authentication scheme), the design of security-related user interfaces, and the design of internals like programming interfaces or the location within the architecture where certain functions are to be implemented. Tradeo s can arise between di erent security needs or between security and other requirements, which must be resolved as part of the design process.
Implementation: As otherwise minor defects can easily break a security architecture, implementation work must aim to prevent such defects. They can arise in the implementation or application of security functions, but also in the implementation of any other part of a system if the security architecture explicitly or implicitly relies on it.
Testing and veri cation: To uncover vulnerabilities, speci c testing and
evaluation techniques are needed. Some types of implementation defects can be
found with automated security scanners. Deeper issues may be found by
penetration testing [
Security needs continuous attention throughout development. However, the e ort that can be spent on security as a secondary objective is necessarily limited.
Scrum [
functional requirements belong into the product backlog and their importance is de ned by the product owner. Quality requirements belong into the de nition of \done" and their ful llment is to be demonstrated during sprint reviews. Scrum does not specify how to deal with requirements that do not t into this clear-cut separation or are di cult to demonstrate.
Value-oriented backlog ordering: Scrum requires the product owner to order the items in the product backlog by expected business value. In line with agile principles, more valuable work thus gets precedence over less valuable work. This assumes, however, that the relative value of each backlog item can be determined at all and be expressed on the same scale.
Scrum de nes only essential roles, artifacts, and interactions, so that by
Scrum alone the work environment is underspeci ed. For example, the product
owner is a generic proxy for project stakeholders. Whether the product owner
represents a customer, the product management in a company, or diverse
stakeholders is not de ned by Scrum. Likewise, work practices and routines are only
speci ed to the extent necessary for Scrum as a management framework. Any
number of further agile practices may be used in conjunction with Scrum, and
development teams likely follow routines that either re ne those de ned by Scrum
or run in parallel. For example, Scrum teams may handle defect reports and
feature requests in di erent ways [
To research the emergence of security work practices in an agile development
group we carried out in previous work [
We followed the product group for 13 months with questionnaires, observations, document analysis and interviews, while the developed product underwent a security penetration test followed by a security training workshop for the developers. Our study explored the research question how the organizational routines of the product group changed to account for additional security work practices during and after the penetration test and training. We found that both events had a visible impact on the product group members, who became security aware and were determined to solve the vulnerabilities the penetration test revealed. However, despite group members' evident belief that security work should be part of development practices, they did not manage to change their organizational routines to account for it. Security work remained a reactive and unguided activity executed as unsystematic, invisible work task for individual developers. Developers themselves questioned this outcome and challenged whether security activities would actually be performed in the long run.
We concluded that in order to succeed, approaches to encourage and anchor security work in a development setting must be aligned to the setting's de ning organizational aspects. This requires to not only consider a development framework such as Scrum as a mere constraint for secure software development interventions, but to also address its implications on how work is structured, understood and performed by developers and other people like R&D and product managers, as well as the embedding of development work in a broader organizational context. In particular, we found that as security requirements emerge from activities during product feature development, it might be considered a quality aspect of the software, but, however, cannot be handled as such as it actually requires continuous visibility and prioritization by other stakeholders outside the development team such as the product management. These key observations motivated us to reconsider current proposals for secure software development in agile development environments, and particularly for scrum. 4.3
The way Scrum organizes software development has several implications for
security work, which we observed in practice in our previously mentioned case
study [
and the attention of the development team. Whether visible security concerns will be addressed depends on the ranking of security items in the product backlog and on the acceptance criteria e ective in sprint reviews. Requirements and priorities come from stakeholders. Stakeholders like clients or product management are the ultimate source of requirements and priorities. Security concerns must therefore be their concerns to be addressed in development. Since agile development explores requirements interactively with the stakeholders, they must must be able to assess the ful llment of their requirements, to give feedback, and to express their valuation of requirements. As agile development avoids speculative and preemptive work beyond the scope of the current cycle, only continual feedback can keep concerns and requirements alive.
Security practices need to emerge, not be prescribed. Prescribing security practices to be followed by a team or individual developers, collides with two elements of Scrum. Such prescriptions would circumvent the product owner and the process to interfere directly with the work of the development team, which is self-organizing and uses retrospectives to re ect and improve its practices. Hence, prescribing practices from the top down introduces ambiguity into the self-management duties of the teams and the responsibilities for work tasks and results. 5
Scrum supports three di erent ways to handle security concerns: security as bug xing, security as a quality requirement and security as a set of features. In the following, we explore for each approach its implications of applying it in the context of agile development with Scrum, using our eld experience (cp. 4.2) and other prior work. We show tensions and pitfalls we think require our attention as researchers with an interest in software development. 5.1
Like other defects, vulnerabilities may be discovered outside the immediate development process and reported to the team. Common sources of such reports include operators of the product, penetration tests and security reviews commissioned by vendors or customers, bug bounty programs, and incidents observed in the eld. Such reports often concern speci c instances of vulnerabilities, which may be isolated defects or consequences of deeper problems that likely cause further instances of similar vulnerabilities.
Bug reports arrive asynchronously as defects are being discovered. Bug xing is a common activity in software development. Scrum treats bug reports as backlog items like any other. However, teams and organizations may develop practices to address urgent bugs quickly, without having to wait for the next sprint for proper planning.
Fixing known vulnerabilities is a necessary part of security development, but by itself insu cient to raise the security of a software product. Once an exploitable vulnerability has been discovered, it must be patched to prevent foreseeable or even to stop ongoing attacks. However, if this only forces attackers to look for another instance, security does not really improve. Bug xing likely misses root causes that lead to numerous similar vulnerabilities. Patterns remain invisible when individual defects are treated in isolation and mitigating root causes often requires changes beyond the scope of a bug x. 5.2
Software security has a strong quality aspect [
Scrum's mechanism for quality assurance comprises the de nition of \done" together with sprint reviews. The de nition of \done" speci es a quality gate that increments have to pass before being accepted as completed. A typical de nition of \done" speci es several tasks that must be accomplished in addition to implementation, such as documentation, code review, testing, and xing of any known defects. These tasks are part of the development team's responsibility. Their completion results must be demonstrated or at least declared during the sprint review for the product owner to accept a backlog item. De nitions are adapted to the needs of a team and its product, but not to individual backlog items.
To address security as a quality requirement within Scrum, one would have to include generic yet e ective security veri cation tasks in the de nition of \done." Developers would write secure code to the best of their ability and verify their results by suitable means. Alas, this approach has limitations: Developers cannot cope. There is a vast number of potential security concerns, of which only a subset applies to any particular development task, and this subset varies across tasks. It is unrealistic to expect developers to \just care" about security, to mentally select and apply the right set of secure development guidelines in everything they do. Security requires explicit e orts rather than just implicit attention.
ity attributes, security functions, and security architecture. The functional and architectural aspects are not su ciently covered by a quality-focused approach.
Direct veri cation is hard. Due to the low visibility of security and vulnerabilities, it is di cult to verify results. While a new function can be demonstrated and evaluated in a sprint review meeting, security properties evade quick and easy evaluation. Moreover, stakeholders and product owners are likely unable to provide useful feedback where deep technical expertise may be needed to even follow the discussion.
Testing has limitations. Indirect veri cation by demonstrating test or review results hinges on testing capabilities. Automated security tests, which t into agile practices, work well for some types of vulnerabilities but miss others altogether. Penetration testing and thorough reviews, on the other hand, are costly and hard to repeat at sprint pace. When carried out asynchronously rather than within an iteration, their ndings are likely handled through bug xing.
While the development team can apply security practices and even adopt them autonomously as part of its self-organization, there is limited potential for feedback that could drive the team to do so. It may be tempting to mandate the creation of certain artifacts, e.g., \a threat model must exist for every new feature," but this would create new software bureaucracy, which agile development avoids. 5.3
Substantial amounts of security work are to be de ned and scheduled through
the product backlog and Scrum process just like any other kind of requirements.
This kind of development work includes, for example, the implementation or
strengthening of security functions, the design and implementation of general
solutions to classes of vulnerabilities (see [
For security feature work to be eventually done, it needs to be speci ed in the product backlog as a requirement or design idea, prioritized su ciently as a backlog item to be worked on, re ned until ready for implementation, and moved to a sprint backlog for execution. The implementation is then veri ed like for any other backlog item and the produced increment may be released to users and stakeholders, who can give feedback and raise new or updated requirements.
Perhaps with the exception of implementation itself, each of these steps can fail due to obstacles inherent to security: Developer-de ned requirements: For security requirements or ideas to appear in the product backlog at all, someone has to identify and specify them. This is unproblematic for common security functions with a clear and obvious business value, which may be requested by stakeholders just like any other kind of feature. However, these stakeholders are unlikely to specify less obvious or less common security functions, particularly when the need for these functions has a technical motivation that only developers understand. Scrum does not prevent developers from adding items they deem necessary to the backlog, but also does not speci cally invite them to raise requirements for their product.
Prioritization of security work: Once listed on the product backlog, a
security requirement will get further attention only if the product owner gives
it su cient priority. All backlog items compete with each other for limited
attention and resources; only those with the highest business value have a
chance of being implemented. Security work has several disadvantages here.
First, its value proposition di ers from that of features with positive
business value. Security work limits losses at some later time [
Features alone are insu cient: Veri cation has two levels. Functional veri cation, checking whether a function has been implemented as speci ed, works as it does for any other function. However, correctness does not imply security, so that the e ectiveness of a security feature needs to be veri ed in addition. This entails the challenges of security as a quality requirement discussed above.
In addition to these obstacles for security within the management process of Scrum, obtaining stakeholder feedback on security is di cult as well, because security properties and vulnerabilities are not readily visible. 6
For all we know, Scrum works well as a development management framework. As development progresses and security needs evolve, the dynamic, empirical and change-accepting approach of agile development to requirements engineering should be suitable for security development. However, security as a class of requirements has special properties that do not align with Scrum's strengths. Three di erent ways of identifying and addressing security concerns would be compatible with Scrum as discussed above, but each has limitations. Mere bug xing is widely rejected as an approach to secure software development. Handling security as a quality requirement su ers from a lack of feedback within the Scrum process and neglects the functional and architectural aspects of security. Security work can be scheduled and managed like other backlog items, but does not t into the scheme of stakeholder requirements prioritized by business value. Software development projects may therefore fail to address relevant security concerns contrary to the objective interests of their stakeholders. Our analysis suggests that remedy may be found in the following areas:
ports can reveal unful lled security requirements. To identify and address these requirements, it is necessary to review collections of defects, look for patterns and nd common causes. Such a review di ers in scope and purpose from defect xing itself; it aims to create new product backlog items that, if implemented, reduce the risk of future occurrences of similar vulnerabilities. Activities and tools that let teams re ect on security could be bene cial and would also t into the general framework of agile development.
expected business value, but security work does not t into this approach. This creates a barrier, which systematically disadvantages some aspects of security development work. Security would bene t from better means for developers, product owners, and stakeholders to make the bene ts of security work items visible at all and comparable with the value of other backlog items.
little work on security expertise in Scrum teams, its impact on development results, and suitable ways of dealing with the diversity of security concerns. However, many software companies have established separate security teams as well as training programs for their developers. This calls for empirical work taking a closer look at interaction, collaboration, and impact.
Veri cation and feedback: Finally, veri cation and feedback for security need more attention. Agile development depends on short feedback loops, but quickly generating useful security feedback remains a challenge. Users and other stakeholders cannot provide feedback on security properties. Automated tests are quick and easily repeated, but for many security concerns not reliable enough. Penetration testing can deliver high-quality feedback, but requires too much e ort to repeat frequently. Better feedback mechanisms would help Scrum teams to notice and address security needs.
These four proposals are neither magic bullets nor should they replace any of the security practices that can be applied within agile development. Their aim is, rather, to amend a set of software engineering activities with suitable agile management practices for the security aspects of software development.
Scrum as a management framework for software development establishes a control loop between the product owner and the development team to de ne, prioritize, plan, and review development work. We analyzed how software security ts into this framework and found several factors that can impede security work. Conceived as a quality attribute, security is too complicated and not visible enough to manage it e ectively through the de nition of \done" and sprint reviews. As a set of backlog items, security work needs to be de ned by the development team but also prioritized by the product owner. We expect security development with Scrum to bene t from re ective practices to discover security concerns, better ways to value and prioritize security work, empirical results on internal and external security expertise, and better veri cation and feedback tools. Each of these four items deserves further exploration.