The State of Software Security (SOSS): Open Source Edition analyzed the component open source libraries across the Veracode platform database of 85,000 applications which includes 351,000 unique external libraries.

The idea was to define the risk that a single flaw in one library can pose to all applications that leverage that code. Chris Eng, chief research officer at Veracode, said open source software has a surprising variety of flaws.

“An application’s attack surface is not limited to its own code and the code of explicitly included libraries, because those libraries have their own dependencies,” he said.

SEE: SQL injection attacks: A cheat sheet for business pros (TechRepublic Premium)

The study found that 70% of applications have a security flaw in an open source library on an initial scan. The other big picture findings were:

  • The most commonly included libraries are present in over 75% of applications for each language.
  • 47% of those flawed libraries in applications are transitive.
  • More than 61% of flawed libraries in JavaScript contain vulnerabilities without corresponding common vulnerabilities and exposures (CVEs).
  • Using any given PHP library has a greater than 50% chance of bringing a security flaw along with it.
  • Fixing most library-introduced flaws can be done with a minor version upgrade.

Here is a look at dependency types, flaws by languages, and an assessment of available fixes.

Identifying dependency types

To get a more complete picture of application security risks, Veracode analysts looked at dependencies in libraries. Many transitive dependencies can be a hidden attack surface and an unexpected maintenance workload.

The report studied where applications commonly pick up their dependencies, by language. The analysts looked at each application to determine how the library came to be included to help show which languages may have unintended consequences for maintainers.

Researchers found that JavaScript, Ruby, PHP, and Java get most of their attack surface from transitive inclusions and .NET, Swift, and Go have more direct dependencies.

The authors point out that: “An application that picks up most of its dependencies via second, third, or even greater degrees of separation from a developer’s explicit instruction increases the difficulty of managing those dependencies.”

Prevalence of the OWASP top flaws by language

The researchers also looked for flaws from the Open Web Application Security Project Top 10 list. These are:

  • Injection
  • Broken Authentication
  • Sensitive data exposure
  • XML external entities>
  • Broken access control
  • Security misconfiguration
  • Cross-site scripting XSS
  • Insure deserialization
  • Using components with known vulnerabilities
  • Insufficient logging and monitoring

The most common of these vulnerabilities in open source libraries are:

  • Cross-site scripting found in 30% of libraries
  • Insecure deserialization found in 23.5%
  • Broken access control found in 20.3%

The authors also found that PHP had the most issues with more than 40 percent of libraries having cross-site scripting issues as well as more broken access control and authentication problems than in any other language.

Most flaws have easy fixes

Even though almost every application that Veracode analyzed had some flaw introduced by a library, it noted the remedy was easy.

The authors analyzed the flaws to see how many could be fixed with an update and that was the case for 74%. Also, the majority of these updates were either minor fixes or patches at71%.

Most of the important library flaws in the Top 10 OWASP categories have fixes available. Indeed, 91% of flaws with public proof of concept exploits have a currently available fix.

The authors concluded that “most of these fixes are relatively minor in nature, suggesting that this problem is one of discovery and tracking, not huge refactoring of code.”

Image: Scanrail/Getty Images/iStockphoto