Software Security in Scrum
Applying security practices as part of Scrum framework
Since as an agile development framework Scrum is all about inspection and fast adaptation, utilizing well-known software security practices should not be a problem. So, how do we map security practices to Scrum main events and other agile development activities it usually contains? This post assumes you are familiar to both Scrum and Software Security activities and roles to some extent.
Introduction
Both agile development and software security, as formal processes, started to be a thing in early 2000s. Scrum, being an agile framework, has strict formalities, such as event types, roles and outputs. Software security, too, evolved to contain a set of best practices most of the practitioners agree upon, such as threat modeling, security requirements, checking security risks of third party components, static code analysis, dynamic application testing, etc.
Originally most secure development life cycle processes, like Microsoft’s SDL, contain security activities mapped to seemingly Waterfall activities of producing software. For example, security requirements and abuse cases should be produced at the beginning of the development and be part of the Software Requirement Specification (SRS). However, these security best practices are just mostly back-to-back activities and can be squeezed into any cycle that can be mapped to the following phases;
Requirements->Design->Implementation->Verification->Release
And without any surprise Scrum activities can also happily be mapped to this phases. Yes, things will be fast and there won’t be well and deep thought security requirements, however, in parallel the functional requirements will also be small compared to non-agile development frameworks.
Short Background
You can skip this short part if you are already familiar with most of the software security practices and have a working understanding of Scrum activities. We won’t be detailing them as stated previously, however, it still make sense to go through will only list some of the Let’s start with Scrum.
Scrum Activities and Roles
There are four main Scrum activities; Sprint Planning, Daily Stand-ups, Sprint Review and Sprint Retrospective. While not part of the main activities, development teams utilize other agile development framework events, such as Bug Triage, Backlog Refinement, Cross-functional Collaboration (discovery meetings, brainstorming, training, etc.) and a few more.
There are also three roles Scrum defines; Product Owner, Scrum Master and Developers.
Software Security Practices and Roles
Defined software security processes like Microsoft SDL, similar to Scrum, also have a set of well-defined practices;
- Increasing security know-how
- Identifying security requirements and abuse cases
- Using secure coding best practices
- Identifying security risks of third-party libraries
- Static/dynamic application security testing (SAST/DAST)
- Employing manual penetration testing
Moreover, there are two basic roles; Security Architect and Engineer. Basically, the first one is more of a role dealing with secure design/architecture and security requirements. The role is also playing an important role in keeping the management motivated about security. The latter is a role who manages or applies security testings and triaging the resulting findings.
Got Resources?
Let’s start with roles. If the team has security experts in the team, excellent. This can even make the whole process easy and less painful. But the critical question is as follows;
Can a (Scrum) team produce secure software with no security experts in it?
Scrum teams are required to be self-conscious, self-managing and cross-functional. I know, this is mouthful and it is not realistic to expect for a developer (programmer or a QA based) be a security expert. It takes time and experience. So, if the management doesn’t provide independent security experts, then should we really expect the team to produce secure deliverable?
Why not… With the good amount of mentality and motivation, it may take a while but still is possible.
While it evolved to have a set of best practices, security is a bit of a Black Art. Anyone worked in that field will realize that it requires a different mentality than development. Otherwise, we won’t be having this many security defects out of developers. In short, developers are builders and, generally speaking, security engineers are breakers. Totally different set of thinking.
Nevertheless, as independent teams increase their knowledge on anything towards finishing the job at hand, they should also get good at security information; perhaps on cryptography, input/output validation, certain attack vectors, authorization and authentication, etc. especially what they are working on has anything to do with these, such as implementing a OAuth authentication, SSO service provider, storing/transmitting sensitive data, accepting/processing user inputs, dealing with critical infrastructures, etc.
However, Scrum teams generally have one or more people with Quality Assurance focuses; the testing folks. So, if a security expertise is a rare or even non-existing resource then we can get security engineers out of these people. You have hacker developers? That’s excellent, too. With a good amount of motivation, like bug bounties, time and gentle push, they can be second to none.
In parallel, if there are no expertise around, a Product Owner or a senior Scrum Developer is a meaningful choice for a security architect role. Managing security in a single Scrum team is different than managing it across five Scrum teams. As resources permit, security architecture and security engineering may be two different roles. The first can attend to Discovery and even perhaps Sprint Plannings, the latter can attend to Bug Triage, Daily Scrums. Both can be part of Sprint Reviews and Retrospective when called in.
A Map of Security Activities on Scrum
Assuming that we have the necessary motivation and resources, how can we proceed following security best practices without changing the Scrum itself.
Yes, there are methods proposed which manipulates Scrum methodology a little to incorporate the security practices. However, let’s stick to what we have for now.
It seems as long as we want security to be built-in more or less all Scrum and agile development activities provide opportunities to some extent.
Discovery
While Scrum doesn’t have a separate discovery phase, sometimes it might be helpful to do separate discovery sessions for bigger features that may include customer feedbacks, brainstorming new ideas and prototyping. This is like a phase prior to Sprint Planning. At this phase while creating functional requirements, it might be a good idea to contemplate on abuse cases and then security requirements.
It would be fantastic to have a Security Architect or a seasoned security savvy Product Owner during these meetings because creating security requirements require different level of skills.
If no luck, then tools like Generative AI can also be used to produce security requirements out of written functional requirements. An it would make more sense to provide all previously Done and related requirements as well as the design architectures to be part of the prompt to get the most out of it. Something to work on…
Sprint Planning
Similar to the phase above, since it allows Product Backlog refinement, item prioritization, estimations, Definition of Done/Ready updates, the Sprint Planning is a great activity security requirements can pop up, discussed and added to the stories.
Moreover, as the story points are given to the tasks being created and pulled, the security actions, such as testing or code reviews will play important role in planning.
To be realistic, the focus of the teams will be on the feature to be built and storification. That’s for sure. So, it’s vital someone with the security mindset to be there, internal or external… For example, the Product Owner can make sure whether the security requirements are there or not.
Bug Triage
During Sprint Planning and Refinement meetings, just like the other BackLog items the security testing findings, too, will be triaged and put again into the Product Backlog.
However, this may not be enough. Security findings might be discovered any time, so, weekly or even Just-In-Time Bug Triage meetings should be available. Moreover, obviously some of those security findings must be handled immediately. So, the current Sprint Backlog might also got hit. The security KPIs play an important role in this decision that all Scrum teams should comply with.
The backlog items with security implications should be marked separately and given security severity levels defined and agreed upon previously by the Scrum team. That marks can be labels and may include any attributes you think would be important later on; such as securityrelated, inhouse/outsource, type of the test.
When these items are pulled into the following Sprint, sub-tasks should also be marked if they exist. These marks facilitate verification and play an important role on building a product specific security knowledge.
It is worth to note that individual and isolated bug-fixing may not necessarily push the team to find out the root cause of the actual defect, so, there might be an opportunity missed here where the team can also look for the same pattern all over the code base and apply the remedy if they find any. But Scrum provides other activities that this can be handled. Read on…
Daily Stand-ups
Albeit time-boxed, daily meetings are great for developers to ask security related testing or coding questions and get feedback from the team. If available, a security engineer would be an excellent asset here in case the team needs.
Sometimes even triaged security findings don’t really give too much away to locate the root causes, the best way to fix problems. So, impediments just like these can be revealed during daily scrums and act upon.
Sprint Review
This activity is for demonstrating the work done. It is perfect for getting feedback from any stakeholders like Users, Product Owners and such. Since it is meaningful to present implemented requirements here, why not shouldn’t it be the same with the security requirements…
Perhaps it’s an overkill to present the demonstration of a fixed security related defect at this meeting, nevertheless, I don’t think it’s completely unrelated. As long as it is done transparently, without pointing fingers and draws attention then it may have a positive effect over both the Product Owner and all the developers, especially if there are multiple Scrum teams with a single Product Backlog and delivering the same product.
Still, it’s always possible to do a PoC about critical security findings during the following activity.
Sprint Retrospective
Well, the team discusses the successes and failures of the previous Sprint, so talking security, like vulnerabilities and weaknesses, is kind of obvious.
Any fixed security defects can be part of the reflection part of this activity. The team will openly discuss the defect and try to find the root cause. This will help to contemplate on the possible process changes or other Product Backlog items that should be applied in order not to get any more of these in the future;
- planning specific security trainings,
- moving to a secure framework,
- creating a specific library for developers to develop weakness-free usages,
- tweaking testing tools,
- writing automated test cases
All these facilitate the continuous improvement.
Cross-functional Collaboration
Security requirements are produced at Sprint Planning meetings and at Daily Scrums. However, this is not enough.
Secure thinking should be part of exploration where risks can be found out close to the origin, prototyping which can trigger the secure design and cross-functional collaboration which is a great period of time for risk assessment with the stakeholders.
While not part of the Scrum framework, cross-functional collaboration activities also include design workshops, brainstorming sessions and other regular communications. It can be used for increasing security know-how among the developers and keep Product Owners and other stake-holders security motivated.
Conclusion
Scrum is an Agile project management methodology, whereas, Software Security is all best practices to make security a focused area on all parts of the software development life-cycle. The biggest suspicion applying these best practices to the framework is about the time-boxed working principles, in other words the agility of Scrum. Some portions of security is a black art, yes, but some part of the development is a craftsmanship and equally challenging. As Waterfall methodology went through it, the secure software development lifecycle should also be able to squeezed into shorter amount of periodic duration.
