Developers and security professionals are often in conflict, and this state of affairs is not going to change anytime soon, in this author’s opinion. Now here are some facts about the current state of affairs.
The Ponemon Institute conducted two surveys sponsored by ZeroNorth in May and June of 2020, one of 581 application security (AppSec) professionals and another of 549 application developers. Three-quarters of the AppSec respondents believe there is a cultural divide between them and developers, while only 49% of developers feel the same way towards the AppSec function. The difference in opinion is not because DevSecOps is more likely to have taken hold among developers — adoption is almost the same among both respondent categories.
Almost half (48%) of developers have bought into the idea that their organization is actively working to help developers and security teams work together. At 32%, AppSec is more skeptical. One has to wonder, is this because corporate leadership isn’t doing anything, or are security pros jaded by past experience? Developers are more optimistic about a raft of other security topics, most notably application vulnerabilities.
As compared to AppSec professionals, developers are significantly less (39% vs 60%), to believe application security risk at their organization has increased. At the core of the matter, AppSec professionals think the development team is difficult to work with because they push code with known vulnerabilities, with many also complaining that developers accept flaws if they believe an app will be a big seller. Whether or not developers are actually pushing a lot of serious vulnerabilities up for debate, but their self-perception is incredibly different from that of their AppSec peers — only 27% of developers say code is frequently being published with known vulnerabilities, compared to the 57% of application security specialists that estimate likewise.
Developers think AppSec is just as difficult to work with, but this doesn’t actually seem to be as big of a problem for them. They chiefly complain about a lack of understanding about their need to meet deadlines and create innovative new products at the same time. When they are frustrated by the security team’s processes, they just circumvent them, if possible, temporarily.
A year ago, Puppet and “2019 State of DevOps Report” demonstrated that the integration of security into the software development lifecycle has been difficult for security professionals, especially in the middle stages of DevOps maturity. A year later, and the pain continues. The consensus that shifting security efforts left, earlier in the development lifecycle, is helpful, but this approach alone is not a panacea. Neither is buying and setting up testing, no matter how sophisticated the salesman tells you the technology is. But even if throwing money at the problem were feasible, AppSec is more than 25% more likely to say insufficient budget constrains the effectiveness of the organization’s application security posture.
And here comes the final rub. Security pros give developers credit for caring, as 81% feel that the development function has at least some responsibility for security. However, this report re-confirms yet again that although developers have some responsibility for security, the buck stops with the security team. Two-thirds (67%) of AppSec respondents think the security team is ultimately responsible for the security of applications as compared to only 39% of developers. Developers whine about Security slowing them down, but in reality, AppSec is just a nuisance to them.
The solution to this ongoing mess is not more leadership efforts to get people to understand each others’ points of view. Nor is it strict enforcement of top-level mandates. Instead, it is an agreement between the two communities about two-four common metrics that can be used to benchmark success. Without this basic step, we will be stuck bickering about how many, how frequently and how severe are vulnerabilities popping up applications around the world.
Feature image via Wikimedia.