DevOps Success is Contingent on Shifting Left

Intro -- Part 2 of Component Management Strategy and DevOps -- Part 3 Up Next

Ok, I'll admit it. It's another cliche. It's really not a new concept at all - security experts have been talking about designing security in from the start for decades. So what's different? Well, first of all, the concept of shifting left is not just about security from the start, it's about shifting all activity to the left. It's about shifting activity that falls under the purview of the DevOps "team", and it's even more important since applications are now being developed using agile methodologies. But I would argue the biggest difference is that while security experts and industry analysts have long advised organizations to design security in from the start, we now have solutions that can make this a reality.

Unlike application security approaches of the past, where -

• Results required long "batch" windows to produce.
• Security results were not integrated into the development lifecycle.
• Results were not delivered until the development process was complete.
• Results were plagued with false positives.

There is a move to provide solutions that -

• Provide results early in the development process.
• Guide developers with information so they can build secure apps from the beginning.
• Make information available instantaneously, without long "batch" processing windows.
• Provide stage appropriate guidance & enforcement throughout the entire development lifecycle.

What exactly do we mean by shifting left? When you think of the software lifecycle as a continuum moving from left to right – design, development, test, production; the more effort that is shifted left or earlier in the process, the better. When you can make design and architecture decisions early, when you can select the right component from the beginning, when you can identify problems early, when you can fix bugs and vulnerabilities, early, etc., you can improve your software delivery capability, you can improve the reliability and trust of your applications, and you can reduce your development and maintenance costs. Prevention is the ultimate form of shifting left - if you can prevent problems in the first place, you don’t have problems to identify, you don’t have things to fix, etc.

As you design your "shift left" approach, make sure that your approach addresses these challenges:

• Identify problems or potential vulnerabilities early in the development process.
• Fix problems early in the development process vs. late in the QA stage or in the production environment.
• Ensure that all parties are included in the initial design and development of the software application (including IT Ops, security, etc.).

And in this day of component-based development, where organizations turn to components to assemble applications, DevOps can effectively shift activity left if they can:

• Provide guidance that allows developers to pick optimal components when they start assembling applications.
• Integrate the component meta-data into the tools that developers and related constituents use so problems can be discovered early.
• Leverage tools and solutions that provide remediation support vs. simply identifying vulnerabilities and flaws.
• Assimilate security, licensing & architecture efforts early in the development process.
• Monitor your production applications for newly discovered component vulnerabilities and flaws.

The ultimate benefit of shifting left is delivering trusted applications faster with less effort - sounds like a perfect complement to DevOps, correct? And, what's great about this approach is that you can measure your results. If your efforts are successful, you'll see it in your metrics: Defects to Production, MTTF (Mean Time to Failure), and MTTR (Mean Time to Repair).

Stay tuned for the next DevOps post about Optimizing the Application Delivery Tool Chain.