This article is based on an interview originally published by TechRepublic, in which Karen Roby spoke with Matt Rose, Global Manager of Application Security at Checkmarx, about the evolution of DevOps and whether “shift left” remains the right mental model for application security.
The ‘Shift Left’ Premise — and Why It’s Being Questioned
“Shift left” has been a guiding principle in DevOps and DevSecOps for years. The idea is straightforward: move security testing and quality assurance earlier in the software development life cycle (SDLC), catching defects and vulnerabilities before they become expensive to fix. Depicted on a traditional SDLC diagram — which flows linearly from planning through development, testing, deployment, and maintenance — shifting left means pulling security activities toward the planning and development phases rather than treating them as a gate at the end.
But Matt Rose argues that this model is rooted in an outdated picture of how software is actually built today.
The SDLC Is No Longer a Straight Line
Traditional SDLC diagrams present software development as a linear process with a clear beginning and end. Shift left makes intuitive sense in that context: earlier is better, so move everything you can to the left of the timeline.
The problem, as Rose explains it, is that mature DevOps practices have fundamentally changed the shape of that process. Modern pipelines are not linear — they are continuous loops. With microservices architectures, containerisation, and CI/CD toolchains, large organisations may execute hundreds or even thousands of builds per day. There is no discrete “start” and “finish” that anchors a left or right side of the diagram.
“With the adoption and the maturation of DevOps, it’s now an infinite loop that’s constantly moving. So there really isn’t a left or right anymore — there’s just the process.”
— Matt Rose, Checkmarx
Rose is careful to say he is not declaring shift left dead. His point is more nuanced: in a continuous delivery environment, the concept needs to be repurposed. Rather than using “left” as shorthand for “identification” of security issues, he argues the early stages of a DevOps loop should be focused on remediation and verification — fixing known problems and confirming fixes hold — while the continuous integration phase in the middle of the loop is where security tooling should be automated and embedded as standard practice.
How Delivery Speed Changes the Security Training Problem
The shift from monthly releases to continuous deployment does more than challenge the geometry of shift left — it also exposes a gap in how application security training is delivered to developers.
Traditional security training follows a classroom model: developers attend an all-day or week-long course, absorb a large volume of material out of context, and then try to apply it back in their daily work. Rose argues this model fails for two reasons:
- Out-of-band delivery: Training delivered away from the actual codebase and toolchain is difficult to retain and apply. The context gap between “what I learned in the classroom” and “the specific vulnerability in this pull request” is too wide.
- Pace mismatch: When a developer needs to fix a security issue flagged during a CI pipeline run, they need concise, actionable guidance — not a reminder to recall something from a course they attended six months ago.
The alternative Rose describes is modular, in-context remediation guidance: when a vulnerability is identified, the developer receives structured, digestible instructions for fixing that specific class of issue at that moment in their workflow. This approach aligns security education with the speed and granularity of modern DevOps rather than fighting against it.
The Acronym Problem: DevOps, DevSecOps, and the Misuse of ‘Agile’
Rose also raises a concern that many practitioners in the field will recognise: the proliferation of DevOps-adjacent terminology — DevSecOps, SecDevOps, CI, CD, continuous integration, continuous delivery, continuous deployment — is generating confusion, not clarity. Terms are frequently misused or deployed as signals of credibility rather than precise descriptions of practice.
His most pointed example is the word “agile.” Rose draws a deliberate distinction between two uses of the word:
- Agile as an adjective/verb: The general quality of being flexible and responsive — able to pivot quickly to meet changing customer or business requirements. This is a desirable trait in any team or organisation.
- Agile as a proper noun: The specific software development methodology defined by the Agile Manifesto, with its own practices, ceremonies, roles, and terminology (sprints, backlogs, retrospectives, and so on).
When someone says “we use agile DevOps,” they may mean either — or neither. Rose’s argument is that the conflation of these two meanings leads organisations to adopt terminology without genuine understanding of the underlying practices, which in turn leads to half-implemented processes and missed outcomes.
Practical Takeaways for DevOps and DevSecOps Teams
The core arguments in this conversation point to several actionable considerations for engineering and security teams:
- Audit your mental model of the SDLC. If your team still thinks of development as a linear pipeline with a defined start and end, the shift left framing may be misleading your security strategy. Map your actual delivery loop and identify where security checks are genuinely embedded versus bolted on.
- Separate identification from remediation. Security scanning in CI is valuable, but flagging vulnerabilities is only half the work. Invest in tooling and processes that make remediation fast and contextual — ideally surfacing fix guidance inside the IDE or the pull request workflow.
- Replace bulk security training with just-in-time learning. Complement periodic classroom or e-learning programmes with targeted, in-workflow guidance tied to real findings in real code.
- Define your terms before you use them. Before your organisation adopts a new acronym or methodology label, confirm that the people using it share a common understanding of what it means in practice. Ask: which specific Agile ceremonies do we run? What exactly does “continuous deployment” mean for our release process?
- Automate security in CI as the foundation. According to Rose, the continuous integration phase is the engine of a mature DevSecOps programme — the point at which security tooling should run automatically on every change, producing fast feedback that feeds both verification and remediation workflows.
Bottom Line
“Shift left” remains a useful principle, but it was conceived for a linear view of software delivery that many mature DevOps organisations have already moved beyond. As pipelines become continuous loops running at high velocity, the more useful questions are: where in the loop is security automated? Where does remediation guidance reach the developer? And do the people involved in the process genuinely understand what the words they are using actually mean?
Getting those fundamentals right matters more than adopting the right acronym.
Source: TechRepublic interview with Matt Rose, Checkmarx, conducted by Karen Roby (originally published 2019).