It’s been said before—long before. It’s the 18th-century philosopher Voltaire who gets credit for the timeless proverb “Perfect is the enemy of good.”
But here we are, centuries later, and it’s still relevant—in this case to modern software development. If you try to make software perfect, not only will you fail at that, but you’ll also fail to get a product out the door.
To do what’s good while actually getting things done requires setting priorities: Fix the biggest problems, eliminate the worst threats, and get the product to market. That’s what DevSecOps, done right, can do.
But doing it right—embedding security into development and operations—hasn’t been easy. It still isn’t. DevOps teams still too frequently view the security team as a drag on their top priority—speed. They figure it’s security or speed, but not both.
That’s the case even after more than a decade of efforts to enable security at the speed of development. The 2020 RSA Conference in San Francisco featured a day of keynotes, panel discussions, and workshops on how to do DevSecOps better, and the bulk of them focused on what has become a mantra: To get DevOps teams to build secure software, make the secure way the easier and faster way.
That same year, 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.”
The security industry has made continued progress in that area. Automated application security testing (AST) tools are now standard. They are much faster than manual testing and flag defects while code is being created, rather than at the end of the software development life cycle (SDLC).
But tension remains because the goalposts keep moving. What used to seem fast is now viewed as intolerably slow, thanks to technology like continuous delivery pipelines. Velocity is expected to spike again with the increasing use of generative artificial intelligence tools to write code.
As Jason Schmitt, general manager of the Synopsys Software Integrity Group, put it recently, there is a “constant debate about where we are on that [security vs. speed] continuum.”
But the encouraging news is that there is also a continuing drive within the security industry to eliminate the perception that it’s a zero-sum game, where one side or the other has to lose, and software users lose as well.
Indeed, it’s important to get DevSecOps right. Security can’t be an afterthought in a world where a lack of it can enable cybercriminals to inflict a list of horrors on their victims—stolen identity, fraudulent purchases with stolen credit cards, looted bank accounts, theft of intellectual property, and compromised personal and financial data. And yes, millions are spent to pay ransomware attackers.
Schmitt sees two promising trends toward making security and speed a win-win. One is continuing innovation in automated tools that are fast enough to keep up with the hyperdrive pace of modern development. The other is a culture shift in which Security teams work with Dev and Ops from the beginning of a project.
Steven Zimmerman, DevOps security solutions manager with the Synopsys Software Integrity Group, referred to that cultural shift in a recent AppSec Decoded video interview, noting that successful DevSecOps requires cross-functional team interaction starting at the planning and strategy level—training development teams but also understanding their priorities. “It’s an organizational alignment,” he said, “where everybody has a seat at the table.”
Indeed, the BSIMM report has noted for years that organizations have boosted the maturity of their software security initiatives by recruiting and training volunteer “security champions” from Dev and Ops teams.
That doesn’t mean a shift of responsibility—the security team still owns security, and speed remains the prime pressure on developers. But that kind of collaboration helps achieve both security and speed.
Another enabler of security at speed is to set priorities. If developers are constantly bombarded with notifications about trivial defects, they’ll become overwhelmed with the “noise” and ignore them all, which degrades security. Or, if they are forced to deal with them all, it can grind development to a halt.
However, automated tools can be configured to reflect the priorities of an organization. Internal applications that never face the public internet don’t need the same level of testing that external apps do. Business-critical applications need more attention than those that aren’t.
“We need to get relevant information to our Dev and DevOps teams that help them identify the most pressing issues to fix,” Zimmerman said, “and give them the information that helps them make the fix.”
Limiting AST notifications to what’s most important to fix “can accelerate risk detection and avoid clogging that DevSecOps pipeline,” Zimmerman said.
One word of caution: One of the more recent trends in DevSecOps is development platforms that offer “lightweight” security testing features designed to prioritize speed, simplicity, and ease of use.
There’s nothing wrong with lightweight security tools. But it’s important to know their limits. Don’t let them give you a false sense of comprehensive security, because their capabilities are lightweight as well. They catch simpler, relatively minor vulnerabilities that are easy to find, but they aren’t so good at detecting more sophisticated, dangerous defects like cross-site scripting or SQL injection in large application with millions of lines of code.
Reliable software development needs both lightweight and heavy-duty testing. That means the obvious challenge for the security industry is to make the more sophisticated tools just as fast as the simpler ones.
To do that takes teamwork—strategy and planning with people, tools, and platforms working together. It isn’t mainstream yet, but it’s possible. So don’t give up on either speed or security. Both are possible and necessary.
For more information on how Synopsys can help build trust in your software, visit www.synopsys.com/software.
