Agile, and Scrum in particular, continue to be popular methodologies for managing software development. But in their emphasis on generating working code quickly, do Agile and Scrum lead to security issues getting left by the wayside? A pair of computer science researchers in Germany think so and have developed a new version of Scrum that they argue better supports the development of secure software.
Why Secure Scrum?
“When investigating why current web applications often have a low security level, we noticed that, among other things, one reason for security vulnerabilities lies in the agility of web application software development processes,” Hans-Joachim Hof, a professor in the Munich IT Security Research Group at the Munich University of Applied Sciences, told me via email. “We decided to have a closer look into this issue and identified Scrum as a common agile software development process that needs a kind of framework for security.”
The result is a paper that Hof co-authored with Christoph Pohl, a PhD student studying under him, titled Secure Scrum: Development of Secure Software with Scrum. In the paper, which they will be presenting later this month at SECURWARE in Venice, Hof and Pohl argue that since Scrum is about minimizing up-front planning, quickly generating working code, and making design decisions along the way, there’s little time for detailed security analysis and planning. “In my opinion, in many Scrum projects, security issues became moving targets and that is why it is so difficult to get security right,” Hof told me. “Security may be one of the most difficult non-functional requirements to achieve with Scrum.”
How it works
In order to better address security issues throughout the development cycle, Hof and Pohl have developed a variation of Scrum they call Secure Scrum. In Secure Scrum, security concerns are identified during the initial planning of the product backlog (as well as during later refinements and sprint planning). User stories which are related to security concerns are clearly marked in the backlog as such; when those stories are included in a sprint, so are the related security concerns. User stories get ranked by the potential monetary loss if the security concern were to be realized.
Secure Scrum allows for third party security experts to be included in numerous ways, for example through training the Scrum team, identifiying security concerns, and even providing black box solutions to security issues during sprints.
Hof and Pohl argue that, unlike other approaches to Scrum which attempt to better integrate security concerns, such as S-Scrum or developing a separate Security Backlog, Secure Scrum minimizes the impact on the normal Scrum process while encouraging developers to consider security issues throughout the development process.
An empirical study
To test their theory that Secure Scrum will lead to more secure software than normal Scrum, Hof and Pohl recruited 16 third year computer science students, divided them into three groups, and gave each one a task of developing a prototype for a social network. Each group was given six functional requirements and one week to develop their prototype. One group could approach development using any method other than Scrum, while another group was to use traditional Scrum, and the third Secure Scrum.
The researchers found that the Secure Scrum group quickly got the hang of it and identified (and implemented) more security requirements than either of the other groups, and their code suffered from significantly fewer vulnerabilities. The main drawback of Secure Scrum was the extra overhead in considering security concerns, which manifested itself in fewer lines of code being written by the Secure Scrum group, compared to the others.
As the authors concluded in the paper, ““This finding shows that Secure Scrum helps to put focus on software security.” In particular, they were impressed by the ease with which the developers could get the hang of Secure Scrum. “I was quite surprised that even beginning programmers (bachelor students in their last year) were able to avoid the most critical security flaws,” Hof wrote to me.
Scrum’s inventor weighs in
While this all sounds quite promising, I decided to check in with Jeff Sutherland, one of the creators of Scrum and the CEO of Scrum Inc., to get his opinion on whether regular Scrum and secure software are mutually exclusive. He told me via email that there’s no reason highly secure software can’t be developed using Scrum without any modifications, citing an example of a highly secure healthcare application that was developed using Scrum after an initial six-week long process of defining security requirements that included security experts from MIT. “I think the paper is a good effort to define just enough security,” Sutherland told me. “However, it will never replace a team of dedicated MIT hackers who can crack anything as a security team.”
Hof and Pohl plan to continue their research into the effectiveness of Secure Scrum by field-testing it with a real software-development company. If your company is interested in participating, reach out to Hof via email.