5 Tips for Managing Your Open Source Components Wisely

According to a recent report published by an independent research analyst, 96% of the commercial applications contain open-source components and dependencies. The report also notes that on an average, each application has around 257 open source components. As the stats suggest, the number of open source components in a proprietary codebase is growing.

Encouraging developers to use open-source code isn’t a bad thing in itself. The development of open source software is very often a collaborative effort that involves a number of individual contributors. The contributors try to maintain the component by fixing bugs and adding new features over an extended period of time. But what happens when a library loses its popularity and the project developer decides to abandon it altogether?

That’s what we will be covering in this post. For a modern business to ensure its competitive advantage in the market, it is forced to leverage the benefits provided by open source software. However, this effort shouldn’t be at the expense of your product’s security. In this article, we discuss the top 5 tips for practical open source vulnerability management.

Patch Management

A centralized framework to manage software patches is perhaps the most critical aspect of OSS ecosystem. It ensures that third-party patches are applied to your company’s infrastructures in a timely manner. It is important to note that most cyber-based attacks happen when a security hole or a vulnerability is discovered. The exploiters could potentially use it to breach the system before an organization could respond to a vulnerability. The only way to counteract this is via a proactive approach.

Having a good patch management strategy is crucial to keeping your open-source components secure. Your company’s security head need to keep a keen eye on the vulnerabilities of the OSS to identify the patches that are required.

You should keep a record of components in use and track the vulnerability status of such components. There are many Software Composition Analysis (CSA) tools out there that help you build an inventory of the open source components you use and analyze them for security risks.

Choose Your Dependencies wisely

When you use a non-standard library that isn’t in active development, there is always a probability that a new vulnerability could emerge in the future, and that there will be no one around to patch it. Although that particular library might appear to be the exact fit for your use case, you are essentially copying its bugs and any inherent vulnerabilities along with it.

Instead, go for the popular alternatives. When you find something with a lot of stars on GitHub, chances are that there are a lot of people reviewing the code. Although code review doesn’t guarantee security, chances are that if a vulnerability is exposed, someone will be there to patch it.

Also, avoid copy-pasting library files from the Internet at all costs Once you copy and paste a snippet, there is hardly any way to track that snippet and update it for software bugs or security vulnerabilities. Instead, look for similar modules in your repository so that you can pull updates from the upstream.

In the off chance that the code is error free, you need to consider the implications when a new version of the code is released. Upgrading a version of the code can be a daunting task unless you are using a component like ‘as is’. If not, you are left with no backup compatibility.

Have a Standardized Policy

Organizations across the globe have a varied potential for risk largely based on their captive market and maturity. It is, therefore, critically important for an organization to have an established set of policies and guidelines that lay out the terms regarding the use of any open source software.

In the absence of such guiding principles, it is possible for the development teams to assume the right to freely use any and all open source software components which might result in a product or service being shipped with vulnerabilities or with incompatible or hostile software licenses.

Once a particular software has been released, it usually proves to be cost and time intensive for a company to reactively address any untoward effects that surround the use of its open source components. A robust pragmatic policy would ensure that the use of highly vulnerable software components is highly inhibited.

Monitor When You Need to Update

According to a recently concluded survey, 1 out of every 16 open source components contained a security vulnerability. Additionally, there were numerous other libraries that contained a number of severe and critical software bugs.

Though a majority of these problems might get fixed in newer versions of the software, they would be difficult or almost unnoticeable if you were not tracking your inventory yourself. Unfortunately, in most cases, they would perhaps only come to light when someone with malicious intent breaches your application.

Let’s take an example. A vulnerability was discovered recently in a package called eslint-scope which is a dependency of several popular JavaScript packages such as babel-eslint and webpack. The account of the package maintainer was compromised and malicious code was added to the package. Gladly, someone found out the exploit quick enough and the damage was reportedly limited to a few users.

More such instances are likely to happen in the future unless serious security measures are taken to prevent them from happening in the first place. So, what can you do? Monitoring the open-source libraries and keeping an eye on credible security reports should help you build awareness about the latest vulnerabilities in your components and limit the damages if any. You could then try updating or removing the particular library that is affected.

If you do come across an update that you would need for one of your software components, it is important to keep in mind that it could actually break compatibility with your code. What this means is that you might need to write and perform a few tests to prove the functionality of the library you use. An added benefit, though, is that these tests can also double up as an added documentation on how the library can be used.

Understand How to Remediate

As an enterprise owner, it is important to understand how you can continuously assess risk from vulnerabilities when it comes to using open source and open source components.

As and when any new risk is detected and identified, your company’s security team needs to proactively coordinate with the development team to remediate the breach. The best practices for such remediation differ and depend mainly on the complexity of the product and the component.

An advisable and pragmatic approach is to first identify if the known vulnerability is exploitable to a degree, and if so, whether a closely matching, non-vulnerable library can be used in an effort to minimize any collateral impact if possible.

Conclusion

To conclude, it is important to emphasize that open source components are the way for the future and are definitely here to stay. They are fast becoming the driving force for rapid development and innovation taking place in the modern enterprise.

However, this widespread popularity and use also lead to systemic risk. All organizations globally need to get a proper understanding of the various open source components they use within their respective development teams. They also need to understand the paramount need to create and enforce a strict policy and set of best practices that can help deteriorate any security vulnerabilities while, at the same time, keeping development and innovation unhindered.