Shift Left Shifted the Blame

“Shift left” promised to make applications more secure by identifying vulnerabilities earlier in the development process. Find problems before production, reduce remediation costs and make security part of software design rather than a final checkpoint.

The principle is sound. Its execution often is not. In many organisations, shifting security left has meant handing developers another collection of tools, alerts and responsibilities. They are expected to deliver features quickly, keep services available, manage dependencies, fix vulnerabilities and understand an increasingly complex threat landscape. Security has moved closer to development, but the time, expertise and authority needed to manage it have not always followed.

The result is predictable. Developers receive large volumes of findings, many with limited context or questionable relevance. Security teams can point to tools embedded within the pipeline. Leadership can say secure development is in place. Meanwhile, serious issues compete against commercial deadlines, technical debt and an endless backlog of product work.

Security has technically shifted left. Accountability has simply shifted down

There is also a wider problem. Application risk is rarely created by code alone. Architecture, access controls, third-party components, cloud configuration and business decisions all influence whether an application is secure. A developer cannot compensate for an unrealistic release schedule, an unsupported dependency or a decision to accept risk in order to meet a customer commitment.

Yet when something goes wrong, the question is often: why did development allow this through?

A credible shift-left strategy should help developers make better decisions, not turn them into part-time security analysts. Automated testing should remove noise, prioritise exploitable risks and provide clear remediation guidance. Security specialists should remain involved in threat modelling, architecture and high-risk decisions. Most importantly, the business must recognise that secure development requires time.

There is value in finding vulnerabilities earlier. There is far less value in finding them earlier and leaving them unresolved because delivery targets take precedence.

Perhaps security also needs to “shift right”: validating how applications behave in production, monitoring real attack paths and learning from how software is actually used. Development pipelines cannot predict everything that will happen in a live environment.

Shift left should be a shared operating model, not a transfer of liability. If developers receive all the responsibility but none of the power to delay an unsafe release, the organisation has not embedded security.

It has simply found someone new to blame.