Move over, DevSecOps — DevEx is the new darling

More than a decade after DevSecOps shook up the way software is developed, many organizations still struggle to find the best way to get that “Sec” into DevOps.

Security teams remain at odds with development teams, with complaints from the latter about organizational friction, intrusive security tools and processes, and torturous workflows. Now, many longtime software engineering advocates are saying that for DevSecOps to really deliver optimal results, organizations will have to focus on developer experience, or DevEx.

Companies including Toyota, Netflix, Etsy, Amazon, and Google are investing heavily in DevEx, hoping that it will both deliver improved business results and introduce a more workable way to improve software security.

Here's what your organization needs to know about upgrading from DevSecOps to DevEx — and how to best get started on making the switch.

Download Today: The 2025 Software Supply Chain Security Report

What makes DevEx different than DevSecOps?

In a recent webinar, Garima Bajpai, a software engineering leader and DevSecOps advocate for Crowdbytes Solutions, said that the goal of DevEx is to keep talented developers happy and productive by getting rid of the roadblocks they face in their daily workflows. DevEx, she added, has a lot of overlap with the first principles that kicked off the DevSecOps movement: improving flow, feedback, and experimentation.

If you want to connect the [DevSecOps] dots with DevEx you can focus a lot on flow. DevEx creates a joyful environment for developers by creating seamless, efficient, and enjoyable workflows.

Garima Bajpai

You want happy developers, she said, because that will boost developer output and improve financial outcomes. And the companies promoting DevEx are claiming to see results. In July, Amazon’s head of software builder experience, Jim Haughwout, wrote in a blog post that the company's investment in DevEx had helped it reduce software delivery costs by 15.9% in 2024.

Particularly important to us is giving developers back their most valuable resource — time. Developers come to Amazon to build and deliver software for customers. Maximizing their ability to do so offers concrete returns for the business. Our improvements to reduce cost to serve (CTS) gave developers that time and reduced toilsome work.

Jim Haughwout

DevEx is a simple enough concept — but it takes a ton of effort to execute it in the real world. 

One survey found that only one in four developers is truly happy with their current job. “Toilsome work” probably has a lot to do with it. Recent studies show that at least half of developers lose 10 or more hours of their workweek to inefficiencies. And about 60% of developers report that their leadership doesn’t understand the friction that stands in the way of peak productivity. These friction points can originate from broken processes or fragmented workflows. One key area of concern: burdensome security tasks.

What’s DevEx got to do with security?

DevEx is now seen as the missing piece of DevSecOps, said Caroline Wong, director of cybersecurity at Teradata, in a recent webinar.

I really want DevOps and DevSecOps to be and mean the same thing. I really just want it to be such that security is so embedded, so invisible or so easy or so fun that it's just included. I don't think we're there yet in the majority of cases.

Caroline Wong

A recent study by Jit suggests that Wong is right, with 61% of developers admitting that security is not a priority or is only somewhat important to their development culture. Some of the leading impediments to the cultural prioritization of security cited were the complexity of modern application architectures and a lack of knowledge, training, and guidelines. Respondents also said they need more time and more leadership support.

One respondent put it succinctly:

My organization prioritizes shipping as fast as possible over security.

And what organization wouldn’t prioritize velocity if the choice between speed and security were binary? Shipping code makes money — and that’s what developers are supposed to help a business do. Which is why for years DevSecOps and application security (AppSec) advocates have been chasing the ideal: developers can smoothly code securely and at speed.

But although these efforts wore many labels — democratization of AppSec, shift left, Secure by Design — they all added more security responsibility to developers’ plates without considering how that would impact their workflow or add to their cognitive load, said Jason Chan, a former cybersecurity leader at Netflix and a veteran AppSec advocate, in a recent retrospective talk on his track record of securing software at velocity.

This is really the essence of security in high velocity engineering environments — we as security teams have to make the investments culturally and technically to allow engineers to focus and spend time in their areas of expertise.

Jason Chan

Chan said the core principle of his leadership philosophy is to not make people responsible for things outside of their expertise. For developers, that includes security, he said.

Chan said that DevEx needs to be one of the most important elements of an AppSec program because engineers are expensive and hard to hire, and you want them focusing on their domain expertise so they can bring value to the business.

The failure mode for not aligning with developer experience and productivity? Your developers will hate you and find ways to avoid engaging with you.

Jason Chan

Teradata's Wong said she believes that one of the biggest issues isn’t just streamlining routine testing to boost velocity, but also thinking very critically about how unplanned security work breaks those routines down.

Part of improving that developer experience is understanding that devs really don't want to do unplanned work, and they really don't want to do rework. Maybe the most important question to ask is ‘Is security in DevOps creating or reducing unplanned work or rework?

Caroline Wong

5 tips for using DevEx to bolster AppSec

There’s no easy DevEx path to follow, but there are key best practices that leading businesses are using to move in the right direction. Here are some places where experts suggest AppSec strategists should start.

1. Build paved roads

For Chan, the path will be smoother if it’s a paved road. “In the context of engineering, a paved road is a collection of well-supported, optional solutions for common problems, and these solutions are provided and supported by central teams,” he said. “Optionality is a key part of a paved road — if the solutions were required, then we would just refer to them as requirements.”

2. Engage in thoughtful workforce planning

Shift left and Secure by Design are correct in their view that embedding security earlier in the development lifecycle is crucial, but that shouldn’t mean heaping everything on the development team, said Crowdbytes Solutions' Bajpai. Hiring the right security people and establishing roles that are geared toward creating paved roads starts with thoughtful workforce planning, she said. She recommends looking into established workforce frameworks to guide how the organization designs roles and workflows.

“I always start with people,” Bajpai said, recommending that leaders lean on a growing body of industry guidance to help them on this front. “Look at NICE, for example, as a workforce planning framework which advocates for the skills, the roles, the initiatives you have to put in place in order to ensure that security is considered to be the integral part of DevOps.”

3. Prioritize visibility

Teradata’s Wong said security people must get better about when, where, and how they share the outputs of security tooling with developers. Embedding technology into development tools is merely table stakes these days, she said. More important is ensuring that visibility is accompanied by the contextual cues and automations that make effective prioritization of issues as seamless as possible.

Developers have to make decisions every day about priorities, she said, but many times “security just shows up with a whole big bunch of bad things to fix but not always clarity on how to prioritize.” This is not something that can be solved by tools, Wong said. “It’s important not to lose sight of those really important human-to-human communications.”

4. Open-source excellence is key

With the bulk of development work centered on open source code, DevSecOps teams can’t afford an ad hoc approach to open source code management. This work is integral not only to software security, but also to DevEx, Bajpai said.

“Start taking open source seriously," she said. "Open source is embedded in 80% to 90% of your developer code. So you'll have to have some kind of focus on strategic investments and how you improve open-source posture from both the developers’ and security practitioners’ points of view.”

5. Solve the AI puzzle

A further complication is AI coding, which is rapidly being adopted regardless of unaddressed security issues. AI is coming, Wong said, so development organizations need to ensure that they establish the policies and tooling that keeps their software team accountable for the actions and decisions made.

“We can use AI to help us do our jobs, but at the end of the day we are still accountable for the decisions we make and outcomes we produce, even if we got there using some kind of automation," Wong said.