In the world of Agile development, new versions and small updates are released daily for many companies, where small teams work side-by-side to improve products daily. Agile offers benefits including higher confidence by customers, the ability to make changes and fix issues immediately and in small increments, better, faster testing, and improved planning. Tech companies like Netflix, Etsy, and Amazon have become household names to watch, thanks largely to how they innovated (and continue to innovate) using the Agile methodology.

The Problem with Secure Software Development in the Agile Era

Our current situation is that most organisations have or are planning on adopting Agile principles in the next several years, yet few of them have figured out how security is going to work within the new methodology. The changes that Agile brings – frequent product releases and dynamic feature changes, among others – create a wholly different threat landscape from those posed by waterfall development methodologies.

There are plenty of reasons why security is left behind in many Agile organisations, but for the sake of brevity, we’ll break it down into two main issues.

Security is seen as a ‘Non-Functional Requirement’ (NFR), a requirement related to the state of the system, rather than, as the name suggests, functional areas of the system.

The problem with NFRs in Agile organisations is that they are hard to pin down in user stories, a main feature of the Agile methodology.

User stories follow a structure of “As a (type of user), I want/need (some goal/desire) so that (reason for goal/desire)”. Each requirement is crafted into a story with a reasoning for the requirement so that developers can plan for the experiences real people will have with the project. These stories closely guide team planning and development. Security requirements can be hard to turn into tangible stories. Especially given the fact that security controls often arise through risk aversion processes that include looking at the full threat landscape, security can be hard to pin down to one story in one application. It’s not impossible, but a lack of strong security user stories can easily prevent security from being planned or implemented correctly.

The second reason why security and Agile have historically been at odds is a lack of Agile-ready security practices and tools.

In waterfall methodologies, security planning is done at the beginning, while security testing is accomplished at the end. Security is missing from the whole middle part – the development process. While this may have worked to some degree in waterfall development organisations, it simply can’t in Agile. When it comes to Agile, security requirements and processes need to be synced up to business requirements. Security can’t (and won’t) be done in a vacuum – Agile organisations, and the security teams within them, need to make sure security fits in with the rest of the crew.

Creating a Secure Development Lifecycle in an Agile Organisation

The process of integrating a secure development lifecycle into the Agile development process can be described by the following high-level steps:

  1. Put Developers in Charge of Secure Development
    At this stage, we help formally define roles and responsibilities around the SDLC process, organise secure coding and code review training, create and maintain secure code review checklists, build the architecture vision, taking into account security requirements.
  2. Implement Continuous Integration Security Practices in the SDLC
    During this step, we help you implement automated security tools such as static code analysis and scanners in the build pipeline. We also help define security deliverables such as automated tools reports (before minor releases) and manual penetration test reports (before major releases) as a part of quality gates.
  3. Adapt, Iterate, and Grow to Keep Security Agile
    Next, we help you maintain security awareness, organise knowledge refresh training, security retrospective, and lessons learning sessions, and build and maintain a knowledge base.
  4. Build a Security Culture through the Above Practices
    As a result of the previous steps, all secure SDLC sub-processes (risk analysis, continuous integration, and the project’s security vision) and artefacts (code review checklists, code analysis security metrics, vulnerabilities, and threats) become crystal clear, familiar, and easy to follow for everyone involved in the SDLC process.
  5. Build Security Through User Stories
    At this stage, user stories are analysed from a functionality and security perspective. All stories’ specific security measures, which prevent the loss of confidentiality, integrity, and availability of sensitive information, are designed based on the existing security architecture vision and consider the results of the risk analysis.

Achieving Secure SDLC Objectives

Successful implementation of the steps described above will allow your SDLC process to meet the main security objectives:

  1. Properly assign security responsibilities and resources
  2. Define software security policy and strategy
  3. Identify and mitigate threats and vulnerabilities
  4. Build and maintain secure change management, software integrity, and data protection processes
  5. Maintain a high level of internal communication and communication with the customers.

As a result, you will build and maintain a mature process of secure development and be able to confirm its compliance with industry standards, such as the PCI Software Security Framework or ISO 27001.