In its 2015 report, the Open Web Application Security Project (OWASP) identified SQL injection and cross-site scripting among its Top 10 software vulnerabilities. Again.
If it feels as if you’ve been reading this same story for the last decade, it’s because you have. So why is it that we can build intelligent robots, fling unmanned vehicles throughout the universe and create computers that can recognize natural languages to a point where they can defeat humans on television quiz shows, but we can’t put an end to these software vulnerabilities?
John Steven, CTO of security company Cigital, said, “We’re in—and sick of—the hamster wheel of pain” that patching those vulnerabilities represents. “How many dynamic testing tools results parties do we have to have on every application before we get that there are certain truths that remain self-evident, like your hygiene around outputting coding and input validation continues to be bad?”
Rod Cope, CTO of Rogue Wave, agreed, saying “You would think after 15 years this wouldn’t be an issue. The OWASP Top 10 looks the same every year.”
Joseph Feiman, lead analyst for application security at Gartner, said, “Developers will keep developing insecure code, and there’s nothing they can do about it. It’s a losing battle with hackers.”
The life of software is so much different than it was just 20 years ago, when you built software, ran it behind a firewall, and left it unchanged until the next version was complete in six months to a year (or more). Today, according to Chris Raethke, CTO of testing organization Bugcrowd, applications are built horizontally using components. “All applications are pieces of the Internet,” he said, “dependent upon microservices and [service-oriented architecture].”
Further, said Raethke, developers are in a race against the clock as decisions regarding release dates, features and updates are driven more and more by non-technical people within an organization. “You can’t throw fairy dust in the air and get an app that’s secure, scalable and does everything [the organization] wants,” he said.
Whose responsibility is security?
For years, security advocates have said it’s up to developers to make sure the code they write is secure. Others insist developers don’t have the expertise in vulnerabilities and aren’t as up to date on known vulnerabilities as security practitioners.
“The bottom line is, we can’t make developers do this by hand,” added Cope. “It can’t be just another checkbox but a critical part of the [development] process.”
Enforcing security in code is anathema to developers, who are more interested in developing cool new functions than in ensuring the software is impenetrable. Cope said developers do not find security work interesting or fun, and they say to themselves, “I don’t get recognized for making my code secure. I only get recognized if I get a cool new feature out the door, or if we get hacked and something horrible happens, then I get blamed for it. But there’s no upside, other than avoiding more pain.”