Avoiding Open Source Vulnerabilities for Applications and Containers

Photo by KeepCoding on Unsplash


The world has changed in the last year; by choice or by force, more and more people are now online. With this large-scale transition to the digital world, cybersecurity has become critical when developing applications.

Zoom learned the hard way that when more people come to your platform, issues come with them, too. Because a significant percentage of commercial softwares rely on open source codes and many contributors write these components, lapses in security are to be expected. The code may unintentionally have bugs and errors, or malicious contributors may have inserted vulnerabilities.

Either way, it’s vital to be able to find them so that your application is not compromised through a cyberattack. In this article, we cover some ways to safeguard your application.

Methods to Protect Your Application

When you deploy your application, you will be using open source software on two basic components: the application itself and its containers. 60–80% of the code in any application is open source. Using open source to build your application can be very convenient because it saves time and money, but it comes with an issue: open source components may contain vulnerabilities.


To minimize vulnerabilities in your application, your company can train your developers in security and make sure they know how to write secure code. However, when using open source software, for instance, a library from Github, you don’t know if the author of this library has been trained to write secure code. The library may contain vulnerabilities because the author made harmful mistakes. We also need to consider the possibility that another person contributed to the library and inserted malicious code. This, too, would turn your application into a security risk.

Best practices for Applications


Most of the time, we will be safe using the latest version of any component we are getting from the open source community. Those versions have already been scanned for vulnerabilities by many people. Yet, there may be hundreds of thousands of vulnerabilities in the open-source components you end up using. Therefore, we need to prioritize which ones to tackle.

There are different ways to prioritize additional criteria to apply. The most crucial aspect to consider is how any given part of our application impacts the business if it gets compromised.

If a database with personal information is compromised, our business will be severely affected, but other components do not have such a serious impact.

Auto Remediation

Ideally, you would like to fix all your vulnerabilities, but that is not feasible simply because there is not enough time to do it. So, we need to address automatically everything that can be managed in such a way.

For example, we can automatically open pull requests, merge the fixes, and run tests. And once all have passed, we can decide to upgrade it to production.

Part of this automation is the alert system. If we get an alert for every vulnerability detected, we will get overwhelmed and ignore all the alerts. So, we need a tool that automatically filters vulnerabilities and, based on some criteria, only alerts us on those that can affect our business and pass those to us to fix them.

Open Source Vulnerabilities in Containers

A container is an isolated environment for running an application. Containers pack softwares into standard units for the development, shipment, and deployment of an application. These standardized units contain everything needed to run an application: code, runtime system tools, system libraries, and settings.


Containers are getting more and more popular and are a great way to scale any application. But consider that if someone gets access to one of the containers where your application is running, he can easily gain access from there to the whole application, so here are some good practices to consider when working with containers.

Best Security Practices for Containers

1. Lightweight containers

Lightweight containers can significantly improve the security of your application by reducing possible attack points. You should only employ the tools and libraries needed on each container and clean up everything that is not explicitly required, like:

· Shells used only in the development and testing phases

· Package managers

· Administration tools

Once again, anything not needed should be taken away. A good option is to use the distroless container from Google. These images contain only the application, its resources, and language runtime dependencies, no operating system distribution, thus reducing the risks to security.

2. Use only trusted sources

Anyone can upload to DockerHub. Be sure to use only images from sources you trust, especially when using orchestrator software like Kubernetes or Docker Swarm. You do not want to replicate hundreds or thousands of vulnerable containers running your application at any given time. You can even sign your checked images and check them before deployment, just to be sure those are the ones you tested.

3. Never run as root

No component of your application should be run as root on the container; doing that and simultaneously having an error in the code maximizes the possibility of a hacker gaining access to the application. Even though a software might have been tested and reviewed, there will always be some code with errors that will go into production. So make it run only with the minimum privileges needed for it to work.

External help

You can also use external help from the people who are working 24/7 on searching and following open source vulnerabilities. Every vulnerability found is registered in a database where you can locate them and find a solution before it affects your application.

One of these services is the WhiteSource Vulnerability Database, the largest free database full of documented forms of open source vulnerabilities. You can look for specific vulnerabilities through their CVE ID or project name across 200 different programming languages.

You can also consider Black Duck’s Open Source Knowledge Base. Their information is curated by Synopsys’ Cybersecurity Research Center which covers 3.9 million+ open source components.

Last but not least, with Cisco Secure Application, your company can detect application code dependency and configuration-level security vulnerabilities in production with automatic runtime protection. Additionally, you can block exploits automatically and prioritize your response based on business impact.


The impact of the pandemic has changed our work and education habits in the last year. Activities like work from home, distance learning, and even remote social gatherings have become part of our lives now. With this shift to the internet, we have to focus our attention on the security of our applications. A breach in security can severely impact our business.

Nowadays, applications are composed of open source software, which is a great advantage because your company does not need to invest time in building something already developed by third parties. But you need to develop and maintain your application in a secure manner. Luckily, there are third-party commercial options that can help you find vulnerabilities and fix them.

I like writing, I am not too good at it, but I enjoy writing anyway.