[DZone Research] Developers as Security Professionals

This article is part of the Key Research Findings from the 2018 DZone Guide to Security: Defending Your Code.

Devs and Sec

Over the last several years, we’ve witnessed a large push among the developer community for security to shift left in the SDLC. The statistics from this year's DZone Security Survey show the effectiveness of this trend. When asked who should take primary responsibility for security, 42% of respondents said developers, 31% said security teams, and 15% said the frameworks themselves. Of the respondents who answered this question, 35% currently work as developers/engineers. Of that 35% currently employed in developer roles, almost half (41%) told us they believe developers should be primarily responsible for security. Additionally, 53% of developer team leads reported that developers should be primarily responsible for security. These are both promising trends in the field of application security.

Security Training

A core part of the shift left movement in application security is not only increasing concern for security among developers but providing developers with the necessary training and resources to learn secure coding practices. Taking a historical look at security training data, we can see some positive signs. In the 2017 and 2018 DZone Security Surveys, we asked how frequently developers at our respondents’ organizations received security training. Here’s how their answers broke down:

• Ad-hoc:
  • 2017: 37%
  • 2018: 33%
• Never:
  • 2017: 27%
  • 2018: 25%
• Yearly:
  • 2017: 16%
  • 2018: 15%
• Semi-annually:
  • 2017: 12%
  • 2018: 13%
• Quarterly:
  • 2017: 9%
  • 2018: 15%

The increase in quarterly security training proved quite substantial and is inversely proportional to the percentage of developers reporting that they receive security training on an ad-hoc basis or no training at all. While ad-hoc or no security training remain the two largest categories reported by our respondents, the decrease in their instances over a year, and the marked jump in quarterly trainings, is a positive sign for the industry.

Security Still Consistently an Afterthought

While security has certainly become a greater concern for developers in recent years, it continues to be outweighed by performance concerns. 37% of respondents said that their organization views performance as the largest priority, while 31% reported that security is their organization’s most important concern. In addition to performance, releasing software on schedule often overrides security issues. Approximately half of this year's respondents (51%) reported allowing release schedules to interfere with security concerns on an at least semi-regular basis. To take a more granular look, 34% said release schedules “sometimes” interfere with security, 11% reported “often,” and 6% reported it happens “all the time.” In fact, only 10% of this year’s survey takers told us that releasing on schedule never overrides security concerns; and an additional 25% said it rarely happens.

So, what happens when a vulnerability slips through the cracks? 83% of respondents told us they inform customers of potential known vulnerabilities that got shipped in their software. While we’d all like to see this number at 100%, it’s still a marked increase from 2017, when only 67% of respondents reported informing customers of potential vulnerabilities in their solutions.

Conclusion: Security Makes Cents

One of the major reasons for security continuing to lag behind performance concerns and release schedules is business value. As the above statistics show, releasing software on schedule that works as advertised still dominates the way organizations think about product releases. A study by the Aberdeen Group, however, shows that more up-front investment in security significantly reduces the cost of application development. For the organizations the Aberdeen Group considered "best-in-class," the calculated "annual cost of application security-related incident not avoided" (emphasis theirs), is $1.18 million USD, whereas the "total annual cost of application security initiatives (includes all related costs for people, process, and technologies)," came out to $350,000. That's quite a gap, and its only gets bigger the less prepared an organization is to deal with "security-related incidents." 

Taking these numbers into account, we can see why developer involvement and organizational investment in security is increasing. Hopefully, this trend t will continue. 

This article is part of the Key Research Findings from the 2018 DZone Guide to Security: Defending Your Code.