DEVOPSdigest

Software development teams are driven by speed. Yes, they care about quality and features, but the real pressure is to move fast — faster than the competition.

Security teams are driven by exactly what their title says — security.

Both of which are good and necessary things to deliver what the market wants: Quality products that are the latest and greatest and aren't littered with vulnerabilities that can put users at risk.

But those very different, and often competing, pressures make it difficult for those teams to find common ground. Developers frequently view the security team as an obstacle — the people who slow them down. Security teams tend to view developers as in too much of a rush to care if what they deliver to the market can be easily hacked.

Add to that the reality that many security teams don't understand modern application development practices, including the move to microservices-driven architectures and the use of containers, and the divide gets even wider.

To look more deeply into the specifics of this divide, Synopsys commissioned IT analyst and research firm Enterprise Strategy Group (ESG) to document the dynamics between development and security teams regarding deployment and management of AppSec solutions.

That report, Modern Application Development Security, polled 378 qualified respondents in cybersecurity and application development. They represented several industries including manufacturing, financial services, construction/engineering, and business services, throughout the US and Canada.

And among its key findings was that when there is a contest between speed and security, speed wins. Nearly half (48%) of respondents reported that their organizations knowingly deploy vulnerable code to production due to time pressures.

That finding deserves some context — it doesn't mean organizations and their development teams don't care about security.

First, there is no way to deploy perfect code. So the reality is that while 48% admit to deploying vulnerable code, everybody is doing it some of the time. And that is not always a bad thing. As a recent Gartner paper on DevSecOps put it, "Perfect security and zero risk are impossible." Which means that trying to make code perfect would mean never deploying anything.

Or, as ESG put it, "Application security requires a constant triage of potential risks … that allow development teams to mitigate risk while still meeting key deadlines for delivery."

However, there is a difference between setting priorities — knowingly letting some lower-risk defects remain — and failing to find more significant vulnerabilities until it is so late in the SDLC that they don't get addressed.

And that is obviously happening. A majority (60%) acknowledged production application exploits involving OWASP Top 10 vulnerabilities in the past 12 months.

To address that problem takes both people and technology, the report found.

The people part is not a new problem. And what is encouraging is that it is getting lots of attention. Tanya Janca, now founder and security trainer at We Hack Purple Academy but at the time a senior cloud developer advocate for Microsoft, spoke about it more than a year ago at the 2019 RSA conference in San Francisco.

In a presentation titled Security Learns to Sprint: DevSecOps, she said a main reason security isn't more of a core element of the software development life cycle (SDLC) is because development and security teams tend to view one another not just with suspicion, but sometimes outright hostility.

This year, RSA featured an entire day of sessions on how to make DevSecOps teams function more cooperatively and effectively.

But cooperation usually takes understanding. And the less encouraging news is that there is still an understanding gap, in part because of a lack of basic training in security.

Go to New Report: Speed and Security Are Both Possible in Software Development - Part 2