Move over, DevSecOps: DevEx is the new darling

More than a decade after DevSecOps shook up the way software is developed securely, many organizations still struggle with the same old pain points that DevOps promised to solve for.

Organizational friction, intrusive security tools and processes, and torturous workflows continue to plague software teams. Longtime software engineering advocates believe that to really get DevSecOps to deliver optimal results, organizations need to refine their efforts: focusing on developer experience, or "DevEx."

Companies such as Toyota, Netflix, Etsy, Amazon, and Google are investing heavily in DevEx to not only deliver improved business results, but also introduce a more workable way to improve software security.

Here's what your organization needs to know about the shift 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?

DevEx is all about keeping talented developers happy and productive by getting rid of key roadblocks they face in their daily workflows, Garima Bajpai, a software engineering leader and DevSecOps advocate for Crowdbyte Solutions, said in a recent webinar. DevEx has tremendous overlap with those first principles that kicked off the DevSecOps movement — improving flow, feedback, and experimentation, she said.

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

Doing so isn’t just about making people happy. The ultimate goal is to boost developer output and improve financial outcomes. Data is starting to mount, showing these benefits can be significant. One of the most recent examples: Amazon, which has invested considerably in DevEx in recent years to increase developer velocity, and drive business value and financial results. In July, Amazon’s head of Software Builder Experience, Jim Haughwout, wrote in a blog post that the company's investment in DevEx 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 takes a ton of effort to execute in the real world. 

The reality is that only one in four developers today are truly happy with their current job. And the ever-present and toilsome nature of their work probably has a lot to do that. Recent studies show that at least half of developers today lose 10 or more hours of their work week to inefficiencies. Three in five developers report that their leadership doesn’t truly 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 that keeps organizations from ensuring that DevOps is synonymous with 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

One proof point comes from a recent study by Jit, which showed that 61% of developers admit that security is not a priority, or is only somewhat important to their development culture. Some of the top impediments to that cultural prioritization of security included the complexity of modern application architectures, followed by lack of knowledge, training, and guidelines. They also noted the lack of time and organizational priority — ultimately a lack of leadership support.

As one respondent of that report put it succinctly:

My organization prioritizes shipping as fast as possible over security.

What organization wouldn’t prioritize velocity if the choice between speed and security was binary? Shipping code makes money — and that’s what developers are there to help a business do. Which is why for years DevSecOps and application security (AppSec) advocates have been all about chasing the ideal of making it easier for developers to code securely at speed.

The problem: However security teams labeled these efforts — democratization of AppSec, shift left, or Secure by Design — the real-world execution often ends up adding more security responsibility to developers’ plates without really considering how it impacts their workflows or adds to their cognitive load, said Jason Chan, a former cybersecurity leader at Netflix and veteran AppSec advocate, in a recent retrospective 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 not to make people responsible for areas in which they are not experts. For example, developers are not security experts, he said.

Explaining why DevEx needs to be one of the most important elements of a software security, Chan said engineers are expensive and hard to hire, and you want them focusing on their domain expertise — which is how they 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 to use DevEx to bolster AppSec

There’s no easy path forward for using DevEx to boost software security outcomes, but there are best practices that leading businesses are using to move in the right direction. Here are some places experts suggest AppSec strategists should start with.

1. Build paved roads

Chan said one of the most important components to improving DevEx to support security in high-velocity engineering environments is the idea of 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

Embedding security earlier in the development lifecycle is crucial, but to make sure everything isn’t just heaped unceremoniously on the development team, organizations need to very thoughtfully build their DevSecOps roles. Hiring the right security people and establishing roles that are geared for creating paved roads starts with thoughtful workforce planning, said Crowdbyte Solutions's Bajpai. She recommends looking into established workforce frameworks to guide how the organization designs roles and workflows.

“I always start with people,” she 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

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 table stakes these days. But even more important is ensuring that alongside that visibility are the contextual cues and automations that make effective prioritization of issues as seamless as possible.

“Developers are put in the position on a daily basis of having to make decisions about which priorities to focus on. And so many times security just shows up with a whole big bunch of bad things to fix, but not always clarity on how to prioritize,” she says, explaining that this is not something that can be solved by tools. “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 around open-source code, DevSecOps teams can’t afford to take an ad hoc approach to open-source code management. This work is integral not only to software security, but also developer experience, Bajpai said.

“Start taking open-source seriously. Open-source is embedded in 80 to 90% of your developer code," she said. "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

One elephant in the room is AI coding. Whether you are a developer, security pro, DevSecOps lead, or a DevEx visionary, there’s no closing that Pandora’s box, Wong said. AI is coming, so development organizations need to ensure that they establish the policies and tooling that keeps their software team accountable to 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.