If Shift Left worked for software testing and the technology stack in DevOps, it would surely work for security, too, right? Developers could take ownership of application security just as they had with software packaging, infrastructure planning, and functional testing under DevOps. At first glance, this comparison seemed appropriate, and “shift left” quickly gained traction as the key solution to the DevSecOps challenge – integrating security testing earlier in the software development lifecycle.

However, serious challenges soon emerged.

Developers began voicing frustration when security testing tools were abruptly inserted into DevOps-style continuous integration pipelines. These tools – mostly legacy scanners like SAST, DAST, and SCA – that had previously been used asynchronously to test software assets were now being forced into the fast-paced, synchronous environment of modern software orchestration.

The result? Cumbersome integrations, painfully long build and test times, and unexplained blocking failures quickly became the norm. This created a negative perception of security among an entire generation of engineers – even as they eagerly embraced containerization, infrastructure-as-code, and automated testing.

Looking back, it’s clear why this adoption gap emerged. The technical responsibilities that have been successfully shifted left with DevOps – and gained trust within engineering teams – share a few key characteristics: 

The long-term developer effort required for implementation is sustainable.

There is a high positive impact on developer velocity, productivity, and job satisfaction.

All of the relevant context to perform the task is accessible to the developer.

The task can be effectively self-serviced, expressed “as code,” and made immutable (built once and consistently executed).

The task cannot be efficiently performed “on the right.”

Unlike unit testing or packaging in containers, simply bolting on traditional application security tools to DevOps processes.

fails all of these criteria:

Developer effort is unpredictable and unsustainable, with priorities generally defined outside the engineering organization. Productivity almost always decreases as vulnerabilities are found.

Developers lack the required context to understand and accurately assess, let alone remediate, issues found within their workflows.

Even the most modern security tools cannot be fully self-serviced by individual engineering teams.

Every organization still performs additional security testing after the fact (pen-testing, runtime scanning, audits).

Put another way, security testing is not in the natural critical path of building modern software. Engineers can easily prioritize speed and meet their goals without ever addressing security. DevSecOps tried to change this by artificially forcing security into the development pipeline, but in doing so, it overlooked the significant friction this would create in the overall developer experience.