The Rehabilitated Security SDLC

How is it that as we, as security practitioners, refuse to think differently about how we secure our applications? For the better part of the last 15 years I’ve been focused on application security concepts and research. I’ve spent countless hours analyzing how attackers target applications, thoroughly understanding the different vulnerability classes that affect applications, and many months modeling attack probabilities and risk levels. I’ve always been of the belief that if we could just teach our developers to write secure code, the issue of web application security could be a solvable problem. I’m here to tell you the cold hard truth about modern appsec…

Web application security is NOT a solvable problem via improvements in SDLC alone. We must get beyond SAST + DAST in isolation if we want to have any chance of success.

The Golden Era of The SDLC — Secure Development Lifecycle

The SDLC has been around for a long time. As a consultant, I remember helping customers implement their first SDLC in the early 2000’s. Back then the concept of writing secure code was as foreign to most enterprise development organizations as humility is to Donald Trump. Sure, the most technically advanced companies were thinking about creating a program that would lower the security flaw count in their development organizations, but even those advanced enterprises didn’t have a clue how to really execute on that vision.

Fast forward 15 years and we find out that even the best implementations of SDLC still can’t get you to a place where your enterprise has zero, or even near zero, latent security flaws in its production code. Many of the more advanced enterprises improve application security via an SDLC, but somehow we are still experiencing breaches in applications developed using strong SDLC methodologies. These breaches are resulting in financial loss for customers and revenue loss for the enterprises themselves.

I’m not writing this blog to deride the use of an SDLC. Quite the opposite actually. Without the SDLC, enterprise applications would be nowhere near as secure as they are today. Using static and dynamic application security testing tools (SAST and DAST) are a great way to implement security into your development arm, and the results are absolutely tangible with a great security return on that investment.

However, I do think it’s time for an application security overhaul. And that overhaul needs to center on how we approach application security and the SDLC at a fundamental level.

Then Came SaaS, Agile, and DevOps

When the development world ran with release cycles scheduled for every 12–18 months, security via the SDLC was possible. It made sense to put a two-week secure design phase upfront, code auditing throughout the development phase, and a multiple week penetration test prior to rolling out the code to production. The security controls were not the gating factor from helping the business make money. The code couldn’t (and shouldn’t) be written or approved any faster than the predetermined release cycle that customers were willing to pay for new versions of the application.

Then came agile development, software as a service, and DevOps. All of a sudden the application release cycle was pushed down to a few months, then a few weeks, and eventually the concept of continuous deployment gave the most aggressive companies the ability to push into production 30–50 times every single day! As organizations realized that they could see revenue, competitive, and customer satisfaction advantages by moving much quicker, the business mandated an overhaul of their development processes. DevOps was born in order to break down the barriers and silos between the development and operational arms with a goal of speeding time to market for new features. What they didn’t consider was how application security would need to adjust to these changes.

Defining The New SDLC

How in the world is the old SDLC supposed to keep up with this pace of change and speed of development? It just can’t. It’s no longer possible to put multiple weeks of security analysis into an SDLC that puts code into production at such a high frequency.

We must reinvent the SDLC using operational security data. Visbility into real time attack signals improves the efficiency of the SDLC in lock step with the increase in development speeds.

Modern development using DevOps is centered on a few specific points. I’ve taken each of these points below and outlined how enterprise application security programs must change to support the new concepts.

Matching of production, testing and development environments

Enterprises must match production, testing, and development environments when it comes to security. If we execute application security review throughout the chain of development environments, then we have implemented numerous looks at the code prior to production, and we haven’t slowed down our development processes. These checks must be automated and live in the hands of the development team itself.

Creating a reliable and repeatable process for deployment

Application security must become reliable and repeatable given the new models of development. This won’t happen with antiquated tools and processes living in isolation. To be successful, enterprises must take real time attack data from their production applications and use it to improve the efficacy of the SDLC. They can achieve this improvement by looking at the who, what, when, where, and why of the attacks that happen against their applications and use that information to prioritize where they spend their limited SDLC resources.

A deployment batch size of one

If modern enterprise development focuses the deployment batch size down to one feature at a time, security must focus the assessment and security testing process down to that same batch size. Looking at each individual feature as it is created and eventually pushed into production is a tenable solution, looking at all of the features of an application at once is not. Security unit tests are just as important as feature unit tests in the new development model.

Continuous monitoring and validation of operational quality characteristics

Enterprises understand that to be successful in modern code development models they must integrate the operations and monitoring side of the house with the quality and development side. These two silos must come together as one to allow for continuous monitoring and validation of operational quality characteristics. Application security must be viewed under the same lens as the merging of development and operations. Continuous security monitoring, validation, and analytics should be used to increase the overall operational security and quality characteristics of the application base.

Amplification of feedback loops

Understanding feedback looks is imperative to continuous improvement. As enterprises move to faster development models they find that feedback loops are required to improve how they execute on everything from deployment to sustainability. Security is no different. The data that comes from a run-time application security system, when fed back into the traditional SDLC, amplifies and speeds up the security feedback loop. Shortening the turnaround time and accuracy of the feedback loop will improve the SDLC as well as the overall enterprise application security profile.

More to come

There is way more to this problem than this short blog post. The SDLC is ripe for reinvention. The technologists that are leading the charge from a development and operations perspective must look to their security brethren to figure out how we make application security, specifically around the SDLC, better given the new state of the enterprise development space.

Keep an eye on Signal Sciences’ Labs for additional articles and commentary on how application security is being reinvented right here at Signal Sciences.

Thanks for reading this article. If you enjoyed it please let us know by clicking that little heart below.

At Signal Sciences we are building the industry’s first Next Generation Web Application Firewall (NGWAF). Our NGWAF was built in response to our own frustrations of trying to use legacy WAFs while enabling business initiatives like DevOps, cloud adoption and continuous delivery. The Signal Sciences NGWAF works seamlessly across cloud, physical, and containerized infrastructure, providing security without breaking production traffic.