Shift-left vs shift-right security is fairly new to software development debates. Traditionally, shift right existed long before shift left came onto the scene. After all, testing, monitoring, and issue resolution have historically occurred after code was shipped.
Shift-left security emerged to advocate that DevOps teams take on a security role as they moved toward more agile development practices, speeding up software development with more iteration steps compared to previous waterfall approaches. Continuous integration meant a new focus on earlier testing frameworks, automation, and security measures all meant to prevent complicated and expensive late-stage failures.
However, shift-right and shift-left approaches aren’t an evolution, with teams having moved from one approach naturally toward the other. And today’s teams aren’t all focused on shift-left testing as a result of the wisdom they gleaned over years of failures at deployment.
In truth, shifting right has reemerged with the promise that it allows teams to focus on vulnerabilities that “actually matter to organizations” — in other words, the production-based threats identified by how software behaves in real time. Pre-production threats, which are discovered in controlled environments, lack real-world context and may not fully represent actual risks. In contrast, runtime threats reflect true operational conditions.
Shift left and shift right work in tandem.
But should one take priority? Do they come with different tooling and automation challenges that should guide teams? And what’s the right balance for teams, tools, and an overall approach to this spectrum? We’re looking deeper at these two approaches, covering debates that impact teams who have integrated both approaches but are still seeking balance.
A Review of Shift Left and Shift Right
Shift left and shift right are complementary approaches to the role of security in the software development lifecycle, each focusing on different process stages where security tools might be focused to improve software quality, security, and performance.
Shift Left
Shift left moves testing and quality assurance earlier in the development process to identify and fix issues at early stages before they’re more difficult and costly to remediate. Benefits of shift left include:
- Reduced development costs
- Faster time-to-market
- Less rework as issues are identified early
- Improved code quality
- Enhanced security
- Fewer disruptions as code is “built secure” and ideally deployed with secure configurations, requiring fewer later code changes
Here’s an example: A development team implements automated unit testing as part of their continuous integration pipeline, catching issues so they can fix bugs before they reach the QA stage. Shift-left security testing integrated into the SDLC means testing early, but it also means that software at deployment is likely to be of higher quality.
Shift Right
Shift right extends testing and monitoring into the production environment to evaluate real-world performance, user behavior, and bottlenecks. Its benefits include:
- Improved experience for real users
- Better understanding of actual usage patterns
- Rapid identification of production issues
- Continuous optimization
Here’s an example: An organization incorporates an eBPF-based sensor into its infrastructure, allowing it to monitor and protect workloads during runtime at the kernel level. The sensor helps detect a zero-day vulnerability that may have gone unnoticed during pre-deployment testing. By using this form of shift-right testing, the organization gains real-world knowledge about how the infrastructure handles production traffic and security events, providing data that they can use to improve proactive defenses.
Examples of Shift-Left and Shift-Right Testing
The table below highlights key examples of shift-left and shift-right testing practices, each focused on a different stage in the software development lifecycle (SDLC).
| Shift-left testing | Shift-right testing |
| Static Application Security Testing (SAST) | Runtime monitoring with eBPF-based sensors |
| Infrastructure as Code (IaC) Scanning | Dynamic Application Security Testing (DAST) |
| Unit and Integration Testing with Security Focus | Cloud Detection and Response (CDR) |
| Dependency Scanning | Chaos Engineering for Security |
Deeper Debates Span the Divide
Many organizations have come to accept the feedback loop between shift-left and shift-right as the prevailing strategy since it’s proven impossible to master a shift-left approach, building with such precision to protect all workloads at runtime, all the time. Consequently, many organizations that enthusiastically embraced shift left have returned to runtime security out of necessity, but with the understanding that they will inevitably face a new hurdle: how to use runtime insights to improve development security.
Thus, security challenges have begun to center not on which approach to use but on broader issues such as how to integrate them smoothly, automate them without losing human oversight, and scale them.
Here are some current issues replacing the left/right debate with added nuance, since more and more workflows require an integrated approach. The solutions to these challenges will likely differ by organization size, existing workflows, and cultures.
Overall Balance: Shift Left vs. Shift Right vs. Integration?
While shifting both left and right is becoming the norm for cloud-native ecosystems, more organizations face the challenge of finding the right balance and ensuring the right level of security is embedded in processes from development to production.
- A heavier emphasis on shift left prioritizes early testing, proactive security, and faster feedback for developers, but at the cost of developer burden, false positives, and limited real-world context.
Organizations emphasizing shift left hope to keep the cost of fixes low and place a heavier emphasis on developer accountability. Another attractive benefit is reducing impacts to end-users and improving user experience.
- A heavier emphasis on shift right means real-time visibility, operational resilience, and user-centricity, but organizations remain reactive, struggle with incident overload, and rely on post-release fixes.
Organizations that emphasize a shift-right methodology recognize real-world conditions and scalability while focusing on problems with the highest impact on end-users. They maintain operational flexibility, too, since they can address threats without overhauling pre-existing development workflows.
- Balanced integration allows for continuous feedback loops between development and production environments, improving both shift left and shift right responses. It can mean introducing new tooling and reckoning with the need for specialized expertise and added organizational complexity.
Observability and Monitoring: Proactive vs. Reactive?
Balancing shift-left and shift-right as a whole is one thing, but related debates emerge about the right balance of impact on teams and the right use of integrated tools. One core challenge is observability — as integration grows, so does the burden on teams. Integration can mean an even greater data burden for teams. Where should security teams start? What should they prioritize in terms of monitoring? How should they respond once issues are identified?
- Proactive observability focuses attention on preventing issues earlier to minimize costs and downtime alike. Yet proactive observability can overburden teams with alerts, be difficult to scale, and make for a longer time to resolve issues.
- Reactive observability focuses on incidents directly impacting users based on real-time data. Addressing live, critical issues can have higher costs and impacts on customers and foster a constant sense of firefighting by teams tasked to address incidents.
- A hybrid approach means some benefits of each approach but lessened focus on either.
Cultural Impacts: Developer-Centricity vs Operations-Centricity?
Balancing the dynamics between development and security teams is also challenging for teams that want to integrate shift right and shift left approaches. With integration, questions arise about where responsibilities should lie and how to balance focus between development and operations functions.
- Developer-centric approaches empower developers to fully control the development lifecycle and its security. That comes with faster feedback cycles and time-to-market but can overburden developers with responsibilities, task them with security expertise, and leave them without support.
- Operations-centricity focuses on the health of the production environment. With a specialized team focusing on infrastructure and security, developers can focus on writing code. Scalability, reliability, and optimization aren’t developer concerns, which can lead to better production performance. The approach adds time to feedback loops and creates silos.
- Hybridity requires collaboration, role clarity, training challenges, and complex or comprehensive tools — and the expertise to make the best use of them. Yet it combines the benefits of both approaches and can be customized to an organization’s current workflow and departmental expertise and needs.
Tooling: DevOps Toolchain Fragmentation vs End-to-End Platforms?
As DevOps matures, integrating shift left and shift right security leads to questions about whether (and how) to integrate existing tools, consolidate with a comprehensive solution, or keep toolchains separate. The debate touches on issues of efficiency but also team collaboration, workflow, and flexibility.
- Toolchain fragmentation lets organizations integrate shift left and shift right while keeping best-of-breed solutions their teams know well. Tools are best suited to their specific requirements and to each phase in the development lifecycle. However, integration is more than managing two distinct tasks simultaneously and separately. Fragmentation can come with double the tool use, making extra work and overhead, along with higher resource allocation.
- End-to-end tooling brings lifecycle visibility but may lack the depth of specialized tools. Organizations reliant on a single platform must train multiple teams to use it, and some won’t find the specialized functionality they crave.
- Hybrid tooling brings visibility and complete security coverage to a unified platform with the depth of specialized tools – along with their costs, added tasks, and complexity. Leveraging APIs and integrations can help streamline functionality. However, organizations can still feel the hybrid approach falls short of the promise of integration.
Where Are We Heading?
Convergence between shift left and shift right is accelerating, as the goal is not just shifting processes earlier or later but creating a continuous feedback loop between development and operations, leveraging real-time data to improve both pre- and post-production efforts — and then managing the tsunami of data that comprehensive coverage brings.
First, logs, traces, metrics, scans, and tests mean a future where machine learning will integrate into most solutions, shifting debates to how we’ll manage added complexity, trust, audibility, and over-reliance on automation.
Second, as teams chase both security and efficiency, platform integration, automation, and policy-as-code practices, all stand to eclipse debates about shift left vs shift right, with more holistic DevSecOps solutions dominating and collaboration between teams as well as between humans and ML-driven tools.
Upwind Shifts Right to Find, So You Can Shift Left to Fix
Upwind’s comprehensive CNAPP embraces a shift right perspective to make insights at runtime simpler to integrate during future development processes. That allows teams to intelligently integrate security during the development process, without the overwhelm that comes from trying to “shift everywhere.”
Let us show you how shift right can secure applications at runtime — and lead to more secure development, too. Book a demo today.
FAQ
How do shift-left and shift-right security practices impact the SDLC?
Shift-left security empowers developers to integrate security directly into the coding and build stages of software development. It requires more time investment in the early stages of development, with developers trained on security tools. Extra steps upfront can also slow development, but can lead to fewer issues later on.
Shift-right shifts security to post-deployment. Insights gained from runtime threat feeds are fed back into earlier stages of the SDLC. For example, vulnerabilities identified during production could prompt changes in upcoming development cycles to fix issues or improve security controls.
How can organizations balance speed and agility with thorough security testing?
Risk-based prioritization, automation, and increasing use of machine learning to cut through the noise and keep teams focused on the right priorities are helping balance integrated approaches, filling security gaps without overwhelming security or development teams.
A dual approach that combines shift-left with shift-right doesn’t have to double the team’s workload. In fact, it can cut the noise significantly by highlighting vulnerabilities that are critical, integrating processes, and streamlining security.
What about continuous testing?
Continuous testing plays a key role in balancing a shift-left and shift-right approach to maximize both agility and security. Continuous testing integrates security checks (like DAST, SAST, and dependency scanning) into the CI/CD pipeline, ensuring every code change is automatically tested for vulnerabilities. That reduces manual testing efforts and reduces bottlenecks.
It also ensures testing isn’t just a one-time endeavor at a single phase in the SDLC, but runs consistently, throughout the entire pipeline. Automated, continuous testing provides a holistic approach without slowing down development teams.
