This is the first post in a series of three blog posts that will be published throughout the next week
Last week’s Equifax breach has caught the ire of the U.S. government and its public as calls for official investigations are being made. The breach is now recognized as one of the 10 worst data breaches in history. A report by Baird implicated a remote code execution (RCE) flaw within open-source framework, Apache Struts. Open source frameworks are where most code is written today. So is open source the root cause of security breaches? Or is it the organization’s IT strategy, development process and work culture that create the weak spot? And, how should businesses control and maintain the software they produce?
While I can’t speak Equifax’s applications or their internal development process, I have firsthand experience with similar enterprises with complicated existing applications. Most organizations make the effort to create well-written software that go through an initial surge of bug fixes, followed by an ebb and flow of patching and updates. In theory, well-written software should not require lots of maintenance and patches to operate. This theoretical reliability creates a false sense of security as software can sit in production with little to no updates in between routine checks.
Open source’s general reliability and vigilant communal identification and patching of bugs also contributes to company-wide false sense of security. Open source libraries are indispensable to modern software. Most code is written on a foundation of open source libraries because it speeds up development and reduces maintenance costs. These libraries help with everything from simple string manipulation to web request handling to user interaction. Without them, software of the scale and complexity required in today’s internet would be impossible. Because of these benefits and protections, information technology (IT) teams may not feel an urgency to religiously check for defects and threats.
Being indispensable does not mean open source is risk-free. Numerous applications depend on these libraries, meaning a security vulnerability in any given library will impact a large number of user applications. In addition, it is easy to find existing security vulnerabilities through tools like the National Vulnerability Database (NVD), a government institution.
However, it is important to note that despite these risks, open source libraries remain much more secure than privately built software. Because open source libraries are popular and well-maintained, they have large advantages over privately built code. With a large active user base, bugs and security issues are quickly exposed. This user base includes the very programmers that developed open source software, and the organizations that build their applications on it. The ability to identify threats then triggers security patching, thereby removing vulnerabilities from the software quickly. These fixes are published and announced to users for inclusion and protection.
This rapid identification and patching process only works when IT strategy, work culture and the organization prioritize security and is proactive about addressing threats vs. relying on well-written code and open source as their daily security measure. For example, The Apache Foundation, whose Struts software was implicated, is very thorough when handling security issues. In relation to Equifax, it is possible that the company failed to keep up with the long-reaching effects of Apache Strut’s RCE flaw. Equifax is not alone in this security lapse. Despite the harrowing threat of leaving known vulnerabilities unpatched, Symantec reported that 75% of websites today remain unpatched, leaving a gaping security vulnerability.
As we can see, open source software is a critical piece of IT and modern applications. Open source enables faster development and more reliable software, but can expose software to shared vulnerabilities (though this exposure risk is greater with privately-built software). Fortunately most open source software does a great job at finding and patching these security holes. But that alone is not enough. To avoid massive security failures, organizations and businesses must be vigilant in maintaining user application in between routine maintenance checks.