Scrum is one of the earliest and currently still the most used agile methodol-
ogy. Scrum was defined in its current form by Schwaber (1995), and revised by Schwaber and Beedle (2002). The term ‘scrum’ itself originates from “The new product development game” by Takeuchi and Nonaka (1986), as does much of the game-themed terminology used in earliest agile methodologies. The Scrum processes are divided into two iterative stages, presenting the “pre-game” planning and architecture stages on the left, and compressing the “game” and “post-game” stages onto the right, consisting of production
Iterate Product backlog planning Risk assessment Initial security assurance Risk list 4 Security policies and regulation 2 Sprint Training Certificates 1 Production‐time security assurance Sprint backlog planning Risk assessment Security reviews 6 Test reports 7 Security documentation 5 Audit reports 8
Implementation Verification Deployment Operational documentation 9 B Security Architecture 3 B A A
Figure 3.2: Software security engineering processes executed in Scrum framework by Schwaber and Beedle (2002): roles, events, and documenta- tion artifacts
and delivery. The iterative Scrum process, as related to various security assurance artifacts, is presented in Figure 3.2.
Numbered items refer to the security assurance artifacts created or uti- lized during a Scrum iteration, linked to the processes and events. Of these, (1) training and (2) security policies typically exist prior to the start of the development process; organizations may also have a security risk assess- ment baseline to perform initial risk analysis. Training requirements may also emerge and be addressed during implementation.
Security architecture (3) is one of the most common security assurance requirements, essentially a part of the general software architecture with security requirements included. Item (4) is the security risk management documentation: risks are related to the protected business value, and the risk mitigation techniques are to be translated into concrete backlog items.
The prioritization of these items can also be based on the risk assessment. The rationale for the security work is based on the security objectives, which are derived from the initial security assurance documentation.
Items from (5) to (9) are produced or updated during the development process through documentation (5), code and software reviews (6), and var- ious forms of security testing (7). In some cases, also security audits, per- formed by a certification body or other third party, may be required and an audit report is produced (8). Before release to production, instructions for maintenance and operations are produced (9). These are sometimes supple- mented by a plan, or roadmap, for updates. This, in turn, is based on the architecture and the technical documentation. To provide some context, in the Common Criteria item (5) would represent the assurance documentation stack ADV_FSP.x (see Figure 2.5).
Scrum introduces a flexible framework, rather than a strict methodol- ogy, within which the techniques and processes most suitable for the task at hand can be employed. In Scrum, work is completed in short iterations, called sprints. In its basic form, Scrum introduces a simple framework of three roles (scrum master, developer and the product owner), three core arti- facts (product backlog, sprint backlog, product increment), and four events (sprint planning, daily meetings, sprint review, and sprint retrospective). When scaling up the team size or the number of parallel teams, a sprint burndown chart is a practical necessity to track and coordinate progress of the work.
The Scrum workflow captures the essence of agile software development work. In Figure 3.2 security specific work stages and security assurance have been added to a rudimentary Scrum process. The security engineering processes, presented in Section 2, practically introduce security and qual- ity gates into all the stages: product backlog planning involves architecture reviews; risk assessment itself resembles a quality gate. Sprint backlog plan- ning implies design and test case reviews; in the implementation phase, there are reviews for the code, tools, and programming practices and processes; the verification stage introduces further security testing and possible third- party audits. The release, done after a final risk assessment, introduces security documentation creation and consequent reviews, and the possible certification of the code.
Requirements are elicited by customer collaboration (i.e., the product owner), and are communicated in the form of stories. The main differ- ence between a story and a requirement is the level of formality and detail: the user expresses what feature is wanted or which objective needs to be achieved, and these are formalized into requirements and further into devel- opment task in backlog planning events. Items in the product backlog are prioritized together with the product owner, and the actual commitment to implementation is done by the developers in sprint backlog planning. Com-
mon ownership of the items is promoted, meaning that the team commits to implement each task they select for the backlog of the upcoming sprint. Each backlog item is assigned a formal definition of done criterion, verified through a continuous (automated) testing effort.
In practice, Scrum is a set of rules tying the above elements together and governing their use throughout the project, adapting to the changes occurring during the process. The incessant drive for ‘value’ is inherent to not only to Scrum, but nearly all modern software engineering. This ap- proach has the potential downside of causing functionally complete software to be released for production use despite inadequate, or completely missing security engineering and validation.