The Three Patterns of Software Development for SDLC Security

The Three Patterns of Software Development for SDLC Security

A one-sized fits all approach to Software Development Life Cycle (SDLC) security doesn’t work. Practitioners often find that development teams all have different processes — many seem they are special snowflakes, rejecting a single SDLC security program. This may not be much comfort to somebody who needs to lead an SDLC Security initiative across a large organization — but in our experience it is possible to build a program of application security that works for different development teams by recognizing that each SDLC tends to fall into one of three patterns: Waterfall, Agile and Continuous Development/No Process. Your secure SDLC initiative should provide a toolkit that works for each without severely impacting the developers’ productivity. Our whitepaper presents detailed guidance on how to embed security requirements into each.

Characteristics of the Three Patterns for SDLC Security:

1. Waterfall: Development with big upfront design.

  • Managed by a central person or team of Project Managers (PMs).
  • Maybe iterative, but generally has long release cycles (i.e. quarterly, bi-annual or annual releases).
  • Common in highly regulated industries, large enterprises, and software vendors who create expensive to patch software (e.g. shipped software, embedded devices).

2. Agile: Iterative development

  • No formal project management as compared to waterfall. Scrum masters are responsible for watching over the process while product owners are responsible for setting priorities.
  • Each release results in shippable software — typically 1–4-week releases.
  • This tends to be the most popular style for internal applications, mobile applications, and increasingly external-facing web-based applications. In general, we see agile as the most common pattern of development for new software.

3. Continuous development/no process: Either hyper-optimized with automation, leveraging continuous integration tools like Jenkins configuration management systems OR absolutely no development process or standardized tooling, such as Application Lifecycle Management (ALM) tools. Both styles impact security requirements as such:

  • Releases and even iterations are completely removed from the picture — software is in a continuous state of release, with no chance to embed security ahead of time.
  • Absolute minimization of process overhead.
  • Cost of a defect is low since it’s relatively easy to deploy a fix.
  • Continuous development is very popular with eCommerce companies and other Internet-based businesses.

Each style tends to have different needs from a secure SDLC standpoint:

1. Waterfall

  • Willingness to spend-time up-front to “do it right” — if and only if the business thinks security is a priority.
  • With sufficient buy-in, design-time analysis such as threat modeling, and longer cycles on security activities such as a full-scale code review are conducted.
  • Can accommodate several different security assessment techniques.
  • Cost of fixing a security vulnerability can be extreme, the window of risk exposure can be particularly long if it involves end-users patching their systems

2. Agile:

  • Primarily feature-driven, particularly when adopting user stories as the primary method for conveying requirements.
  • Typically do not have any process around managing non-functional requirements
  • Can adopt security into the iteration planning process by baking security requirements into the product backlog.
  • Emphasis on automated testing, whenever possible — may be able to accommodate manual testing from QA or security teams.
  • Cost of fixing security vulnerabilities/window of risk is lower than waterfall, but there is still an emphasis on shipping defect-free software.

3. Continuous development / no process:

  • Obsessed with automation and protecting developers from process overhead. Anything that requires developers to take time away from coding is often met with fierce resistance.
  • No ability to plan up-front except on a per-feature or per-change basis.
  • Often willing to invest in building security features into frameworks, automated front-end tools to shield them from developers.

Recognizing the three patterns and providing toolkits that work for each can dramatically lower the resistance for an SDLC security initiative. Read our guide on how to embed requirements into each.

Also, see:


Previous Article
Making the Business Case for a Software Security Requirements Program
Making the Business Case for a Software Security Requirements Program

Most of our customers need to justify the costs of implementing a software security requirements program wh...

Next Article
4 Reasons Why Developers Don’t Read Secure Programming Guides
4 Reasons Why Developers Don’t Read Secure Programming Guides

At Security Compass, we had the experience of building secure programming guideline documents for a number ...