The number of open source components in proprietary apps continues to rise—a 2018 code audit found that there were 257 open source components per proprietary application. The same audit found that 57 percent of the average proprietary application codebase was open source. Open source projects give developers convenient access to high-quality code that can save them precious time in fast-paced modern development teams. However, because the open source model depends on community collaboration to identify and fix security problems in addition to setting security standards on a per-project basis, there is no guarantee that the open source components your company’s apps depend on are vulnerability-free. Large numbers of applications can become exposed to a vulnerability found in a single open source dependency. Apache Struts 2 is a case-in-point: this framework is widely used in modern web apps, including a host of Fortune 100 companies. The much-publicized Equifax data breach happened because hackers exploited a critical Struts vulnerability that could allow remote attackers to run malicious code on web servers. The damage caused by this Apache Struts vulnerability serves as a stark warning to organizations that they must take active steps to find and fix open source vulnerabilities in their code. Here are eight tips for uncovering and dealing with vulnerable open source code.
Lackadaisical security standards will encourage developers to take huge risks and use open source libraries or frameworks when building apps without considering security at all. Make sure it is organizational policy to develop with a security-first mindset. Require that developers check open source components for either disclosed or undisclosed vulnerabilities before using them. Communicating the risks involved in using vulnerable open source components, both to the wider application and to the organization as a whole, can also go a long way towards reinforcing why your security standards need to be so strict.
Modern solutions like software composition analysis tools and log management tools can provide greater visibility into open source vulnerabilities and whether they are being exploited. Software composition tools identify all open source used in source code, binaries, containers, build dependencies, and components. Logging tools like LogDNA will facilitate the analysis of large volumes of log data, providing visibility into suspicious network activity and system events across your infrastructure. This log data analysis can help identify if open source vulnerabilities are being exploited.
A container is a unit of software packaged with everything it needs to run, including libraries, system tools, dependencies. Running your libraries, frameworks, or apps inside containers provides isolation from other containers and from host systems, which limits the potential damage from any open source vulnerability.
Quite often the damage from a given vulnerability is not due to the lack of a fix, but poor patch management by companies exposed by that vulnerability. The Equifax Struts data breach exemplified what goes wrong when patches aren’t applied promptly. The credit reporting agency neglected to apply an update that fixed a major bug in Struts, and the resulting breach cost the company $242 million. The lesson? Keep up to date with security patches for open source projects and apply them as soon as possible to vulnerable application components.
Several useful tools exist that can test applications for several types of vulnerabilities and even pinpoint the precise location that the security issue arises from. Grabber, for example, is a lightweight tool that scans web apps for issues such as cross-site scripting and SQL injection. Other useful testing tools for uncovering security vulnerabilities include nogotofail, W3af, and Wfuzz.
Build automation tools like Maven and Gradle not only describe how an application is built, they can also list all the application’s dependencies, which is extremely useful for identifying vulnerable open source components. A simple command is all it takes for you to get a printed dependency tree in either Gradle or Maven. Other build automation tools often offer similar functionality in listing dependencies.
A number of vulnerability databases exist that collate information on different types of vulnerabilities, and it is prudent to check them regularly. The CVE database is a good starting point because it contains a regularly updated list of publicly known cybersecurity vulnerabilities. OSS Index is also worth checking out; it is a database used by developers to identify open source dependencies and check for vulnerabilities.
A difficulty with identifying vulnerabilities in open source projects is that developers often don’t publicly report the security defects that they find, perhaps due to the extra work involved or simple forgetfulness. To find out about undisclosed vulnerabilities and their fixes, you can audit the commits for open source projects. Manually this would be quite tedious, but a tool such as Commit Watcher can automate auditing by flagging commits with words such as exploit, vulnerability, or security.
Actually detecting open source vulnerabilities is half the battle when it comes to avoiding the monetary and reputational costs of a serious cybersecurity incident. Enforce prudent security standards, adopt containerization, regularly test applications, and gain visibility into documented and undocumented vulnerabilities and all dependencies. To remediate vulnerabilities, apply patches promptly, preferably from point releases so that you don’t make changes that could break the functionality of your apps.