DevSecOps: Shifting Left and Shifting Right

Organization’s ability to cope with the complexity of delivering software at high velocity, with confidence and excellent quality, in a multi-speed IT landscape and hybrid environments has become a reality with the DevOps best practices like continuous integration, continuous delivery, and continuous deployment. But there have been shifting approaches that are confusing to Devops people, 'shift left' and 'shift right.' So, the question is, what exactly are we shifting here?

Let's dive deeper into what shift left and shift right mean in DevOps, and how software teams can embrace these concepts to achieve real innovation through continuous delivery of high quality software applications.

Shift left or shift right, the methodologies are usually applied with respect to the security aspect of the software development pipeline. Shift left is primarily applied to two main issues- all related to quality: Testing, and Security (security is a type of testing/ensuring quality, but there are other types of shift-left testing- for example doing performance testing early on, pre-flight integration tests, and others)

DevSecOps:

DevSecOps is the extension of the DevOps philosophy. DevSecOps is a concept that introduces security into the software development lifecycle. If DevOps is about increasing the level of collaboration through seamless communication between development and operations, then DevSecOps is about integrating security into the two.

DevSecOps works on the principle of security first, and everyone is responsible for the security, not just the security team.  

No doubt that DevOps is a must for firms to rapidly release the software to the market and has many benefits, but it has been observed that DevOps still does not thoroughly integrate security in its processes, and security teams continue to work separately in silos from the DevOps team.

Security vulnerabilities are handled still differently, leaving security to the security people, which affects the whole principle of DevOps. So, the need is high priority security checkpoints at each stage of the software delivery pipeline and assigning security as everyone’s job, not just security people. DevSecOps practices aim to incorporate security throughout the DevOps workflow, and this allows agile development without compromising security.

When it comes to security, there has always been confusion about whether to shift left or shift right. Let’s see what conclusion we arrive at further in the article. 

What is shifting left?

Shifting left is when a given process is done earlier in the software delivery chain. It can be testing, security, and more. 

The main idea behind shifting left is, performing a given process the earlier, the better in the delivery pipeline, with this, you can easily detect and fix problems than waiting longer and then getting surprises at the end, and this poses a higher risk of delaying the other processes and production issues. 

Reasons to adopt the Shift-Left testing approach: 

• Improved design implementations
• Improved software quality throughout 
• Bugs are fixed early before they reach end-users
• Massive time and effort saved
• Reduces gaps between developing and testing
• improvement of code quality increased developer confidence and efficiency 

What is shifting right?

Reversing some of the processes commonly performed earlier in the SDLC and performing them later in the delivery pipeline is known as Shift right. Shift-right is most often associated with testing in Production- where we can benefit from a large resource pool and heterogeneous user behavior.

Common patterns include feature-flags, blue/green or rolling deployments, and run-time analysis and tracing tools- designed to listen to quality/usage signals in large scale production systems to optimize/harden the application, ensure security, or limit the scope of risky/new features until they've been thoroughly tested with live production data and rolled out gradually.

Let's take, for example, shifting-left approach with testing, if you allocate resources and importance for doing unit tests, integration tests and other tests very early in the software delivery pipeline, you may fall out of resources in the end, and this might affect adversely since there is no much importance given at the pre-production stage and you my find it costly/difficult to do testing near the production stage.

Hence, shifting right ensures taking processes that typically happen before application release and moving them near the production stage; this will help us catch post-release and production issues before end users notice them.

A common key reason is that for some complex systems or apps, no matter how much we try to think ahead and design test scenarios with "shifting left" we can never cover all permutations that real user behavior can generate at large scale.

So it's inevitable that some bugs or behaviors would only manifest in real Prod environments. Another reason is that, many security compromises are reliant on abusing the network and these often mandate continuous security scanning and proactive remediation at runtime, not just in pre-prod.

Reasons to adopt the Shift-Right testing approach:

• Easy and improved customer feedback
• Enhancing end-user experience 
• Increased scope for automation
• Empowers high test coverage
• Lower production issues
• Allows engineering teams to have Blue/Green deployments and release rehearsals
• Empowers automated testing at the UI level

Shift left or shift right?

Shifting left and shifting right; both are valuable in the software delivery pipeline. Teams have discovered that agility and improvement come at all stages of the pipeline by implementing both shifts.

Even the idea of DevOps is the same – there should not be any silos between the teams, integration of all aspects of the software development and IT service delivery should be continuous. 

You should not only be testing at the beginning stages or just at the end stages, but the testing and security must also be implemented at each point of the delivery pipeline continuously with some sort of checkpoints to track if everything is on track. Concentrating efforts of testing only at one stage will automatically expose other stages at risk of getting ignored and unsure. 

Once both are implemented, in an ideal delivery pipeline, data and metrics collected from Prod (shift right) would feed back to the pipeline stages to the left- in order to optimize the pipeline, cycle time, or trigger specific pipeline stages based off events gathered in production (for example an error in Prod automatically triggering a roll-back pipeline to the last stable version, in order to ensure business continuity.

Shift both ways for a strong DevSecOps

A strong and recommended practice is shifting both ways in DevOps, this ensures more security and confidence. To do this, you need security checkpoints (as already discussed) at each point of the delivery pipeline till the end and every developer should ensure safety is by default included in their task list.

Companies also need tools to ensure security is maintained throughout and developers should  have access to such tools. Artifactory, the only universal repository manager that serves all binary types and CI/CD automation needs, providing full Docker support and integration enables developers to automate and deploy legacy applications. 

Along with Artifactory, JFrog Xray (Disclaimer: The Author works at JFrog) performs deep recursive scans of your Docker images and for all other types of binaries as well and identifies security vulnerabilities in all layers and dependencies, creating a comprehensive, end-to-end, cloud DevSecOps solution.

With the emerging need for DevSecOps requirements in the organizations, Xray makes perfect sense for security throughout your software delivery pipeline. Xray has the capabilities of checking, tracking, and ensuring that all licensed software components comply with your organization’s procedures and policies.

Officially speaking, there are 3 things/capabilities of Xray: Open-source security vulnerability scanning, license compliance, organization policies. It scans and uses data from industry-leading sources to determine whether a package or artifact contains a certain vulnerability.

This helps firms to block any unauthorized, vulnerable, and non-compliant software from going into production, and continuous scanning can ensure high and trusted security with continued safety and complete DevSecOps capabilities. Xray has a powerful automated response to violations, such as preventing a download or failing a build which is a best practice for DevSecOps and developers in the shift left approach.

Since developers see vulnerabilities and remediation when they first code the app, it helps companies to fix bugs and any code errors before they reach customers. 

Ensuring the fidelity and immutability of signed artifacts/release bundles to ensure these are vetted and no drift throughout the environments/stages - all the way to Production. That's not exactly "shift right" but promotes fidelity in the runtime environment. 

So as discussed above, it is not just shifting left or shifting right, it is shifting both ways and it should be continuous. DevSecOps is primarily a shift left approach and is now driving a revolutionary shift in IT culture, and there’s no doubt that DevSecOps transforms and organizes the way firms handle security.

DevSecOps can deliver a sustainable competitive advantage and has proven to be one of the ingredients in the digital transformation. The technical and business benefits that organizations can achieve from DevSecOps are very promising.

DevSecOps model will not only help to seamlessly embed security and compliance scans into the DevOps pipeline but also find and fix security and compliance concerns in cloud services.

Try JFrog Xray for DevSecOps

(Disclaimer: The Author works at JFrog)