How to Manage Open-Source Software Securely

Despite decades of history, flexibility and cost effectiveness open source software is still viewed as risky by some organizations and industries. This piece explains how the use of modern practices around both infrastructure and development components ensure open source can be used just as safely as traditional closed source software.

How to Use Open Source Software

There are as many ways to use open source software as there are open source projects themselves. However, in general, they break down into two general categories:

• Open source as infrastructure: When using open source software as part of infrastructure, proper control is analogous to more traditional vendor management, with concerns around how secure the software is, how well it’s managed, how you can configure it, etc.
• Open source as development components: When open source components are used as part of development, a different set of questions should be raised, including licensing, how active the supporting community is, how well it integrates with other components, etc.

It is critical to understand open source is not inherently more or less secure than commercial software. While it is true companies have an economic interest in keeping their software bug-free, several decades of history suggest economic interest does not outweigh the need to constantly release new features with less testing than may be ideal. Open source software may lack that economic interest, but the people who work on many open source projects feel very strongly about code quality, which appears to function as a similar driver. This tends to put open source free software and closed source commercial software on roughly equivalent footing.

Download: DevSecOps Best Practices Checklist

What are the Open Source Environments?

When selecting open source software, it is important to understand two environments:

• The large environment in which it is developed
• The smaller environment (yours) in which it will be used

While many tests can be run to identify code quality, bug histories and the like, the simple fact is if you are using software in a way the creators and maintainers did not anticipate, you are far more likely to have problems, whether it is open source or not.

Issues When Used as Infrastructure

As an infrastructure component, you want to make sure the software is reliable and comes from a trustworthy source. There are no differences in due diligence when using, for example, Apache as compared to Microsoft IIS. Both are capable systems. Both come from reputable organizations. Both have had and fixed critical bugs. The overriding concern here is if the tool is suitable for the purpose and, if so, if you have the internal skill sets needed to configure and maintain it throughout its lifecycle.

Download: Open-Source Tooling Guide for Teams on Tight Budgets

Issues When Used as a Development Component

As a development component, you have the same concerns, with additional issues layered on top:

• Licensing: Some open source components come with specific licenses that could force you to release your own code as open source if you integrate with them in specific ways. It is wise to have a licensing expert on hand who can understand the specific licenses being used and assess whether there is any licensing risk to the organization. (While infrastructure components can pose a similar risk, it usually presents only in the context of modifying or integrating the component at the code level, which, effectively, turns it into a development component.)

   

• Overlaps and dependencies: As a development component, you also should be aware of overlapping components and choose appropriately. Although there are open source infrastructure components that overlap—such as the Apache and Nginx web servers—infrastructure components are designed to work together through open standards, while development components are designed to work together through dependencies. Because dependencies can become very complex, care should be taken that any development component is within the same “family” of other components already in use. This is easier in some languages/frameworks—such as Node.js and npm—than in others, such as Perl and CPAN. In general, selection of an open source component should involve a light analysis of other components that could solve the developer’s problem and identify why the suggested option is selected.

   

• Expertise: When using multiple copies of infrastructure components throughout an organization, it tends to work best to have a subject matter expert (SME) for that component who is aware of and can work with all instances. For example, if PostgreSQL is being used as a database, administrative tasks for PostgreSQL are very similar, regardless of what the database is being used for. However, if you have multiple development teams using the same component, the uses could be very different, and it is best to keep the SMEs aligned at the development team level. While the teams should certainly communicate with one another to discuss challenges, trying to have one person be responsible for specific development components tends not to work well in practice.

 Learn: How to Maximize Your Cybersecurity Impact

Tips on Detecting Open Source Software

While any software may enter an environment in unexpected ways, the free availability of most open source software does result in situations where such software is disproportionately represented in shadow IT situations. As such, having a method to detect and report on open source software is important. Fortunately, in addition to tools focused on this problem, most other security tools that are able to report on application or software issues can also identify the majority of such use cases.

From an infrastructure component perspective, traditional application control methods work fine. Open source applications like Apache Tomcat or Mozilla Firefox can be detected as applications, while open source servers/devices such as Kali Linux or Kubernetes can be detected through network scanning. Even open source infrastructure used in development such as Jenkins can be detected in this way.

Detection of open source development components is trickier and best done by scanning both the source control systems and the published/deployed production environments with software composition analysis (SCA) tooling. The best SCA tools, unfortunately, depend on the languages and frameworks in use, so it is not possible to provide specific tool recommendations here.

Infrastructure components should fall within existing policy around the deployment of software and systems. However, development components cannot be well controlled in most organizations because attempting to do so often slows development to unacceptable levels. Instead, you are better off defining what the application should do and placing controls around the application to restrict it to only authorized actions. This allows you to run a slower process that periodically checks for licensing and intellectual property issues and otherwise relies on the developers to be professionals who can be trusted to make appropriate decisions around what they are building.

Patching and Updating Open Source Software

A common question around open source software is how often it needs to be patched, because most open source projects do not release patches on a regular schedule like Microsoft. The answer is, unfortunately, “as often as it needs to be.” This means each patch should, in an ideal world, be reviewed and applied as soon as possible. In practice, the review will seldom result in any actual findings, so a more practical approach is often “patch automatically within each major release, as quickly as possible, and run automated tests.” For an infrastructure component, this should align with how you are patching other applications. Updating Linux and updating Windows are very similar processes. Updating a component with a version like 12.4.11 should be straightforward, so long as you are upgrading within the 12.4.x line and (often) even within the 12.x.x line.

Updating open source development components is both easier and harder. It’s easier because developers tend to have better automated tests than infrastructure engineers. It’s harder because of the dependency issue. It’s wise to make sure any product SMEs are given sufficient time to build automation around automated patching so their time can then be spent untangling overly interlocked dependencies. The magnitude of such an effort varies drastically from project to project.

Best Practices for Securing Open Source Software

As you work with open source software, it is critical to understand it’s just software and all the issues that apply to traditional closed source software also apply to open source software. To ensure your use of open source software remains secure:

• Check your licensing: While closed source software can have licensing concerns, the prevalence of open source software as development components raises the quantity, if not the magnitude, of this risk, so develop a practice around checking licenses.
• Detect shadow IT: Open source software is often available for free, which means it is more likely to appear as shadow IT. However, a program should be developed to identify and reduce shadow IT, not open source software specifically, because that is where the actual risk is.
• Automate your patching: Whether you’re using open source software or not, the ideal time to patch is immediately; if your practice can’t handle that speed, adjust your practice so it can.
  

Finally, while it is understandable to want risk metrics around open source, the risks do not come from the open source nature of such components, but from the actual use cases, so there are no standard open source risk metrics. Instead, focus on metrics around code quality, patch timing (release on their side, deployment on yours) and how well your people understand the technology they’re using.

Learn How to Maximize Impact with Cost Effective Solutions from IANS

Facing budget pressures to do more with less?  We're here to help. See real results on how IANS clients save time, decrease costs and reduce risk. Go to our new Maximize Impact page - You’ll find tools and guidance that make your job easier. Manage risk while saving time and budget.

Our 150+ Faculty practitioners are here to help you and your team move faster and make more informed decisions. Not an IANS client? Get in touch to learn more.

Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in connection with such information, opinions, or advice.