5 Open Source Security Risks You Should Know About

By giving developers free access to well-built components that serve important functions in the context of wider applications, the open source model speeds up development times for commercial software by making it unnecessary to build entire applications completely from scratch.

However, with research showing that 78 percent of audited codebases contained at least one open source vulnerability, of which 54 percent were high-risk ones that hackers could exploit, there is clear evidence that using open source code comes with security risks. Such risks often don’t arise due to the quality of the open source code (or lack thereof) but due to a combination of factors involving the nature of the open source model and how organizations manage their software.

Read on to find out the five open source security risks you should know about.

Publicity of Exploits

The nature of the open source model is that open source projects make their code available to anybody. This has the advantage that the open source community can flag potential exploits they find in the code and give open source project managers time to fix the issues before publicly revealing information on vulnerabilities.

However, eventually such exploits are made publicly available on the National Vulnerability Database (NVD) for anyone to view. Hackers can use the publicity of these exploits to their advantage by targeting organizations that are slow to patch the applications that may be dependant on open source projects with recent vulnerabilities.

A pertinent example of issues due to publicly available exploits was the major Equifax breach in 2017 wherein the credit reporting agency exposed the personal details of 143 million people. The reason the exposure occurred was that attackers noticed Equifax used a version of the open source Apache Struts framework which had a high-risk vulnerability, and the hackers used that information to their advantage.

Dealing with this risk from the organization perspective means recognizing that open source exploits are made vulnerable and that hackers stand to gain a lot from attempting to breach services that use vulnerable components. Update as quickly as possible or pay the consequences.

Difficulty Managing Licenses

Single proprietary applications are often composed of multiple open source components, the projects for which are released under any of several license types, such as Apache License, GPL, or MIT License. This leads to difficulty in managing open source licenses considering the frequency with which enterprises develop and release software and the fact that over 200 open source license types exist.

Organizations are required to comply with all individual terms of different licenses, and non-compliance with the terms of a license puts you at risk of legal action, potentially damaging the financial security of your company.

Tracking licenses manually is prohibitively time-consuming—consider a software composition analysis tool that can automatically track all of the different open source components and licenses you use in your applications.

Potential Infringement Issues

Open source components may introduce intellectual property infringement risks because these projects lack standard commercial controls, giving a means for proprietary code to make its way into open source projects. This risk is evident in the real-world case of SCO Group, who contended that IBM stole part of the UnixWare source code and used it for their Project Monterey and sought billions of dollars in damages.

Appropriate due diligence into open source projects can flag up potential infringement risks.

Operational Risks

One of the main sources of risks when using open source components in the enterprise comes from operational inefficiencies. Of primary concern from an operational standpoint is the failure to track open source components and update those components as new versions become available. These updates often address high-risk security vulnerabilities, and delays can cause a catastrophe, as was the case in the Equifax breach.

It’s vital, therefore, to keep an inventory of your open source usage across all your development teams, not only to ensure visibility and transparency, but to avoid different teams using different versions of the same component. Keeping an inventory needs to become part of a dedicated policy on open source usage, and software composition analysis tools provide a means to enforce this practice in an automated, easily manageable way without manually updating spreadsheets.

Another issue is abandoned projects that perhaps begin with much active involvement from the open source community but eventually peter out until nobody updates them anymore. If such projects make their way into apps in the form of libraries or frameworks, your developers are responsible for fixing future vulnerabilities. Part of good inventory management is to track projects that are updated infrequently.

Developer Malpractices

Some security risks arise due to developer malpractices, such as copying and pasting code from open source libraries. Copying and pasting is an issue firstly because you copy any vulnerabilities that may exist in the project’s code when you do it, and secondly because there is no way to track and update a code snippet once it’s added to your codebase, making your applications susceptible to potential future vulnerabilities that arise. You can avoid this issue by creating an open source policy that specifically forbids copying and pasting snippets directly from projects to your application codebases.

Another malpractice that can occur is the manual transfer via email of open source components across teams. This is opposed to the recommended best practice which is to use a binary repository manager or a shared, secure network location for transferring components.

Conclusion

Open source is a highly useful model that deserves its current standing as the bedrock of the development of many modern applications. However, smart use of open source components involves acknowledgment of the security risks involved in using these components in your applications and prudent, proactive action to minimize the chances of these risks affecting your organization directly.