Dangers of Only Scanning First-Party Code

When it comes to securing your applications, it’s not unusual to only consider the risks from your first-party code. But if you’re solely considering your own code, then your attack surface is likely bigger than you think.

Our recent State of Software Security report found that 97 percent of the typical Java application is made up of open source libraries. That means your attack surface is exponentially larger than just the code written in-house. Yet a study conducted by Enterprise Strategy Group (ESG) established that less than half of organizations have invested in security controls to scan for open source vulnerabilities.

If the majority of applications are made up of open source libraries, why are most organizations only scanning their first-party code? Because most organizations assume that third-party code was already scanned for vulnerabilities by the library developer. But you can’t base the safety of your applications on assumptions. Our State of Software Security: Open Source Edition report revealed that approximately 42 percent of the third-party code pulled directly by an application developer has a flaw on first scan. And even if the third-party code appears to be free of flaws, more than 47 percent of third-party code has a transitive flaw that’s pulled indirectly from another library in use.

Over the years, several organizations have learned the hard way just how dangerous it is to only scan first-party code.

• In 2014, the notorious open source vulnerability – Heartbleed – occurred. Heartbleed was the result of a flaw in OpenSSL, a third-party library that implemented the Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols. The vulnerability enabled cyberattackers to access over 4.5 million healthcare records from Community Health Systems Inc.
• In 2015, there was a critical vulnerability in Glibc, a GNU C library. The open source security vulnerability nicknamed “Ghost,” affected all Linux servers and web frameworks such as Python, PHP, Ruby on Rails as well as API web services that use the Glibc library. The vulnerability made it possible for hackers to compromise applications with a man-in-the-middle attack.
• In 2017, Equifax suffered a massive data breach from Apache Struts which compromised the data – including social security numbers – of more than 143 million Americans. Following the breach, Equifax's stock fell over 13 percent.

On the good news front: Close to 74 percent of open source flaws can be fixed with an update like a revision or patch. Even high-priority open source flaws don’t require extensive refactoring of code – close to 91 percent can be fixed with an update. Equifax had to pay up to $425 million to help people affected by the data breach that the court deemed “entirely preventable.” In fact, it was discovered that the breach could have been avoided with a simple patch to its open source library, Apache Struts.

Don’t become a victim to the monsters lurking in your third-party libraries. Download our whitepaper Accelerating Software Development with Secure Open Source Software, to learn more.