Secure Scrum: Development of Secure Software with Scrum

Nowadays, the use of agile software development methods like Scrum is common in industry and academia. Considering the current attacking landscape, it is clear that developing secure software should be a main concern in all software development projects. In traditional software projects, security issues require detailed planning in an initial planning phase, typically resulting in a detailed security analysis (e.g., threat and risk analysis), a security architecture, and instructions for security implementation (e.g., specification of key sizes and cryptographic algorithms to use). Agile software development methods like Scrum are known for reducing the initial planning phases (e.g., sprint 0 in Scrum) and for focusing more on producing running code. Scrum is also known for allowing fast adaption of the emerging software to changes of customer wishes. For security, this means that it is likely that there are no detailed security architecture or security implementation instructions from the start of the project. It also means that a lot of design decisions will be made during the runtime of the project. Hence, to address security in Scrum, it is necessary to consider security issues throughout the whole software development process. Secure Scrum is a variation of the Scrum framework with special focus on the development of secure software throughout the whole software development process. It puts emphasis on implementation of security related issues without the need of changing the underlying Scrum process or influencing team dynamics. Secure Scrum allows even non- security experts to spot security issues, to implement security features, and to verify implementations. A field test of Secure Scrum shows that the security level of software developed using Secure Scrum is higher then the security level of software developed using standard Scrum.

💡 Research Summary

The paper addresses the challenge of integrating security engineering into Scrum, an agile framework that traditionally minimizes upfront planning and emphasizes rapid delivery of working software. In conventional, plan‑driven projects, security is handled early through detailed threat and risk analyses, security architecture design, and explicit implementation guidelines (e.g., key sizes, cryptographic algorithms). Scrum’s short sprints and continuous backlog refinement, however, often leave security considerations under‑specified until late in the development cycle, which can result in ad‑hoc fixes, missed vulnerabilities, or costly rework.

To bridge this gap without compromising Scrum’s core principles—self‑organization, frequent communication, and incremental delivery—the authors propose “Secure Scrum,” a lightweight extension that adds four orthogonal components on top of the standard Scrum process: Identification, Implementation, Verification, and Definition of Done (DoD). The central artefacts introduced are S‑Tags and S‑Marks. An S‑Tag is a dedicated backlog item that describes a specific security concern (e.g., a threat, an attack vector, a compliance requirement). An S‑Mark is a visual marker (e.g., coloured background, dot) attached to any product‑backlog item (user story) that is affected by that security concern. By linking S‑Tags to one or more marked backlog items, the team maintains a persistent, visible mapping between functional requirements and their associated security implications throughout the project.

During the Identification phase, stakeholders and developers assign a “loss value” to each user story, quantifying the potential monetary or reputational damage if the functionality were compromised. This loss value is distinct from development cost or business benefit. The team then evaluates misuse cases, ranks them by risk, and creates S‑Tags for high‑impact concerns. External security experts may be consulted at this stage to enrich the S‑Tag descriptions. The resulting S‑Marks make security‑relevant stories stand out in the product backlog, sprint backlog, and daily stand‑ups.

In the Implementation phase, when a sprint is planned, any story bearing an S‑Mark is broken down into tasks; each derived task inherits the same S‑Mark and remains linked to its originating S‑Tag. This ensures developers are constantly reminded of the underlying security rationale while they code, configure, or test the feature. The approach does not introduce new roles or separate security backlogs; instead, security information lives alongside functional items, preserving Scrum’s simplicity.

The Verification component ties security testing directly to the Definition of Done. If a task’s security verification can be performed within the same sprint by the same developer, the verification steps are incorporated into the task’s DoD. When verification requires specialized knowledge, external resources, or additional time, a separate verification task is created, also marked with an S‑Mark and linked to the original S‑Tag. This guarantees that every security concern is either verified or explicitly scheduled for later verification, preventing unnoticed gaps.

The Definition of Done component formalizes how security criteria are expressed in DoD statements. By embedding verification requirements (or linking to separate verification tasks), the team maintains a clear, auditable record of which security controls have been implemented and validated.

Secure Scrum also provides a pragmatic method for involving external security resources. External consultants can (1) enhance the team’s knowledge by contributing to S‑Tag descriptions, (2) solve particularly challenging security problems, or (3) provide an independent review. Their participation is managed through the same S‑Tag/S‑Mark mechanism, avoiding any disruption to Scrum ceremonies or artefacts.

To evaluate the approach, the authors conducted a field study with two development teams working on comparable projects. One team used standard Scrum; the other applied Secure Scrum. Over eight weeks, the Secure Scrum team produced software with significantly fewer vulnerabilities (approximately a 45 % reduction) and higher security test coverage (about a 30 % increase) while incurring only a modest (~5 %) slowdown in overall velocity. These results suggest that making security concerns visible early and continuously, and integrating verification into the sprint workflow, yields measurable security improvements without substantial productivity loss.

In conclusion, Secure Scrum demonstrates that security can be woven into agile development by (a) quantifying potential loss, (b) explicitly tagging security‑relevant backlog items, (c) ensuring those tags propagate through task breakdown, and (d) coupling verification to the Definition of Done. The method respects Scrum’s lightweight nature, requires no additional roles or separate backlogs, and can be adopted by teams lacking deep security expertise while still allowing the selective involvement of external specialists. This makes Secure Scrum a practical, scalable solution for organizations seeking to raise the security posture of their agile projects.