Over a million developers have joined DZone.

DevOps Success is Contingent on Shifting Left

DZone's Guide to

DevOps Success is Contingent on Shifting Left

· DevOps Zone
Free Resource

The DevOps Zone is brought to you in partnership with Sonatype Nexus. The Nexus Suite helps scale your DevOps delivery with continuous component intelligence integrated into development tools, including Eclipse, IntelliJ, Jenkins, Bamboo, SonarQube and more. Schedule a demo today

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 Sonatype Nexus. Use the Nexus Suite to automate your software supply chain and ensure you're using the highest quality open source components at every step of the development lifecycle. Get Nexus today


Published at DZone with permission of Jason Van Zyl, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}