The Three Patterns of Software Development for SDLC Security

Friday, August 30, 2013

Rohit Sethi


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 a 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.

This 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).

            • May be 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 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 iteration planning process by baking security requirements into 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 of 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 a SDLC security initiative. Read our guide on how to embed requirements into each.

Possibly Related Articles:
Security Awareness Security Awareness Webappsec->General Webappsec->General
SDLC Development
Post Rating I Like this!
Marc I Hi Rohit,

I think you're confusing a few things.

1) Waterfall and Agile are two separate paradigms (not patterns) for moving through an SDLC, as is a Spiral Model, a V-Model, or an S-Model. The SDLC is a "backbone" for any paradigm.

2) Continuous Development and Continuous Delivery are paradigms for automating pieces of your SDLC, regardless of your paradigm.

When you have a solidly defined SDLC (address = ), you can apply any paradigm for getting it, and you can apply any of the Continuous Frameworks for automating pieces of it (such as Building, Pakaging, Distributing, Installing, Instantiating, Initializing, and Executing).

This confusion is probably why your article has about five thousand views but zero likes.

Rohit Sethi Hi Marc,

Thanks for your comments. Admittedly, we are overloading terms to describe the three patterns. There aren't any industry accepted names for these patterns today, and when we hear our clients discuss the patterns we find that they tend to use the paradigm names.

The key point of the post is that a single security approach that doesn't take into account the differences in the patterns (and the dozens named development methodologies that fit within them) is likely to fail. For example, requiring big up-front security design steps in a process that has no formal design step whatsoever is bound to fail. Companies that are faced with hundreds of development teams often simply cannot create sufficient security process guidance to deal with each specific development methodology. We've found that when these companies have toolkits for each of the three patterns then their approaches are more likely succeed.

With respect to continuous integration, the term is overloaded in a different way. There are tools, such as Jenkins, that developers use for continuous integration. This set of tools has enabled developers to build without the need for formal releases or even iterations. Not everyone who uses continuous integration tools has dropped the concept of up-front planning stages but many have. Trying to embed security into such a process requires a shift away from activities like analyzing a sprint backlog for security requirements.

Rohit Sethi
Marc I Hi Rohit,

I think you have to be very careful about "overloading terms." Doing so causes ambiguity and ambiguity often causes lack of credibility.

For example: You talk about "#3: Continuous Development" being "obsessed with automation." And yet, in the title you group "No Process" with "Continuous Development." You cannot automate, at all, without a clear and repeatable process as repeatable process is the very foundation for automation. Therefore, the "obsession with automation" is, in fact, an obsession with process.

The foundation is to start with an industry standard SDLC, like the one from IF4IT, Once you have an SDLC, regardless of where it came from, you would start to do things like figure out how to apply something like an Agile approach to get through it. Once you have that approach, you can then do things like apply Continuous Build, Integration, and Delivery patterns to it, to optimize the processes and make getting through the SDLC much faster, with lower costs, and with much higher levels of quality.

When you have a process like the above, you haven't abandoned the "upfront" phases so much as you've made them leaner/lighter and easier to get through. For example, you can't possibly have a Release without knowing what you're going to include in that Release. Somewhere, someone has to plan the things that will go into it. Such activity is, in fact, work that is related to those up-front phases of the SDLC (whether you choose to formalize such work or not).

Hope this makes sense.
Marc I By the way, I forgot to add that you may want to also consider things like separation of duties, between environments ( as a means of creating a more secure SDLC. You can also apply things like separation of User IDs and Accounts as a means of ensuring that work in any one environment doesn't clobber work going on in any other environment.
williama willis Of course, you could always make a piece of composing on how to make a piece of composing.
williama willis To the primary type, add the various meats, the design and the little elaborations. The joy of content marketing comes from the fulfillment of having done it yourself.
williama willis Why should you use it? Well, here are some of the top reasons why you should.
williama willis The SEO Adelaide companies have accessibility be unique. The SEO Adelaide centered companies generate has local taste, but international appeal.
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.