The Facts - On September 7th Equifax announced that hackers breached their systems. According to their information site the breach occurred in mid-May and became known to Equifax on July 29th. In the days following the announcement, Equifax's stock fell over 13%, a congressional hearing was ordered and a class-action lawsuit formed for the people affected. Fortune describes the hack as "...the most economically damaging hack in U.S. history".
The full story and the long term impact are still emerging but given the magnitude of this hack and the details that are already known, we have put together a set of free resources to help you make sure your company does not become the next Equifax.
How the Equifax Data Breach Happened
In this particular case hackers exploited a web vulnerability in the Equifax site which was built on a Java framework called Apache Struts. Struts is widely used in banks, airlines, and Fortune 1000 companies and like almost all popular open-source code has had its fair share of vulnerabilities being reported which have subsequently been patched. This year there have been several major vulnerabilities reported in Struts: the first in March and the most recent last week. SourceClear also knows that most vulnerabilities are not reported to the National Vulnerability Database (NVD) and Struts, like other open-source projects are likely to contain many inherited and similar issues.
Analyzing the Latest Code for Apache Struts
We analyzed the latest code for Struts on Sunday 10th September which revealed it uses 11 vulnerable libraries which have 43 security advisories reported against them. One specific library has a high risk remote code execution vulnerability where the vulnerable part is actively being called. Information about this issue CVE-2017-7525 at the time of writing is marked as Reserved in the NVD meaning it is not publicly or widely available but SourceClear has a complete technical writeup available to its users. This new issue is a textbook case of why simplistic tools that only look at the source code are not sufficient for open-source security testing because the library in question is only added to Struts at build-time and would therefore never be seen by tools monitoring code repos like GitHub. The full write up of our analysis of the open-source used in the latest version of Struts can be found here.
Data breaches like this are a result of hackers exploiting vulnerable open-source code are becoming the new normal. There are effective tools and processes you can adopt today to prevent it from happening to you.
What You Should Do
All companies can take immediate steps to determine if their projects are using the vulnerable versions of Apache Struts and then determine if they themselves are vulnerable.
Scanning with SourceClear will show you what open-source is being used, which vulnerable libraries are being used, and most importantly if you are using them in a way that makes your company vulnerable. Our real-world studies show that less than 10% of the time that vulnerable Java libraries are used that the project is actually vulnerable and the only way to actually determine this is to scan your projects when they are being compiled. SourceClear is the only solution that uses call-graph technology to perform this level of analysis.
Longer term all companies should build an open-source security program which scans always all code as part of the continuous integration process and ensures that only safe-code is being consumed by their software supply chain. SourceClear is a security automation and risk management solution for open-source code that integrates with all continuous integration systems and connects with issues trackers like Atlassian's JIRA to allow security teams and development teams to work together, keeping safe open-source in and kicking un-safe open-source out.