For years developers have been told to shift left, meaning that testing happens at the start of the software development process. The idea behind this is that it’s easier and more cost effective to find and fix an issue earlier on in an application’s life cycle.

However, Dylan Thomas, senior director of product engineering at OpenText Cybersecurity, believes that companies should be moving to a “shift everywhere” approach where testing doesn’t just happen at the beginning or the end, but is rather a continuous process. 

“In 2025, DevSecOps will continue evolving beyond the ‘shift-left’ paradigm, embracing a more mature ‘shift everywhere’ approach. This shift calls on organizations to apply the right tools at the right stages of the DevSecOps cycle, improving efficiency and effectiveness in security practices,” he predicted at the end of last year. 

Thomas was interviewed on the most recent episode of our podcast, What the Dev?, to talk more about this concept of shift everywhere and why it’s going to continue to take hold. Here is an edited and abridged version of that conversation:

SD TIMES: What do you mean by shift everywhere?

THOMAS: The way I like to think of it is with the DevSecOps process it’s meant to be this continuous process and to do so, we’ve really got to think about the overall end to end importance. That means looking everywhere in that whole process. It doesn’t mean just at the beginning or just the end or just at the middle. It’s taking this holistic view of saying, how do we become the most efficient and deliver high quality software at the highest level of efficiency throughout, and that means taking a staged approach throughout. And yeah, that’s really kind of what it means to apply shift everywhere. It’s about the right tool for the right job at the right time.

SD TIMES: So what’s the driver behind this transition away from shift left and to this shift everywhere approach?

THOMAS:  I think everybody’s probably seen some variant of the stat that shows, you know, it’s 40 times, or 100 times, or, you know, 10 million times more efficient and cost effective to fix something before it’s even conceived, right, compared to fixing and production. On the surface that’s very true, but I think that’s been taken out of context and kind of parroted in front of management, both by stakeholders in the organization, as well as by every single vendor out there as justification why their solution is the best and why you should buy my XYZ thing. And that just kind of perpetuated this concept of shift left is the way to do it. Everything should be done very early and very effectively. But what you start to realize as we look at why we’re evolving to shift everywhere, it’s that that just didn’t work, right? You were trying to force fit things that didn’t really belong there. Like, if I’m putting a new roof on a house, I’m not going to go in and take one piece of plywood and cut that and then put tar paper on it, and then put shingles on and then stick it on the roof before I put on the roof, right? I’m going to phase these things out, and I’m going to do them kind of one at a time, in a sequential order. And there’s nothing wrong with that, in many ways. What shift everywhere represents is kind of recognition of that. Instead of trying to do it all up front, let’s phase it out. Let’s take developers writing code in their IDE, and let’s think about what the requirements are to get the most efficient outcome out of that phase of the life cycle, right? Get the code written, focus on getting functionality. Don’t slow that down. Give very rapid, effective feedback and security. But then when we get to say, like, the pull request or a merge request, we’re trying to take our future preemption, bring it back in. When we’re doing reviews, we can then start to up the level of engagement. And then as we go into actually building, compiling our code, we can do a little bit more, right? And so we have this layered approach that rather than artificially creating work where it doesn’t belong, it just fits more seamlessly into the process.

SD TIMES: Would you say that there are specific tools or technologies or ways of working that are key to making shift everywhere a reality?

THOMAS: We’re seeing consolidation in the application development platform, largely around where the source code lives, and it’s becoming that hub of collaboration. And I think that’s been a really key empowerment capability to really unlock this. When you shift extremely left in the IDE environment, you’re almost isolated, right? So how do you collaborate when I’m off in my IDE with my head down, running code, then comes the point of coming back together is oftentimes like “oh, great, let me submit the PR.” Now other members of my team are going to start reviewing my code and commenting on it and giving me feedback, or approving to merge it in and so forth. So it’s a very natural point. It also allows us to integrate intelligence, be it security, performance, functional, you name it, right into the code directly. And that really shortens the feedback loop for engineering teams to take action on it. And that’s fantastic. And I think that’s been a key enabler.

SD TIMES: Do you have any advice for development teams who are looking to kind of get started with this approach?

THOMAS: I’d say there’s really a couple aspects I’ve seen that drive success. One of those is really partnering with security. So if we think about establishing shared goals and a non-adversarial relationship, hopefully at some point in the future, there’ll be this Nirvana where we have perfect security that’s instantaneous, with no false positives, and everybody is happy. But we’re not there. So, I think coming in and saying what’s important to me as the development or an engineering organization, what’s important to the security organization, and aligning those principles up front and having both kind of having a better kind of working relationship is key, otherwise you just kind of end up in an adversarial one. 

And I think the other one is about being pragmatic. There’s no such thing as perfect security, and so really, the intent of building security into the development life cycle is to kind of reduce risk in accordance with the business goals. So it’s like, what’s our milestone for getting better? You know, I’m gonna start this, I’m gonna roll out some new security tool, it’s gonna give me a lot of feedback. It’s not so much where I am today, but it’s, how do I incrementally get better, and do that in a way that’s balanced against the business value being delivered? And that’s going to be different for every organization, and oftentimes different teams within organizations.