6 Best Practices for Using Open Source Software Safely
Open source software is critical yet potentially dangerous. Here are ways to minimize the risk.
October 6, 2020
![](https://eu-images.contentstack.com/v3/assets/blt6d90778a997de1cd/bltf090c2712531f809/64f0d3bcb3a30f0b74781c12/Image_1.jpeg?width=700&auto=webp&quality=80&disable=upscale)
It's no longer a question of whether enterprise software is developed using open source code, but just how much open source code makes up each application. And as DevOps becomes the default development discipline for more organizations, the pressure to reach out and grab reusable modules and libraries is almost guaranteed to make open source code a greater percentage of enterprise software.
Even with commercial software, questions about third-party risk and supply chain security loom large. When those questions extend to open source software, they can become absolutely overwhelming.
Research bears that out. In reviewing enterprise codebases submitted for audit, Synopsis found 70% of the code was open source. While not in any way an indictment in and of itself, 73% of codebases they found had at least one licensing issue and 82% included 4-year-old code. Combined, the security and reliability of applications containing open source software becomes a legitimate concern.
As with so many facets of cybersecurity, attention to detail carries a great deal of weight when it comes to keeping open source containing projects safe and secure. What else do you need to know? Dark Reading combed the Internet and reviewed numerous conversations we've had in recent months to put together this collection of best practices. Let us know whether you have any of your own in the Comments section, below.
(Image: duncanandison VIA Adobe Stock)
When the organization's de facto policy on software development is "finish it yesterday," it's easy to let other policies languish. But the beginning of security for open source software within enterprise development is having a policy about open source software in enterprise application development.
According to a blog post on Synopsis, the first step in securing software development is to create a clear policy for developers, management, and operations staff regarding the use of open source use within the organization.
As the policy is developed, it presents an opportunity to involve all the stakeholders for application development so they both understand the priorities in reducing risk and provide input about how to reduce risk. That understanding can be the beginning of standard behaviors and practices, as well as the foundation of application security.
In the hyper-speed world that is DevOps (or even agile), old code is, at best, a ticking time bomb. At worst, it's the sort of digital "hack me" sign that criminals love to see in an application.
Statements about how updates should be managed should be part of every open source policy document. According to an article on the AltexSoft blog, "Any time a bug is found and fixed in an open source project, it's a race against time to ensure you apply the relevant updates to all applications that use libraries or frameworks from those projects."
One of the keys to keeping components updated is understanding which components are part of the application. A number of tools are available for scanning and enumerating the components in a project. Coverity Scan, for example, is used within many larger open source projects and enterprises. But regardless of the tool used, it's important the technology support a policy of consistently monitoring and updating named components and their various software dependencies.
The need for speed in DevOps and agile can run into the limitations of smaller security headcount. Automation can be the "bumper" that allows the two competing realities to co-exist.
Automation is recognized as critical for open source security at many different levels. GitHub, for example, has launched Dependabot as a tool to monitor dependencies (applets, pieces of code, or libraries used inside another application) and ensure the code used in a project is the most recent version. Similar tools are available for both developer and operational uses within the enterprise.
As anyone who has lived through Patch Tuesday can attest, the automated update scan process can lead to unintended consequences. Properly deployed security, orchestration, automation, and response (SOAR) tools can go a long way toward minimizing the risks of updating while maximizing the benefits of up-to-date code. Both the consequences and benefits are why it's important to include automation tools as part of an overall software supply chain security program, rather than expecting to turn on the tools and walk away.
No application is an island. In the modern era, virtually all applications are built from components -- most of them open source projects -- that are themselves built of more open source components. Vulnerabilities can exist in any of the components, including those the enterprise development team aren't aware they're using. That ignorance can, in and of itself, be a most profound vulnerability, too.
According to a report by Synopsis, the average codebase analyzed in 2019 contained about 445 open source components. Not all of them will be called explicitly in the enterprise code, and many are likely to be dependencies called within a piece of code incorporated by name.
Many tools are available for identifying the dependencies within an application. For example, the OWASP Dependency-Check tool, which has been developed and released in an open source structure, analyzes code and checks it against CVE databases to find known vulnerabilities and dependencies.
Open source projects come in many different sizes, from those around many Linux distros, which can have thousands of contributors and hundreds able to make "commits," to projects with a single administrator and active developer. When it comes to security, the size of the project can have a profound impact on whether code is safe to use in the enterprise.
There have been next to no cases of intentional vulnerabilities inserted into open source code, but vulnerabilities do exist in open source projects, just as they do in commercial software. Vulnerabilities tend to be found more quickly in larger projects because they have more sets of eyes available to look at code for potential flaws. It is, at its root, a numbers game in which the larger projects win.
It's difficult to imagine a rational rule stating "code may only come from projects with at least XX active participants." Still, it's reasonable to encourage developers to take project size into account when evaluating code and to develop a bias in favor of the larger project when multiple libraries or functions are available to do similar jobs.
Do you know where your code comes from? Unfortunately, many development managers believe their developers (or contractors) are getting nothing but wholesome, grade-A libraries and functions from well-known sources, when, in fact, the code actually comes from whichever repositories come up highest in their search results.
In a report on supply chain security, the Linux Foundation notes, "In most language repositories, weak or missing authentication and publisher verification mechanisms create uncertainty and risk over the provenance of stored code." That's just one of a half-dozen risk factors the foundation calls out for open source repositories used by enterprise developers.
GitHub is the repository where many open source projects maintain their code base and project documentation. There are also many language-specific repositories, as well as repositories targeting particular frameworks and managers. It's important that developers understand the capabilities and limitations of any repository where they obtain code, and for development managers, in consultation with security teams, to build policies and procedures that spell out limits on where developers can get the code that will go into enterprise applications.
Do you know where your code comes from? Unfortunately, many development managers believe their developers (or contractors) are getting nothing but wholesome, grade-A libraries and functions from well-known sources, when, in fact, the code actually comes from whichever repositories come up highest in their search results.
In a report on supply chain security, the Linux Foundation notes, "In most language repositories, weak or missing authentication and publisher verification mechanisms create uncertainty and risk over the provenance of stored code." That's just one of a half-dozen risk factors the foundation calls out for open source repositories used by enterprise developers.
GitHub is the repository where many open source projects maintain their code base and project documentation. There are also many language-specific repositories, as well as repositories targeting particular frameworks and managers. It's important that developers understand the capabilities and limitations of any repository where they obtain code, and for development managers, in consultation with security teams, to build policies and procedures that spell out limits on where developers can get the code that will go into enterprise applications.
It's no longer a question of whether enterprise software is developed using open source code, but just how much open source code makes up each application. And as DevOps becomes the default development discipline for more organizations, the pressure to reach out and grab reusable modules and libraries is almost guaranteed to make open source code a greater percentage of enterprise software.
Even with commercial software, questions about third-party risk and supply chain security loom large. When those questions extend to open source software, they can become absolutely overwhelming.
Research bears that out. In reviewing enterprise codebases submitted for audit, Synopsis found 70% of the code was open source. While not in any way an indictment in and of itself, 73% of codebases they found had at least one licensing issue and 82% included 4-year-old code. Combined, the security and reliability of applications containing open source software becomes a legitimate concern.
As with so many facets of cybersecurity, attention to detail carries a great deal of weight when it comes to keeping open source containing projects safe and secure. What else do you need to know? Dark Reading combed the Internet and reviewed numerous conversations we've had in recent months to put together this collection of best practices. Let us know whether you have any of your own in the Comments section, below.
(Image: duncanandison VIA Adobe Stock)
About the Author(s)
You May Also Like
CISO Perspectives: How to make AI an Accelerator, Not a Blocker
August 20, 2024Securing Your Cloud Assets
August 27, 2024