Hello, this is Antti Vähä-Sipilä from Nokia.  I thought I’d use my first entry here as a guest blogger to talk about marrying software security and Scrum, an area which has recently kept me busy.

I’ve seen many people claim that agile methods and security are mutually exclusive, as ‘agile’ is interpreted as ‘laissez-faire’.  I don’t buy this as Scrum is actually quite strict.  There’s a better argument, though: As every Scrum sprint is different, mandating a specific security engineering activity in every sprint is counterproductive to agility.  This is probably true.

The key observation was therefore to distinguish between actual engineering activities, such as those listed in the SAFECode Fundamental Practices for Secure Software Development paper, and security risk management, which is all about meeting an acceptable level of business risk.  Scrum is a management model, and therefore, we really ought to be concerned about how risk management fits Scrum.

And after all, in Scrum, an enormous amount of trust is placed on the team. They should know best how to do the actual engineering, and to make sure they do, providing all sorts of software security training and support is necessary.

So, a scheme is required where the traditional security business risk management practices can be built into the management practices in Scrum. First, you need to identify the threats; second, you need to decide on the controls (which may be engineering practices as well, not just design decisions or features). What you’ll have left is residual risk - the part of the risks that haven’t been fully mitigated or terminated - and that has to be acceptable to the business owner.

As it happens, Scrum readily gives a lot of structure where these risk management practices can be implemented. The most complex one of these was the threat analysis part, which, when done properly, is a bit too large of an effort to squeeze into the sprint planning session.  At the moment, the best proposal I’ve seen is that sprint planning only identifies the largest risks - typically those having most impact in terms of engineering - and the detailed threat analysis would be done by the team as they see fit, most likely early in the sprint.

Deciding on the controls would be done by the end of the sprint, depending on how the team organises their work. The team has three options for each identified threat: either they add new sprint backlog items and address them during the current sprint, or they postpone the work by adding product backlog items, or they make a first-level risk acceptance decision by choosing to do nothing.

The third phase, approving the residual risk, fits the sprint review. The team makes the lowest level business decision by determining whether they feel they’re ‘done’ with the sprint backlog given all the threats they’ve found, and the controls they’ve implemented. If they agree, the residual risk can then be approved by the product owner, who is also the business owner. If a product is comprised of the outputs of several Scrum teams, residual risk acceptance for particularly hard decisions can still percolate higher up if necessary.

This model has some very nice properties: if the team feels that they cannot accept a risk but they still don’t have enough time to mitigate it during the current sprint, producing a product backlog item will automatically escalate this to the product owner, and require the product owner to prioritise it for later sprints. In addition, flagging a sprint backlog item ‘not done’ in the sprint review gives the Scrum team power to voice their concerns over open security risks.

For this to work, the Scrum team does need to be acutely aware of security engineering and software security issues, and especially the threat analysis part needs to be prudently done. Security specialists should be on call. Luckily, an ideal Scrum team is also an ideal mentoring environment for security, but that will probably be a topic of another post later.

Finally catching up after the RSA Conference.  It was a fantastic week for SAFECode, which we kicked off with a board of directors meeting.  The board discussed some exciting projects we’ve planned for the next few months on issues such as software integrity in the global supply chain, measurability and software assurance R&D, and I am looking forward to sharing more details on these as they progress.

Another highlight of the conference was our panel discussion around our paper on Fundamental Practices for Secure Development.  We had a expert group of speakers representing some of our member companies: Steve Lipner, Microsoft; Reeny Sondhi, EMC; Wesley Higaki, Symantec; Gunter Bitz, SAP; and Paul Kurtz, our executive director who moderated the discussion.  And while the panelists were great, it was really the audience feedback that made the experience so rewarding.

After the discussion, members of the audience thanked us for the paper and presentation and let us know that they had started implementing our recommendations in their own efforts. This feedback from actual practitioners meant a lot because it demonstrates that we are having the impact we hope to achieve with this work.   Our members are sharing the lessons they have learned from their own secure development efforts so that we can help others in the industry start or refine their own internal software assurance programs.  Hearing first hand that others are finding practical value from these efforts further strengthens our commitment to sharing our experiences and continuing to refine and update our development practices paper.

In fact, in an effort to keep the paper as relevant and useful as possible, we are currently accepting feedback on its recommendations via an online comment process.  If you have worked to implement some of our methods or have ideas of your own, we’d love to hear from you.