Challenges and Opportunities: Security in Agile Software Development

by | 03.12.2019 | Project Management

Information security still gets too little attention in software development. In contrast, in the areas of infrastructure and management, security is well-established. It seems that especially in agile projects very little attention is given to security. There are a few reasons for this:

  • Security requirements are too vague
  • Security doesn’t offer a direct business value
  • Security concerns aren’t anchored in the development process, but are held off until later phases

Consequently, security requirements are addressed too late and are dealt with separately from functional requirements. This leads to missed opportunities and additional problems: Architecture has to be changed retroactively and synergies with business requirements aren’t maximized.

How to integrate security in agile projects – the first, effective step

The diagram below shows a Scrum-based process with the addition of security activities. Alongside quality requirements, the backlog contains security requirements that are used for sprint planning and which are then implemented and tested in the sprint. The definition of done incorporates important quality considerations, such as reviewing security architecture and documenting and addressing identified threats.

There are additional security activities that belong to any secure agile development project, such as adherence to secure design patterns, the use of code analyze tools, penetration tests and secure deployment. In this article, however, I want to focus on threat modelling and security requirements, using a simple example in order to look at the issue in more detail.

microTOOL Blog: Secure agile process

Simple Example: An Online Shop for City Tours

Using a simple example, I’d now like to demonstrate how you can utilize basic security activities like threat modelling to formulate concrete, testable security requirements.

The example involves an online shop where internet users can learn about and book city tours. Customers can document their experiences in a guestbook for other users. In order to simplify the example, payment occurs with the use of invoices and is not part of the software system to be developed.

The following diagram shows the primary use cases:

microTOOL Blog: Use Cases

In the first step we’ll need to consider which data and processes need to be protected and then formulate initial high-level security requirements. Here are a few examples:

  • The confidentiality and integrity of customer data (GDPR) must be ensured.
  • Note: there are further requirements, such as the data privacy statement and the deletion of data, resulting from the GDPR
  • It must be possible to book city tours 24/7. Thus 95% availability is required.
  • The correctness and reliability of the city tour information (location, prices) has to be guaranteed

These requirements are added to the backlog and concretized in the refinement process. Just like functional requirements, security requirements can be formulated as user stories and correspoding acceptance criteria. It’s important that dependencies between security requirements and functional requirements be taken into account during backlog grooming and sprint planning in order to enable efficient implementation.

After requirements, system design is the next important step, a chance to incorporate security from the beginning. The software architecture and chosen technical components be compatible with the necessary security requirements. On the basis of the technical architecture, unidentified threat scenarios can be identified and analyzed. A very efficient tool for this is threat modelling. A threat model is usually created in the form of a data flow diagram. The focus is on representing essential processes and data flows on the basis of an architecture model.

In comparison to the data flow diagram, a threat model contains an additional element, the so-called trust boundary. A trust boundary marks a change in confidence levels. Examples for this are system or user interfaces.

The diagram below shows a threat model for the online shop. It contains actors, central processes and data flows, as well as a database where the tour information, customer data, invoicing details, and the guestbook are stored. All diagram elements are given a unique number. The numbering allows for the assignment of identified threats to the model. Important trust boundaries are represented in red.

Note: Data flows that aren’t important from a security point of view are not represented. Technical details have been left out in order to make the diagram easier to read. However, these should be documented and taken into account separately.

microTOOL Blog: Threat model

In an agile project, an initial threat model should be created as soon as the basic architecture and essential features of the application are determined. Review and discussion of the model are part of the definition of done.

Following the data flow, the threat model provides a sequence for identifying and analyzing threats. At each step, possible threats are identified. We can identify a few threats even in our small example. Here I’d like to limit myself to a few obvious threat scenarios:


STRIDE Model Threat Possible defenses – a few examples
Password, e.g. via phishing attack, dictionary attack, … Storage of passwords, password rules
Tampering 3
Trust boundary A
Attacker hijacks the session of the shop owner and changes city tour offers (prices, dates, meeting points, …) e.g. via Cross Site Scripting Secure session management, input validation, data encryption during transmission, data integrity verification
Information Disclosure 10
Trust boundary B
Accessing customer data and orders during data transfer or through unauthorized access to the web shop or database Encryption of data during transmission, authentication and authorization when accessing the web server (API), Least Privileges for database input validation and masking
Denial of Service 4, 14
Trust boundary B and C
DoS- attacks through the guestbook or accessing the webshop Captcha, secure availability of the guestbook and the webshop

In our example, the threats identified above have been evaluated as high security risks because they’re widespread and easy to exploit, and because they pertain to the “crown jewels” defined for our software:

  • Integrity of the city tour information
  • Confidentiality of customer data
  • Availability of the online shops

Simple methods such as STRIDE from Microsoft can be applied to identify threats on the basis of the threat model. STRIDE categorizes the most important threats (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privileges). There are also easy to use methods for evaluating threats (e.g. Microsoft DREAD, OWASP Risk Rating). These take various factors into account concerning amount of damage, how easily the vulnerabilities can be exploited, and possible attackers.

The following examples have been chosen to show how concrete security stories can be derived from identified threats:

Security Story 1

As a customer of the webshop I would like my personal information to be protected from access by third parties so that it can’t be exploited for their purposes.

Acceptance criteria for 1

  • Ensure that the transfer of data from the customer’s browser to the web server is encrypted with TLS 1.3.
  • Ensure that only authenticated and authorized users have access to customer data via the webshop.
  • Ensure that only authenticated and authorized users have access to the database.
  • Ensure that communication between application components, including API and database, requires authentication.

Security Story 2

As the owner of the webshop, I want to be the only person able to create and modify information in the online store, so that my offerings can’t be manipulated by third parties.

Acceptance criteria for 2

  • Ensure that the shop owner has to authenticate herself with a name and a password.
  • Ensure that the shop owner must choose a password of at least 12 characters long.
  • Ensure that the password is checked against a list of known compromised passwords when creating the account and choosing the password. Only non-compromised passwords will be accepted.
  • Ensure that the shop owner can change her password when desired.
  • Ensure that the shop owner receives an email when her login details are changed.
  • Ensure that the password is stored with salted hash encryption.
  • Ensure that the session token becomes invalid once the session has ended or expired.
  • Ensure that session tokens are not displayed in URL parameters or error messages.

These examples represent a very small selection of possible stories and acceptance criteria. They are useful for understanding the basic principle, but they are not a complete picture.


Security activities can be effectively incorporated in agile development processes. As with any new procedure, it might be a little bumpy at the beginning, but systematic integration in the agile process will make things smoother with every sprint.

Threat modelling is an efficient tool for helping teams systematically analyze threats and continually deploy and test countermeasures within an agile development environment. Documenting threats and the measures taken creates transparency regarding application security. This is very useful, not least of all in the event of a possible security breach.

Although there’s still little pressure to create secure applications, it’s worth considering that you can gain an enormous security advantage without much effort. Today, sustainable software development demands quality and security. The necessary things that need to be in place are security knowledge in the team and support from management, as well as a structured, systematic approach and useful tools.

Learn more about Secure Software Engineering at the author’s website: