Disconnect Between Application Development and Security Getting Wider

There is a widening gulf between application developers and security decision makers inside the enterprise, and it’s starting to cost companies serious money.

There is a widening gulf between application developers and security decision makers inside the enterprise, and it’s starting to cost companies serious money. Sure there’s been lots of talk about the need for better static and dynamic web application testing tools and the need for a formalized security methodology integrated into software development lifecycles [SDL], but to date it’s all been talk.

Web applications are often a simple point of entry for attackers to get at enterprise data, yet security largely remains an afterthought for developers who face enormous deadline pressure to get features built in and applications out the door.

“No one argues around the need for better security and the need to get it earlier into process. Everyone talks about the SDL, but the problem is they’re not getting buy-in to the notion, but their processes aren’t aligned,” said Jennifer Johnson, vice president of marketing for application security company Coverity. “We see development and security in some cases being forced to work together, or they won’t come into same meetings, or just don’t like each other.”

Forrester Research and Coverity released a survey this week looking at this paradigm. The results shine a harsh light on the disconnect between these two IT disciplines; more than half of the respondents reported suffering a Web application-based breach since the start of 2011, with a quarter those costing companies between $100,000 and $500,000. A few reported breach losses between $1M and $5M.

“It’s mindboggling to see some large technology-driven organizations where developers and security don’t talk,” Johnson said. “It’s partially because developers don’t think with a security mindset. They have to get features delivered and are on a deadline. Security, meanwhile, works in a different way. They come in at the end [of the development lifecycle] and they’re compliance driven. There’s a need for both, but they haven’t met in the middle. Processes and incentive structures are not aligned.”

The result is a shoddy state of affairs with Web applications in production filled with gaping holes, daring targets for hackers. Basic flaws such as default account passwords, security misconfigurations, SQL injection and cross-site scripting vulnerabilities and poor authentication remain persist in Web apps.

“One of the big takeaways is the time-to-market pressures and the amount of code developers need to deliver functionality faster,” Johnson said. “Security can’t keep up. Legacy security tools purpose-built for [security] auditors don’t work for developers.”

Developers aren’t security experts and shouldn’t be expected to morph into security experts either. The pine for security tools that can easily be integrated into the development process that won’t yield a high volume of false positives and will provide actionable guidance as programmers code. Companies such as Coverity, White Hat Security, Armorize offer tools and services that integrate into a development environment and pop up remediation advice as coders enter potential defects into applications.

“The side benefit to that is that you’re quietly training developers and helping them understand where they might be susceptible to making errors,” Johnson said.

Most organizations, the survey results said, still rely on manual code reviews, that clearly don’t scale well across millions of lines of code and complicated enterprise-level applications. Less than half use static-testing tools during development. Time-to-market pressures are also blamed for the lack of secure coding guidelines in place and the fact that 28 percent of respondents reported they don’t use a library of approved or banned functions during coding. Even fewer developers use threat modeling practices during development, and despite metrics show it’s cheaper to fix security issues earlier in the development lifecycle, only 17 percent test during development.

“What happens is that security auditors will use a tool and send to it developers; security has selected a tool now they have to use it. This dynamic puts fuel on the fire around the lack of collaboration,” Johnson said. “Developers want to be empowered and pick tools that work best for them.”

Suggested articles

Kaspersky Lab Launches Bug Bounty Program

Kaspersky Lab today at Black Hat USA 2016 announced the launch of a public bug bounty, one of the few offered by a software vendor in the computer security industry.


  • Adam on

    Where's the evidence that the gap is widening? Over what timeframe has the gap widened? Over the last 15 years, we've made amazing strides forward.
  • Anonymous on

    This article seems like wild conjecture. Where's the evidence? Bring data or GTFO.

  • Anonymous on

    I think you'll find that the problem is management. If the security group isn't in on the development, or if their go/no-go decision is ignored, then who do you think is to blame.
  • Andy Kays on

    I would agree that the disconnect does still exist, I believe there is a lot of positive movement in the Industry but there is a long way to go. We at Nexor has spent considerable effort bringing security into our methodology and it has meant some fundamental changes in our approach to developing systems which are secure. We have only been able to achieve this by full buy in from the management, education of our team and the development our new processes to support it.

     Education is key to improving the situation and this has to start at school and university level. By teaching and training the next generation we will come to see security as an integral part of developing solutions and not add on that comes later.

  • web application on

    Thank you for sharing this application development and security blog.

Subscribe to our newsletter, Threatpost Today!

Get the latest breaking news delivered daily to your inbox.