Despite a steady drumbeat from experts who put the responsibility for securing applications on developers, two recent surveys showed that developers still are not doing enough in this regard.
Veracode, a cloud-based application security testing company, used its database of applications collected over the past 18 months to determine what developers are doing in the area of software security. Sam King, vice president of product marketing at Veracode, said that some of the findings came out of the fact that the company raised the level of requirements for software programs to pass the security tests.
CAST, a software analysis and measurement firm, found that there is over US$3.6 million of technical debt (the amount of money it costs a software company to correct high-risk issues that appears in a line of code) across all applications with 1 million lines of code, according to its CAST Report on Application Software Health survey.
Bill Curtis, CAST’s chief scientist, said the survey found that these security vulnerabilities are not limited to one specific type of programming language, although he noted that COBOL-based financial applications did fare better.
Performance in the security tests, he said, was lower in Java applications, which is what King found for mobile applications as well, as many are written in Java. Veracode tested Android and iOS mobile applications, but only released findings for Android applications because it has supported testing them longer.
“We are trying to figure out what the lower performance issues in Java mean,” said Curtis. “It might mean developers are younger and don’t have as much experience dealing with security issues.” Curtis believes that Java developers are younger because it is a newer and more popular language, in his experience.
Neil MacDonald, vice president and distinguished analyst at Gartner, said that because security is not a part of most college curricula, companies should take the time to invest in training their developers.
“The single most important thing a developer can do is filter and whitelist input,” he said. “This doesn’t require an understanding of security vulnerabilities.” He added that it does help defend against cross-site scripting and SQL injection attacks. In order to filter and whitelist input, he said developers should simply require that a particular field gets either numbers, characters or a combination of both, blocking against whatever shouldn’t be included in that particular data field.
Additionally, MacDonald said developers should be taught what exactly these vulnerabilities and prevention look like with actual code examples to help familiarize them with the blocks of coding they should include in their applications.
#!
Inside the numbers
The CAST survey tested 745 applications, and increased its sample size to 360 million lines of code from last year’s 108 million lines of code, making this one of its largest samples. Curtis said this offered a better example of what types of security problems, including application performance, robustness, and software transferability and changeability, are actually floating around in software used by millions of people on a daily basis. He said that more than 35% of the violations found result in damage to the business by affecting the security, performance and uptime of application software.
The Veracode survey tested 9,910 applications—compared to last year’s 4,835—and eight in 10 applications did not pass its security standards, which include a zero-tolerance policy for cross-site scripting and SQL injections. “This shows how much work needs to be done,” King said.
Overall, the Veracode survey found that SQL injection threats were present in 32% of all Web applications tested, and 68% of applications had scripting vulnerabilities.
King added that 40% of the vulnerabilities found in government Web applications are from SQL injections, the highest of the industries tested. SQL injections account for 29% of the vulnerabilities in finance applications and 30% in software industry applications.
King said that Android applications showed the same types of vulnerabilities in the Veracode survey as early Web applications did. Chris Wysopal, cofounder, CTO and chief information security officer of Veracode, said mobile application developers often work quickly and need to incorporate security measures into their reduced development cycles, something they may already be doing but aren’t doing diligently.
King said many mobile applications carry the requirement that end users don’t have to authenticate multiple times, which can create risk, particularly since many of these applications have to call back to servers in order to work. Thus, if a device is authenticated and lost, the back end could be exposed to whoever picks up the device.
As CAST’s Curtis said when he speculated that Java developers coming straight from school may have a hard time incorporating stringent security standards into their applications, lack of training seemed to be an issue in the Veracode survey as well. Better-trained developers, King said, appear to write better applications out of the gate.
Gartner’s MacDonald said development speed and security do not need to be at odds. “Coding security [into applications] doesn’t have to take more time,” he said, adding that there is a perception that doing work quickly means leaving out steps that are not mission–critical, but that this is not the reality. He said that developers can do work quickly and add the proper security measures, if they’re aware of the vulnerabilities out there. He said automation can actually help with securing applications, but he warned that development teams should not believe that tools and automation will be all they need to secure their applications.
“It is hard to change processes and developers,” said MacDonald. “It requires a combination of people change, process change and technology change.” He added that short-term gains sometimes make companies resistant to change.
Agreeing with MacDonald, Curtis warned that the implications and expenses of technical debt are far greater than the cost of training. CAST determined that the average line of code costs companies approximately $3.61 in technical debt, which means that, as he explained, once you hit 300,000 lines of code, it is already past the million-dollar mark. Java, he said, had the most technical debt per line of code.
Security, he said, needs to be a discipline, which is why he is encouraged by the fact that the agile community raises awareness for these issues. He said that some debt needs to be “retired” in each iteration or development cycle in order for companies to ever handle—and ultimately get ahead of—their technical debt.
