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.”
