eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
As it turns out, application security has a language barrier of sorts.
While security flaws affect applications written in every programming language, a new report shows that apps created using particular languages are more likely to have certain types of vulnerabilities than others.
In its State of Software Security report, application security firm Veracode found that some languages and frameworks make it easier for developers to make particular mistakes.
“Languages such as C/C++ are not type safe languages,” explained Veracode Vice President of Research Chris Eng. “Type safe means the language itself, rather than the programmer, keeps track of whether a data object is an integer or a string and the amount of space is needed to store that object. If there is not enough storage space, you will have a buffer overflow problem.
“In C/C++, the programmer has to keep track of the type and space with no help from the language or compiler, allowing flaws to creep into the software,” Eng said. “Languages such as .Net are type safe, so you will see a much lower occurrence of buffer overflow flaws.”
The proof is in the stats. The report examined data collected during an 18-month period from January 2011 and June 2012 from 22,430 application builds uploaded and assessed by the Veracode platform.
While 1percent of .NET applications are affected by buffer overflow flaws, that number jumped to 48 percent among C/C++ applications on first submission. SQL injection vulnerabilities, meanwhile, were found in 31 percent of Java applications on first submission, compared with 27 percent of PHP applications and 72 percent of ColdFusion applications.
“Organizations can estimate the resource impact of implementing or changing application security policies,” the report notes. “Consider the situation of a security team writing a policy aimed at eliminating SQL injection flaws and a development team writing their application in Java. The percentage affected data tells the teams there is a 31 percent chance that their application will have SQL injection flaw. The vulnerability prevalence data means that if the application does have SQL injection, it is likely that only 3 percent of the vulnerabilities found will be SQL injection.”
“Language design improvements can improve security, but they must also give developers flexibility to be innovative—which is why developers will always shoulder some of the responsibility for creating rugged code,” Eng said.
Having a mature development process does not automatically mean an organization has a secure development process, he added.
“The main concern of development organizations is creating software that meets key deadlines,” he explained. “They are not measured against security goals and their priorities are tied to time to market, meaning that security concerns often get shorted. Also, telling programmers that their code contains security flaws is basically telling them they made mistakes. It’s simply a reflection of human nature that there is a significant amount of pushback from the development organizations around security findings.”
Those mistakes, however, can be costly. Earlier this year, for example, it was revealed that Facebook and Apple were hacked due to employees visiting a site serving a zero-day exploit for a vulnerability in Oracle Java.
Upon first submission, 70 percent of the applications that Veracode analyzed were out of compliance with enterprise policy.
“Compliance with policies upon first submission of an application can be a good indicator of the success or failure of ‘building-in’ security as part of the software development lifecycle (SDLC),” the report notes. “Because security flaws that are eliminated before deployment, or never created in the first place, are much less expensive to remediate, thus building remediation into the SDLC at an early stage is often a key goal for most organizations.
“Yet, with more than two thirds of the applications failing to comply, our results show that secure software development practices are still not as widespread as they should be,” according to the report. “While applications may eventually become compliant, the high initial failure rate validates the concerns CISOs [chief information security officers] have regarding the business risks related to application security.”
While it is easy to say scan early and often in the SDLC, making that happen takes effort and requires building a relationship between two departments that often have competing interests, said Eng.
“Making security testing self-service for development teams, having a simple process to get developers started and providing remediation guidance on specific flaws found are all part of building a better relationship between development teams and security teams,” he said.