Reconciling Agility with Security: The Agile Manifesto and OWASP to the Rescue!

The Open Web Application Security Project (OWASP) and its Top 10 have long been associated with application, website, and API development security. If you’re unfamiliar with it, read our post on the topic before visiting the OWASP website to learn about the latest updates, particularly the Top 10 of 2021.

Our Top 10 in 2-2 post helps us visualize the progression of vulnerabilities and recognize that although some of them are now addressed by design in the frameworks and technologies we use, there are always new security challenges for the applications we develop. So, it’s essential to stay up-to-date on this topic.

But, even before OWASP, when we think of development and security, we think of DevSecOps (see our post on how to incorporate security in your DevOps projects), which is currently all the rage. Beyond the buzzwords and magic tools, we believe it’s worthwhile looking at what OWASP suggests as the most effective way to incorporate security into the development cycle of an application in an Agile setting.

Agile Development and Security

At first, these two terms may seem difficult to understand together. But let’s take a step back and review the basics.

The Agile manifesto taught us, among other things, that we had to interact intelligently with our application’s clients and deliver regularly. Despite a mandate to pay “continuous attention to technical excellence and good design,” the Agile movement was swiftly left behind and the term quickly overused, relegating quality to the background.

The Craft, the return of eXtreme Programming (XP) (see our post on XP), and Agile Testing/Shift-Left Testing practices put quality back at the center of our development.

The DevOps movement could break through the “wall of confusion,” and we would be able to deploy apps rapidly and reliably (with the help of the cloud). This transition, which is far from complete, is taking time in companies, including Microsoft.

Consequently, it should come as no surprise that “Shift-Left Security,” or the development of skills in the security matters exemplified by the Security Champion and governance, is the main driving force behind DevSecOps.

This means considering it at every step of the iterative/DevOps cycle:

The OWASP SAMM Project

The Software Assurance Maturity Model (SAMM) project is a set of tools and suggestions for improving an organization’s software security management.

It is based on a model and an assessment that allows us to self-assess our maturity level and develop an improvement plan.

This comprehensive (sometimes complicated) model covers the entire application life cycle and will need adapting to your technical environments.

I’ll let you read up on it yourself on the SAMM model review website and do your own self-assessment.

SAMM Agile Guidance

SAMM Agile Guidance is undoubtedly one of the OWASP elements that should be studied first in order to understand how to include security in our development process. There is no mention of the term DevSecOps. We said earlier how difficult it can be initially to reconcile security and agility. The solution the guidance gives us to this issue also has its roots in Agile principles:

• Security is an integral aspect of software quality
• A security assessment model should be viewed as a means for continuous improvement

Quality and continuous improvement are at the heart of Agile development!

Practical Ways to Put This into Action

Take Our Share of Responsibility

Security is the entire team’s responsibility, and that responsibility must be shared. Our success as developers depends on our sound understanding of these subjects. An excellent place to start is by studying the OWASP Cheat Sheet. Ideally, you’ll also have a Security Champion.

Share Our Understanding of the Issues

When we (re)implemented quality assurance (QA) in agile development teams by integrating these issues as early as possible (and not during a test sprint), one of the tools we used was “the 3 Amigos,” a relatively simple tool included with Behavior-Driven Development (BDD). Three people (the product owner (PO), developer, and tester) can use this simple but powerful workshop to establish a user story with concrete examples.

Because it brings together the PO, a developer, and someone playing the role of a hacker, it’s particularly useful in the context of security. The Security Requirements and Abuses Story will be defined during this session in order to discuss and outline the feature’s security requirements. Then we can automate these tests while reserving time for manual security testing, such as exploratory QA testing.

Define a Global Security Strategy

Finally, depending on your maturity and the criticality of the application you’re developing, this will undoubtedly involve structuring your thinking around the overall security of the application with “Threat Modeling,” for example, using the Microsoft tool.

Agility and Security: Key Takeaways

To sum up, the goal of this post was to provide you with information from two sources we consider references: the Agile Manifesto and OWASP, to help you strike a balance between agility and security during the application development process. By adapting our agile mindset to the implementation of software security and learning through experimentation and the documentation mentioned above, we are confident that you will consistently improve the quality of your work.

Note: The 3 Amigos workshop is quick and straightforward. While it was created to facilitate communication about app behavior, it can just as readily be applied to other aspects vital to any app’s success, such as ops (deployment, monitoring, performance), security, UX/UI, localization, accessibility, etc.

However, there are three potential pitfalls to look out for:

• Ideally, each topic (like security, for example) should have its own session. There is always a connection between the subjects, but our focus here is on exploring one in-depth and discussing the problems and insights along the way. It will then be “easier” to promote the overall vision.
• For a standard story, each workshop should be brief. Fifteen minutes would be enough. This requires the session to be planned by an expert in the workshop topic (a PO, a QA, a developer, a Security Champion, etc.) and that the three individuals present are appropriate for the task at hand.
• Don’t waste time planning these workshops for stories that won’t be developed for a long time. Instead, be just in time by focusing on the stories for the upcoming sprint and prioritize those that are worthwhile.

Would you like to learn more about cloud security? Here are the rest of the posts in this series:

• Cybersecurity: A Strategic Issue for Companies
• Cybersecurity concerns as Information Systems Evolve
• Delegating User and Device Management in Azure AD and Intune
• Cybersecurity in Azure Sphere: Who, What, When, and How?
• Why Is Cybersecurity Training So Important?
• Smart Business / MLSecOps : How security should drive Machine Learning project?
• Github Security

Our experts are also available to discuss your security issues: contact us!