Shift left vs. shift right

Testing throughout the software development lifecycle is critical for keeping up with user expectations, functionality requirements, and security measures. To shift left is to incorporate security testing as soon as possible to find vulnerabilities and fix defects as early as possible in development. To shift right is to monitor user behavior, usage, performance, and security metrics in the production stage to verify software operability.

Both shift right and shift left are meant to evaluate and ensure quality and performance of new products and features throughout the DevOps process and software development lifecycle (SDLC) by focusing on continuous testing methods. The thinking behind the principles of shift left and shift right in an agile practice is to “fail small, recover quickly” in order to catch potential issues before they become major problems.

To understand shift left and shift right, it’s first helpful to think of a software development lifecycle as a line that goes from left to right. The left half of that line consists of the coding stage and the building stage–the right half is the production stage, which refers to deployment and monitoring of the software.

Traditionally, testing the security of the software only came into play late in the middle of the SDLC–just before it was sent to production. Delaying testing, however, creates space for security flaws to go undetected as the software moves further through the lifecycle process. This means that when a vulnerability is eventually discovered, teams are forced to struggle with the complex and costly rework that is required to isolate and mend the flaws that have been compiled into the application until that point.

Eventually, organizations started realizing that if they were able to remove bottlenecks earlier on in the SDLC, flaws and errors cost less to fix, resources were saved, and a better finished product was created. This is when the concept of “shifting security to the left” was born and has since become fundamental to modern software development.

Developers do not profess to be security professionals, nor do they wish to. As it is, they struggle to keep pace with their release cadences, especially if they are responsible for fixing or amending code written by another developer that may have accidentally introduced a serious vulnerability.

As software architecture becomes more complex, expansive, and decentralized, it becomes more challenging to effectively monitor and manage security across an organization. Modern software delivery methods that embrace continuous deployments across hybrid environments require a new security approach–one that provides security guardrails earlier in the application development process, automated security at each step, and transforms security into a business enabler.

Developers use the shift left strategy as a proactive measure to help improve application security by identifying and remedying defects before they move too far forward in the pipeline. This strategy involves integrating security practices and testing as early as possible in the development process, rather than leaving it as an afterthought. Shift left is closely associated with the rise of DevSecOps, which emphasizes early and continuous security integration. 

Organizations experience security incidents across the build, deploy, and runtime phases. Implementing and automating DevSecOps with a shift left approach provides developer-friendly guardrails that can decrease user error at build and deploy stages and protect workloads at runtime.

Techniques involved in shift left testing can include:

• Static application security testing (SAST) -  analysis of an application's source, bytecode, or binary code for security vulnerabilities.
• Dynamic application security testing (DAST) - a blackbox testing methodology used to uncover potential security flaws by performing automated security scanning against a running target.
• Threat modeling - the process of thinking about each decision made in a given system and extrapolating how these may affect its security profile, either immediately or in the future.
• Security architecture review - identifying, evaluating, and mitigating risks to fortify an organization’s security measures against present and emerging threats and risks.
• Container image scanning - analysis of a container image layer by layer to detect potential security threats.
• Code signing - method of putting a digital signature on a program, file, or software update so that authenticity and integrity can be verified upon installation and execution. 

The practice of shifting left aims to find and fix vulnerabilities early at code time. This not only ensures better security but also enhances user experience and functionality by delivering software faster and more frequently with higher quality. It speeds up development efficiency and can also reduce overhead costs by detecting and addressing software bugs earlier in the development cycle. 

As threat vectors become increasingly sophisticated and attack surfaces continue to grow exponentially, businesses recognize that relying solely on shift left testing during the build phase will not sufficiently protect them from evolving security threats.

This means that shift left has developed a complementary phenomenon: shift right testing. To shift right is to continue the practice of testing, quality assurance, and performance evaluation in a post-production environment. 

To implement shift right testing, development teams perform controlled experiments toward the end of the software development cycle with the aim of examining functionality, performance, failure tolerance, and user experience.

Techniques involved in shift right testing for key controls and real-time visibility can include:

• SIEM - stands for security information and event management. It’s a solution that helps organizations detect, analyze, and respond to threats.
• SOAR - stands for security orchestration, automation, and response. It seeks to alleviate the strain on IT teams by coordinating, executing, and automating tasks between various people and tools.
• Canary deployments - testing a new functionality on a subset of users before releasing it to the entire user base.
• Deployment rings - gradually deploying and validating changes to your extension in production, while limiting the effects on your users.
• A/B testing - an approach to testing a hypothesis by creating a control group and introducing variant scenarios, functionality, appearance, etc., and measuring the reactions across scenarios against an intended reaction.
• Fault injection testing - intentionally introducing faults into a system in order to test it.
• API security testing - track egress traffic and outbound calls to understand behavior and detect security incidents. Istio is a service mesh platform that provides the underlying communication channel and helps manage authentication, authorization, and encryption of service communication at scale.
• Chaos engineering - “breaking things on purpose” to test the resilience of a system.
• Blue-green deployment- an application release model that gradually transfers user traffic from a previous version of an app to a nearly identical new release–both of which are running in production. 

By observing the behavior of software in real-world environments, teams can proactively detect security threats in runtime and make sure applications are performing as intended. Shift right testing allows for a continuous, real-time feedback loop from users as well as the opportunity to analyze issues that may not have been anticipated. 

As organizations move to cloud native constructs and modernize their applications to include technologies like microservices and containers, a best practice is to adopt both shift left and shift right strategies. By providing your team with the capacity to run end-to-end testing at all phases of the SDLC, your organization moves closer to the ultimate goal of continuous integration and continuous delivery (CI/CD).

The benefits of adopting a shift left and shift right methodology include increased efficiency, improved product quality, better security, faster time to market, and improved user satisfaction. Furthermore, organizations have found that the relative cost to fix bugs, based on time of detection, increases over time. In other words, the longer you wait to fix an issue, the more money it will likely cost. Thus, taking the preventative measures of shift left can likely make a difference in your bottom line. 

Safeguarding your software supply chain requires a multifaceted approach. There are many things you can do to improve software supply chain security, and each will add another layer of protection for your organization and customers.

To begin implementing shift left and shift right principles in your organization’s development lifecycle, start with implementing a software bill of materials (SBOM), that is, a nested inventory of all sources and dependencies–including source code, open source and software libraries, middleware, and development frameworks–that are part of an artifact.

From there, start implementing automated testing to gather data and analysis throughout the software development and deployment pipeline. Continuous testing at each stage of the SDLC is the best way to monitor performance and detect root causes.

Perhaps most importantly, make sure to collaborate and communicate within and between departments, so as to identify problem areas within each team and find the correct tools that work for you. 

In today's rapidly evolving technology landscape, organizations increasingly embrace containerization to achieve greater scalability, portability, and efficiency in their application deployments. While containerization has its benefits, it also can present IT security challenges that must be addressed to improve the safety, confidentiality, and accessibility of containerized applications. As the use of cloud-native apps grows, improving the security posture of containers and Kubernetes becomes vital.

Red Hat® invests significantly in the maintenance of open source software throughout the life of every product. For software we ship, we take on the responsibility of not just supporting it but also addressing issues of significant concern, such as security.

Red Hat Trusted Software Supply Chain helps organizations build security into the software development lifecycle from the start. With the right security software, organizations can protect themselves from risks and vulnerabilities within their supply chain systems. Without the proper protection, they risk losing the trust of their users, customers, and other stakeholders. With Red Hat Trusted Software Supply Chain, customers can code, build, and monitor their software using proven platforms, trusted content, and real-time security scanning and remediation.

Red Hat OpenShift® champions the shift-left approach by automating DevSecOps and integrating security early and throughout the development cycle. Its array of out-of-the-box developer tools, CI/CD capabilities, and a focus on security ensures a safe and efficient software supply chain. It is a comprehensive, Kubernetes powered application platform that helps enterprises build, deploy, run, manage, and provide security for innovative applications at scale.

Red Hat Advanced Cluster Security for Kubernetes shifts security left and automates DevSecOps best practices. The platform works with any Kubernetes environment and integrates with DevOps and security tools, helping teams operationalize and better secure their supply chain, infrastructure, and workloads.

Red Hat Ansible® Automation Platform provides a consistent enterprise framework for you to build and operate IT automation at scale, while prioritizing security throughout the software development lifecycle. It allows your teams to automate security and compliance across your enterprise, and use certified automation content to respond to threats in a coordinated way—with around-the-clock support. Ansible Automation Platform also offers a number of security integrations that are supported by Red Hat and our technology partners.