When people first hear about Agile, most think it is about doing things faster. Although that may be the outcome, this is not what implementing Agile is really about. Under Traditional Project Management, quite often the focus is scope, budget, and time, with quality often being sacrificed.

For Agile Software Development, we try to focus more on creating secure, working software that is made with continuous attention to technical excellence. Even if the team is doing Scrum, the pressure of a shorter development cycle can still lead to sacrificing security or quality for speed. This is not the intention or the spirit of Scrum. If the team is properly implementing Professional Scrum, improved security is one of the benefits.

How should you handle security in Scrum?

Students quite often ask me how to approach non-functional requirements like security and performance issues in Scrum. Within the framework, we have two ways of handling them:

1. Separate Product Backlog Items ( PBI)

2. Definition of Done

Separate Product Backlog Items (PBI)

When the team first starts working on the product, they may not have a full picture of the architecture and features. They may implement some features, test out some architecture, and start planning out some security-related Product Backlog Items. The Development Team can propose the following as Product Product Backlog items and suggest that the Product Owner add it to Product Backlog, ideally putting them near the top of the list:

• Carry out security and penetration testing

• Review Architecture in terms of security

• Test out a new framework or library for handling security

• Do an overall code scan/code review for vulnerabilities

• Try to hack the system

• Fix known security issues

• Apply patches and update the system

• Do research, proof of concept, or a Spike to uncover uncertainties regarding security implementation

Ideally, if the Development Team has the necessary skills and competency, they can implement security features themselves. Otherwise, the Development Team can get help from subject matter experts, security specialists, other teams, the Scrum Master, or other leaders.

We want the above items to be separate Product Backlog Items (PBI) for better transparency so that the Product Owner and stakeholders can have a better understanding of the current state of the Product. We want the issues to be transparent to everyone involved so that we can plan out accordingly. Additionally, these issues can take considerable amounts of development time, so we want the effort spent on them to be transparent, as well.  

But… security has no value, right?

Quite often, the Product Owner has no understanding of security-related issues, and it is up the Scrum Master and Development Team to highlight the risk and potential negative value associated if the issues are not addressed.

For example, if we do not carry out penetration testing or we do not fix known critical issues, the system may get hacked, press may cover the data breach in the news, and we may be fined by local and international governments (e.g., 4% of global turnover levied by the EU if we violate GDPR). Company directors could even face jail time if we do not do our best to protect customer data according to all relevant legal requirements.

It is up to the Scrum Master and the Development Team to highlight the technical risks and negative business value and then suggest the Product Owner re-order the Product Backlog to make sure we address those issues.

Definition of Done

If the Product Owner still refuses to order the Product Backlog to address security issues, then it is up to the Development Team to have the courage to include security as part of their Definition of Done. As the Development Team estimates the efforts, it is up to them to uphold Scrum and the Definition of Done. This is what we mean by doing Professional Scrum. We do not want to trade quality for speed!

It is up to the Scrum Master to coach the Development Team on the importance of security as part of software quality and to highlight that delivering a working Increment with security is the purpose and very spirit of Scrum. It is not up to the Product Owner to decide whether to release the software with a security flaw or not. The Development Team is responsible for delivering a done Increment, and security should be part of the Definition of Done. Yes, it will take more time, but more time and effort is nothing compared to the security risk.

Organizational Definition of Done

From Scrum Guide

If "Done" for an increment is not a convention of the development organization, the Development Team of the Scrum Team must define a definition of “Done” appropriate for the product. If there are multiple Scrum Teams working on the system or product release, the Development Teams on all the Scrum Teams must mutually define the definition of “Done.”

Usually, the Development Team defines the Definition of Done, but it may not make sense for different Scrum Teams under the same organization to have a different Definition of Done. Ideally, the Software Organization (this can be the whole IT department, customer-facing teams, or portfolio/application team) should have a common, organizational-level Definition of

Done. For example, if the Product involves customer data, then we need to do penetration testing and handle all high and medium criticality issues.

How to get started

So, how to start if security is not handled seriously? First, have a conversation about the sensitivity of data. What happens if hackers get access to it? Then, discuss the Definition of Done during Sprint Retrospective or at any time. Afterward, talk to the Product Owner to create some PBIs for security testing. Once this has been implemented, put that as your Definition of Done and continue to handle security if you have new features or new architecture components.

But what if we do not have security knowledge?

As mentioned above, the Development Team can get help from subject matter experts, security specialists, other teams, the Scrum Master, or other leaders. You can also consider asking DevOps or security consultants or vendors for outside help.

Scrum Masters and other leaders can also arrange security training for the Development Team. I recommend sharing OWASP Top 10 Security Risks with the team.

Some tools, like WireShark, can help the team to do security checks to study the channel and check for man-in-the-middle attacks. Also, consider using static code analysis tools or web application vulnerability tools .If you are using the cloud as your infrastructure, you can schedule a Penetration Testing with AWS or consider using Netflix Security Monkey as part of the Chaos Monkey Suite. There are many tools out there, so speak with your security team or consult with some security experts if you are not sure which ones are right for your organization.

Conclusion

If the team is doing Professional Scrum, they should handle security issues as separate Product Backlog Items or have a strong Definition of Done that includes security. It is up to the Development Team to deliver a high-quality High Increment, and it’s the Scrum Master’s responsibility to coach the Scrum Team on the importance of quality in Software Development.

Doing both of these can require a lot of courage. To get started, the Development Team can discuss security as part of Definition of Done, talk to the Product Owner, do some research, and get some external help.