DevSecOps is an abbreviation open to different interpretations. You could view it as Security surrounded by the welcoming embrace of Development and Operations. Or you could look at it as Sec getting in the way, inhibiting the seamless productivity of Dev and Ops. It probably won’t surprise you that the latter view is still the dominant one.

For years, there have been ongoing efforts to get the three to play nicely together. To emphasize that they’re all on the same team, reaching for the same goal: To make software that does what it’s supposed to do (quality) and doesn’t do what it’s not supposed to do (security) with the help of tools and processes that decrease risks to businesses without slowing developers down.

The reason that’s so hard—and is still a topic at security conferences like RSA Conference—is that there are different pressures and incentives for those teams, and those incentives can clash.

For developers, the primary pressure/incentive is speed. Get it into production fast. Their mantra is: “We’d love to have security in our value stream if it doesn’t slow us down.” If it does slow them down—or they think it does—speed wins. Security testing that can’t keep pace with the ever-increasing velocity of development gets pushed to the side or ignored. But it doesn’t have to be that way—really. The software security industry is making progress in heeding the long-time exhortation to “make the secure way the easy way.” That doesn’t mean the journey to making it easy takes no effort or investment. If security is creating friction, there are multiple possible reasons, and they all need to be addressed.

It could be tool overload—too many tools with some of them doing the same thing. The Enterprise Strategy Group (ESG) reported last year that organizations, on average, run 25 to 49 security tools from up to 10 different vendors. This doesn’t mean security testing tools are bad or that only one tool is good. But there is such a thing as too many good things.

It could also be that testing tools aren’t configured to conduct the right tests at the right time and to flag only significant defects. That can create the dreaded “friction” and end up undermining security. It’s known as “tool sprawl,” and analysts like 451 Research have noted that as many as 40% of organizations admit that their development teams are overwhelmed by security alerts. Indeed, when those alerts are constant, they become background “noise” and are ignored—the exact opposite of the intent. Larry Ponemon, President of the Ponemon Institute, has said of tool sprawl that “So many things are generating reports [and alerts] … you are in a state of information overload pretty quickly.”

There is no magic button that will solve all those problems. It takes “people, process, and technology.” But on the technology front, Application Security Orchestration and Correlation (ASOC) can help make the secure way the easy way. ASOC improves on yet another security mantra—to “shift left,” meaning doing security testing earlier in the software development lifecycle (SDLC). While that is much better than leaving everything to the end, it is even better to “shift everywhere,” doing the right test with the right tool at the right time, no matter where it is in the SDLC.

A good ASOC tool will do five major things that, collectively, can help build integrity into your software while keeping up with the accelerated pace of development:

Execute tests: It will run the right tests at the right time using whatever tools an organization has—it’s tool-agnostic. Orchestration means configuring it to suit the types of applications being tested and the needs of the organization.

Correlate results: That means “normalizing” the different formats and nomenclatures of multiple testing tools into a single nomenclature, matching them to eliminate redundancies, and then combining and aggregating them into a superset of results.

Prioritize: Users can configure an ASOC tool to flag the critical and ignore the trivial.

Track remediation: It will scan all the correlated and prioritized results, take the highest-priority defect findings, and automatically open tickets in a defect tracker like Jira, Bugzilla, or Backlog. It will then verify when a defect has been corrected and automatically close the ticket.

Centralized platform: Commonly called the “single pane of glass,” it means an analyst doesn’t need to check each individual tool to see what problems exist and what has been done about them. It makes ASOC an AppSec system of record.

It also lets security executives like CISOs answer fundamental questions about testing, including what defects were found and whether they were fixed. In short, for DevSecOps to build trust into software, the security component must be an enabler, not a hurdle.