Over a million developers have joined DZone.
Platinum Partner

DevOps Success is Contingent on Shifting Left

· DevOps Zone

The DevOps Zone is brought to you in partnership with New Relic.  Learn more about the common barriers to DevOps adoption so that you can come up with ways to win over the skeptics and kickstart DevOps.

This post comes from Mark Troester at the Sonatype blog.

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.

The DevOps Zone is brought to you in partnership with New Relic. Quickly learn how to use Docker and containers in general to create packaged images for easy management, testing, and deployment of software.


Published at DZone with permission of Jason Van Zyl , DZone MVB .

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}