One of the concerns that takes the back burner while setting up the agile SCRUM teams is application security. One other area that gets similar behavior like security is performance which shall be addressed in later articles. However, performance gets addressed quickly as it is key quality characteristic and gets noticed by end users very quickly.
In the traditional waterfall based development model, security gets fair attention as the non functional requirements related with security gets captured in the initial stages and the team gets composed of at least one security officer/specialist/architect to take care of security requirements. However, having a security specialist/officer in each SCRUM team is not feasible and cost effective owing to exclusivity of the skills and expertise related with application security. Thus, there is a need of some framework or model based on which security requirements related with Sprint deliverable of different SCRUM teams can be addressed on sustainable manner.
How does the traditional scrum team composition look like?
Let’s try and understand the traditional agile SCRUM team composition. Following is how it looks like:
- Product Owner/Business Analyst: He/she is creating for managing the product backlog and work with the team describing the user stories as part of Sprint planning.
- Scrum Master: He/she is responsible for managing the SCRUM team
- Developers: They are responsible for developing the source code
- Testers: They are responsible for testing the code
Then, there is a common infrastructure team which owns the responsibility of managing servers, code repositories, builds and deployments.
Proposed SCRUM team composition to take care of application security?
In the above team composition, what is missing is security officer, security testing professionals and security representatives. To take advantage of application security as part of Sprint deliverable, following is the proposed model/framework:
Agile SCRUM Team Composition and Application Security
- Traditional team composition as like that mentioned above.
- A centralized security team visiting of two or more security officers/specialists who got a good hold and experience with application security in terms of conducting threat modeling exercise on requirements, laying down security architecture, advising and taking part in security code review, conducting security awareness training for different SCRUM teams, assisting testers on security testing, advising adoption of security tools and frameworks etc. In addition, this team also consists of a set of security testing professionals which could get involved with vulnerability/penetration testing from time to time.
- At least one security point of contact in each SCRUM team (called security representative here onwards) who is aware of concepts related with threat modeling, security vulnerabilities, security code review checklist etc.
[adsenseyu1]
Process to Address Application Security Issues?
The above represents the SCRUM team composition to address application security in ongoing sprints. Let’s see what can be the process to address these application security issues on ongoing basis:
- For stories of points less than 3 or so, the security representative would try and do the threat modeling and put the security design in place. He could, however, run his threat modeling through the security officer. He will also do the security code review (manual) and ensure that the code is sanitized from security perspective.
- For complex story (points 5), the security representative may involve the security officer from centralized security team in the threat modeling phase and also security code review if required.
- Doing security testing for each sprint may be cumbersome. Thus, the security testing professionals from centralized security team could run the security testing (vulnerability/penetration) during the release time (maybe, before UAT phase or so).
Check out my latest book titled as First Principles Thinking: Building winning products using first principles thinking.
- Agentic Reasoning Design Patterns in AI: Examples - October 18, 2024
- LLMs for Adaptive Learning & Personalized Education - October 8, 2024
- Sparse Mixture of Experts (MoE) Models: Examples - October 6, 2024
I found it very helpful. However the differences are not too understandable for me