How I Fixed Open Source Security Issues for my Application

Writing secure web applications is something that everyone wants. For this, developers use the best practices forimplementing different sensitive techniques, like a login system or a DoS protection, and sometimes they even test the application themselves to see if they can hack something.

The security of the code you write is 100% in your hands, and you have total control over it.

But what about all the open-source code you integrated via different libraries or modules? No one expects to reinvent the wheel and write everything from the ground up, but how do you maintain your application's overall stability if there are parts you can't control? This is where open source security measures come in. Here are the principles and advice I followed.

Security-First Culture

Most of the time, developers choose the open-source components based on their functionality and ease of use. While this is good for your development process, these are not the first things you should consider when creating secure software.

Image Source

A security-first culture means that the decisions you make when adding new components to your application meet the following criteria.

License Compliance

Before using any third-party code within your software, be sure that you can comply with the license under which it is released.

The application in which you integrate the open-source components must comply with each individual license.

Even though open-source software is viewed as free, it's no different than any other software managed by a license. Therefore the way you intend to use the open-source software must be in concordance with what its license allows you to do: use, modify, or share under defined terms and conditions.

Although there are many licenses in use, OSI (Open Source Initiative) lists only 82 approved licenses.

Active community and development

Once you validate that you can comply with the license under which an open-source component is released, the next step is to validate its community.

Here you should check who else is using this component and how many developers actively support and improve it.

Everything has a start, including software. If you found a module that you need to integrate into your application, but it's still new and not widely known and used, then be sure that the developer/developers behind it still maintain it.

Known issues

The next step is strongly connected with the previous one, and it's about inspecting the project's known issues. This approach is a good way to see if the project is actively in development. If many open issues do not receive an update for a long time, then the chances are that the support for the project is reduced.

Although it may not be a severe security issue now, it may become one in the future.

The problem is that the open-source vulnerabilities and their path of exploitation are publicly published across a wide variety of platforms. From that point, a race begins between the hackers and the developers. Malicious people will try to abuse this vulnerability; they have time to do it not only until the patches are released but also until the targeted software will take over these new patches. That's why it is necessary to have tools and processes to find and address these issues quickly.

Use components from trusted environments

A good security practice is to install and use tools, software, and everything only from secure and reliable environments.

Nowadays, when it comes to open-source software, this situation is addressed by default because there are many centralized platforms from where one could download open-source code.

Back in the day, when there were no platforms like npm or NuGet, most software, including open source libraries, wasself-hosted. The problem with self-hosted components is that you don't know what you are downloading, and there is almost no transparency between you and the project.

On the other hand, code in a centralized repository is continuously audited and verified. The entire community, both developers and users, actively detect and remove problematic open-source software. Thus, the potential security risk is much lower than if you downloaded it from "original sources."

There are many good examples to validate this; one is the package electorn –- a typosquatting package that, once installed and in use, was broadcasting the user's IP address, username, and device fingerprint information on the web. These kindsof unsafe packages, when discovered, are reported by the community and consequently removed.

Use Scanning Tools to Detect Vulnerabilities Automatically

Open-source software must be kept up to date, but when you have dozens of modules, it can be overwhelming. Usually, once a vulnerability is spotted in software, it is listed in a vulnerability database like the National Vulnerability Database(NVD).

It's very difficult for someone to manually check and constantly follow all updates regarding the open-source components in their projects. Luckily, we no longer need to do this, because there are automated tools that can do it for us.

One of these tools is WhiteSource Advise. This tool can be directly integrated in your IDE if you use Visual Studio, Visual Studio Code, Eclipse, or IntelliJ. WhiteSource Advise examines components added to a dependency file andhighlights any vulnerabilities, if present, while also suggesting fixes.

Some of the insights that it will return are the CVE (Common Vulnerabilities and Exposures) ID and CVSS (CommonVulnerability Scoring System) Score.

You can install it through the extensions tab that you have in your IDE and active it using your email and license key.

Once the extension has been activated, you can use it to scan your project. It will search through your code to see if there are any known open vulnerabilities associated with your dependencies. Problems found will be displayed directly in the IDE along with a possible solution.

Train Yourself and Your Developers

Lastly, you can never go amiss with security training. A general understanding of cybersecurity, as well as the latest trends and updates, should help developers identify, protect from, and fix common security issues that arise in open-source code and otherwise as well.

Similarly, if there is a security team for the project, they should be kept involved from the early development phase. This not only will help teams spot problems in the early stages, but they will also have time to address them or replace the vulnerable components.

Wrap up

Open-source software should be reviewed more carefully. Rather than a simple and innocent free-to-use third party module that you incorporate in your application and will work with 0 side effects, it should be approached with more care.

Open-source can be secure because the community is actively engaged in monitoring and improving the project. However, this does not mean that we have nothing left to do and everything is being taken care of for us. In the end, it depends only on us what we use in our projects and the side effect that it has.

After all, that's what the most common open-source licenses say "THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND" –- a fragment from the MIT license.

Cover Photo by Arif Riyanto on Unsplash