Security report: Enterprises place reckless trust in third-party software suppliers

Veracode's Supplemental to their State of Software Security Report shows most dangerous security flaws in existence are among the most prevalent vulnerabilities in third-party vendor applications - while few enterprises have vendor application security testing programs in place.
Written by Violet Blue, Contributor

Software security testing company Veracode's just-released Supplemental to its 2012 State of Software Security Report focuses on the software supply chain. It reveals that organizations are confronting externally developed application security risks more than ever - yet most enterprises place a reckless trust in their third-party software suppliers.

Veracode has been publishing their State of Software Security reports since 2010, and - of course, in light of the report's focus - it's no surprise a software security testing company is concluding a need for multi-sector, systematic software security testing.

I asked security researcher and CTO of Veracode Chris Wysopal what kind of reactions the report has had so far.This 2012 Supplemental marks the first time Veracode has re-examined its dataset from varying perspectives. This second supplemental focused on software security testing metrics, and how different program approaches impact software vendor compliance with app security policies.

He told me, "CIOs and CISOs love it. It gives them data that they can use to design a 3rd party risk program. It gives them evidence that these programs can work."

However, he added, "A few have come to me and said XYZ huge software company is never going to participate."

Veracode's Supplemental saw that few enterprises - defined in the report as companies with over $500 million in revenue -  have formal programs in place to manage and secure the software supply chain.

The Supplemental also showed significant gaps between between enterprise standard and industry standard compliance.

Non-trivial attacks (like SQL injection and Cross Site Scripting) were listed in the report as among the most prevalent vulnerabilities for third-party vendor applications. 

Interesting bits from the Supplemental included:

  • Testing vendor apps is on the rise in many industries, finally.
  • Less than one in five enterprises have asked for a code-level security test from a software vendor.
  • 38% of vendor supplied apps complied with enterprise-defined policies - vs. 10% with the OWASP Top Ten and 30% with CWE/SANS Top 25 industry-defined standards.
  • SQL injection and cross-site scripting affect 40 percent and 71 percent of vendor-supplied web application versions, respectively.
  • Enterprises with structured programs enabled more vendors to achieve compliance quickly (which makes sense), with 45 percent of vendor applications becoming compliant within one week.
  • By contrast, enterprises with ad-hoc programs only saw 28 percent of third-party applications achieve compliance within one week.
  • Veracode explored vulnerability categories by language family. For Java, code quality topped the list (86%) followed by crypto issues; crypto took the top spot for .NET (77%) with code quality in second place. Error handling affects the most C/C++ apps (87%) followed by buffer overflow (75%).

It was interesting to have Wysopal tell me that what surprised him about the report was just how much awareness has increased about outside software security across varying sectors;

The diverse types of companies doing 3rd party testing surprised me. It isn't just finance and software companies which you would assume understand the risks from 3rd party software.

The fact that telecomm, healthcare, business services, and media companies are doing this tells me this will become mainstream a lot sooner than I expected.

Still, Veracode's findings suggest that most companies purchasing software from outside vendors have uneven approaches to monitoring the security of these products - if the enterprises are even demanding the products be security compliant at all.

I asked Wysopal, that if the third party app ecosystem is riddled with risks, and isn't going to change anytime soon (and may get worse before it gets better), what could be done to manage/mitigate risk in the immediate future?
Chris responded, 
I think the 3rd party ecosystem is going to change sooner than was once thought.  It took over 5 years for Microsoft to make headway against the software security problem but that was sort of like turning around a supertanker.  
Smaller software vendors don't have so much legacy code and backwards compatibility issues to deal with. They can change more quickly and have been the most responsive.
For the immediate future I don't think there is anything easy that can be done quickly. It will be important to prioritize the applications and vendors you deal with first. A risk assessment should take place to determine which 3rd party applications are the most critical to your business and target them first.
Since Veracode's report could read like a cautionary tale, I asked Wysopal what he felt was most urgent.
He replied,
Organizations should start with the web applications that are outside their perimeter. Just like they patch those machines the quickest when new critical patches are release those should be the first 3rd party apps they assess.
You don't have to look that far back in time to see serious incidents that were do to attackers compromising  web apps developed by 3rd parties.  
For example, the pbs.org attack was due to a vulnerability in their content management system, Moveable Type. And When Kaspersky's support site was compromised they said it "was in a 'third-party application' used by the website."

About Veracode's SOSS methodology: 

This Study of Enterprise Testing of the Software Supply Chain captures data collected from 939 application versions (across 564 distinct applications) submitted to the Veracode Platform during an 18 month time period from January 201 to June 2012. The data comes from actual security analysis of web and non-web applications across industry verticals, languages and platforms, and represents multiple security testing methodologies on a wide range of application types and programming languages.

Editorial standards