Say “DevSecOps” to people in the software industry, and the image that comes to mind will probably depend on what they do. 

For those on application security teams, the likely image is of security as an enabler—joining development and operations to build software that does what it’s supposed to do (quality) and is free of vulnerabilities that hackers could exploit to make it do what it’s not supposed to do (security). 

But for development and operations teams, security is too frequently viewed as an obstacle, creating friction that undermines their top priority—speed. As in, you can have security or speed, but not both.

This is not a new conflict. For years, a prime topic at cybersecurity conferences has been how to help those teams play nicely together to achieve a common goal: quality software that can be trusted, and also gets to the market in time to beat the competition.

While those efforts have led to improvements, the reality is that tension remains, and speed is still king. The 2020 “Building Security in Maturity Model” (BSIMM) report by Synopsys documented the message from developers: “We’d love to have security in our value streams if you don’t slow us down.”

Security vendors have responded with automated tools that are much faster than manual testing, but what used to seem fast is now viewed as intolerably slow, thanks to technology like continuous delivery pipelines. And velocity is expected to spike again with the use of generative artificial intelligence tools to write code.

As Jason Schmitt, general manager of the Synopsys Software Integrity Group, put it, there is a “constant debate about where we are on that [security vs. speed] continuum.” 

But he also said that it doesn’t have to be a zero-sum game where security or speed loses, noting that the tension between speed and security has led to “two changes that are important and positive.”

One is that the pressure for speed is “forcing innovation in the security vendor landscape, raising the bar on automation that doesn't compromise security and also meets the needs of modern development.”

The other, he said, is increased awareness that effective security at the speed of today’s development takes more than tools or mandates—it requires “meeting developers where they are, working very meaningfully with them from the beginning of everything they’re trying to do.”

That, he said, is happening in the DevSecOps world through automation that acknowledges the priorities of DevOps teams by providing the security information they need without slowing them down. “But it’s a cultural shift that makes the change really happen,” he said.

One part of that cultural shift is getting Dev and Ops teams more involved in security—the BSIMM report has noted for years that organizations with mature software security initiatives have recruited and trained volunteer “security champions” from Dev and Ops teams.

That doesn’t mean a shift of responsibility—the security team still owns security, and the prime incentive for developers is still speed. But that collaboration helps achieve both security and speed.

Some bumps in the road remain. One trend aimed at easing the conflict is the increase in development platforms that add “lightweight” security testing features designed to prioritize speed, simplicity and ease of use. 

That sounds irresistibly tempting, and there’s nothing inherently wrong with lightweight security tools. But it’s important not to let them give you a false sense of comprehensive security. Because those tools’ capabilities are lightweight as well—they catch vulnerabilities that are relatively minor and easy to find, but they aren’t so good at detecting more sophisticated and dangerous defects.

“To find a complex memory overflow, cross-site scripting, or SQL injection [issue] across seven architectural tiers of a large application of 10 million lines of code is simply not possible in a quick and easy scan,” Schmitt said.

That means good software development needs a mix of lightweight and heavy duty testing. And the challenge for the security industry is to make those more sophisticated tools just as fast as the simpler ones. 

“That's where the true innovation has to happen—and is happening,” Schmitt said. “You've got to be able to find the hard stuff but still meet those speed requirements.”

That takes a team effort—Dev, Sec and Ops. But done right, there’s no need to choose speed or security. Both are possible—and necessary.

For more information on how Synopsys can help you crack the code for DevSecOps visit www.synopsys.com/software.