Report: Reused, Third Party Code Major Sources of Insecurity

A new report out from security testing firm Veracode suggests that reused and third party code is a big source of application insecurity. 

A new report out from security testing firm Veracode suggests that reused and third party code is a big source of application insecurity. 

Application security is a sore spot for many organizations, as attackers shift the battlefield from operating system and network attacks to application specific hacks. Now a new report out from security testing firm Veracode suggests that the problem may be getting worse, not better. 
Veracode Inc. released its second State of Software Security Report on Wednesday. The report, which was based on Veracode’s analysis of 2,922 applications, found that fully 60 percent those submitted to Veracode for security verification failed on their first submission – up from 58% in the first State of Software Security Report. As in that report: third party application code and reused code were a major source of application insecurity, Veracode found.
The second volume of Veracode’s semi annual report includes reports on 1,400 more applications than were analyzed for Volume 1, which was released in March, 2010. Fifty seven percent of the applications scanned failed to pass the Veracode quality test on their first submission, and more than 80 percent of Web applications failed to pass a scan for the OWASP Top 10 Web application errors. Cross site scripting attacks continued to be the most prevalent type of security vulnerability, accounting for 51% of all vulnerabilities uncovered by Veracode. SQL injection is also a leading type of vulnerability and a top attack vector. Forty one percent of the applications scanned were found to have “cryptographic issues,” a category of vulnerability that could include sensitive data that was unencrypted or inadquately encrypted, the report found. 
Veracode’s study combines the results of a variety of types of testing, including static binary analysis, dynamic code analysis and manual testing. The company said its larger application testing base – 200 percent larger than that used for Volume 1 of the State of Software Security – makes for a better picture of the application security space. In assigning “pass” versus “fail” grades, the company takes into account the application’s score on its various code analysis tests, as well as the application’s criticality – how sensitive the data that it handles is. 
The picture that emerged isn’t encouraging. Third party code was found to be a major source of application vulnerabilities – and to be ubiquitous. Between 30% and 70 of applications submitted to Veracode as “internally developed” were found to contain code from third party suppliers, said Chris Eng,Senior Director of Security Research at Veracode. Often, that code comes in the form of third party code libraries used to develop the applications, special purpose tools acquired for use internally, or applications inherited through mergers and acquisitions, he said.   
Simple cutting and pasting of code is also common, Eng said, which means that mistakes made once can metastesize across a wide ecosystem of applications. 
“Lots of time we see code copied from the documentation of an API and its a vulnerable piece of code,” Eng said. 
Veracode said it found more evidence of back doors in the applications it analyzed, and some instances of malicious back doors, data exfiltrating torjans and logic bombs. Such suspect or malicious elements may account for as much as 2% of the vulnerabilities discovered, he said. 
Still, inadvertent errors and poor implementation of features were the biggest source of vulnerabilities, Eng said. The prevalnce of cross site scripting and SQL injection holes points to the need for better developer education and training, he said. 
In industry verticals that have emphasized secure coding, such as financial services and government, there appears to be a pay-off. Just forty percent of applications submitted by Veracode government customers failed to pass on their first scan, compared with 56 percent for financial services and 60% for the software vertical.

Veracode Inc. released its second State of Software Security Report on Wednesday. The report, which was based on Veracode’s analysis of 2,922 applications, found that fully 60 percent those submitted to Veracode for security verification failed on their first submission – up from 58% in the first State of Software Security Report. As in that report: third party application code and reused code were a major source of application insecurity, Veracode found.

The second volume of Veracode’s semi annual report includes reports on 1,400 more applications than were analyzed for Volume 1, which was released in March, 2010. Fifty seven percent of the applications scanned failed to pass the Veracode quality test on their first submission, and more than 80 percent of Web applications failed to pass a scan for the OWASP Top 10 Web application errors.

Cross site scripting attacks continued to be the most prevalent type of security vulnerability, accounting for 51% of all vulnerabilities uncovered by Veracode. SQL injection is also a leading type of vulnerability and a top attack vector. Forty one percent of the applications scanned were found to have “cryptographic issues,” a category of vulnerability that could include sensitive data that was unencrypted or inadequately encrypted, the report found. 

The security of Web applications has been in the headlines recently. Last week, researchers at a conference in Argentina demonstrated an attack that could circumvent security protections in millions of Web applications that use Microsoft’s ASP (Active Server Pages) .NET technology. Recent threats like the Stuxnet worm have also focused on compromising application holes – in the case of Stuxnet: a hard coded administrative password in Siemens industrial control software.  

Veracode’s study combines the results of a variety of types of testing, including static binary analysis, dynamic code analysis and manual testing. The company said its larger application testing base – 200 percent larger than that used for Volume 1 of the State of Software Security – makes for a better picture of the application security space. In assigning “pass” versus “fail” grades, the company takes into account the application’s score on its various code analysis tests, as well as the application’s importance: how sensitive the data that it handles is. 
The picture that emerged isn’t encouraging. Third party code was found to be a major source of application vulnerabilities – and to be ubiquitous. Between 30% and 70 of applications submitted to Veracode as “internally developed” were found to contain code from third party suppliers, said Chris Eng,Senior Director of Security Research at Veracode. Often, that code comes in the form of third party code libraries used to develop the applications, special purpose tools acquired for use internally, or applications inherited through mergers and acquisitions, he said.   

Simple cutting and pasting of code is also common, Eng said, which means that mistakes made once can metastasize across a wide ecosystem of applications. 
“Lots of time we see code copied from the documentation of an API and its a vulnerable piece of code,” Eng said. 

Veracode said it found more evidence of back doors in the applications it analyzed, and some instances of malicious back doors, data stealing Trojans and logic bombs. Such suspect or malicious elements may account for as much as 2% of the vulnerabilities discovered, he said. 
Still, inadvertent errors and poor implementation of features were the biggest source of vulnerabilities, Eng said. The prevalnce of cross site scripting and SQL injection holes points to the need for better developer education and training, he said. 

In industry verticals that have emphasized secure coding, such as financial services and government, there appears to be a pay-off. Just forty percent of applications submitted by Veracode government customers failed to pass on their first scan, compared with 56 percent for financial services and 60% for the software vertical. 

Suggested articles

Discussion

  • Greber on

    While this study does a great job of raising the awareness of just how vulnerable enterprise applications are, it does not focus on the bigger issue of how to fully secure these applications.

    Automated scanning tools like Veracode are very good at finding some common vulnerabilities, but they cannot find some pretty significant issues.  The only way to determine the total risk due to application vulnerabilities is to use a combination of manual and automated analyses. This is still the only way to discover all the risks present in internet applications, although using these automated tools is better than doing nothing at all.

    Greg Reber, CEO, AsTech Consulting

     

  • Dan Marx on

    All,

    My name is Dan Marx and I work for Veracode. I just wanted to clear up any confusion there may be regarding our stance on assessing applications using multiple testing technologies. We absolutely agree with Greg that assessing applications using a combination of manual and automated analysis is the only way to determine the total risk due to application vulnerabilities.

    In fact, we state this in the executive summary and go into greater detail in the body of the report:

    6. No single method of application security testing is adequate by itself
    Others have reported this year on the inadequacy of web application scanning.3 Veracode’s code-level analysis of vulnerabilities using multiple testing techniques on the same applications confirms that dynamic web application scanning tools are not sufficient as the sole testing method. Similarly, manual penetration testing, while necessary to fully comply with policies such as the OWASP Top 10 and the CWE/SANS Top 25, lacks consistency of coverage and will rarely detect all instances of commonly occurring vulnerabilities. However, while the evidence shows that static binary analysis provides the most consistent breadth and depth of coverage, it is also true that not all design and business logic vulnerabilities are discoverable with static methods alone.
    Recommendation: CISOs and CIOs should view different testing techniques as operating controls that each play an important role in a comprehensive policy driven program. Multiple testing techniques should be adopted based on application business criticality and type of application. The use of multiple techniques is the only way to comply with industry standard security polices such as the OWASP Top 10 and the CWE/SANS Top 25 Most Dangerous Software Errors.

    Just wanted to clear up any confusion there may have been. Please feel free to reach out to me with any questions you may have. My email is dmarx@veracode.com.

    Thanks,

    Dan

  • Courtney Cavness on

    Very interesting article.

    It's nice to know some statistics about the kinds of vulnerabilities 3rd-party code typically introduces. I work in information security and have seen firsthand that it is increasingly common for developers of IT products to include 3rd-party code, and they are sometimes are unaware of the security risk that poses.

    I've also found that many prominent ISO IT security standards don't address the issue of reviewing all included 3rd-party code -- or address it only insofar as to say the developer must define some criteria the 3rd-party must meet, but that is left up to the discretion of the developer.

    Seeing this issue arise more and more often, two colleagues and I wrote a white paper identifying the security problems that arise when including 3rd-party code in IT products, and specifying the criteria of an acceptance procedure that would allow these inherent security risks to be overcome. The white paper is here, for anyone interested: http://www.atsec.com/us/news-white-paper-untrusted-developers-cc-203.html

Subscribe to our newsletter, Threatpost Today!

Get the latest breaking news delivered daily to your inbox.