How to Find, Fix and Prioritize Vulnerabilities in Your Docker Container Image

Patching software systems and securing them from a single vulnerability requires careful steps to ensure validity without interruptions. More specifically, re-deployed images should work as expected and not suffer from side effects. Imagine multiplying that effort by 1,000 and having to tackle multiple containers across your infrastructure.

In this post, we examine the strategies for addressing a large volume of vulnerabilities in a container environment. We describe different vulnerability types and ways to prioritize them. We also discuss emerging technologies such as patch management software as well as more sophisticated container security solutions that have the potential to make organizational experiences with large-scale vulnerability remediation more efficient and effective.

What to Do When Multiple Vulnerabilities Are Detected

So, you’ve logged in on your work laptop and received a thousand emails. Suddenly, your production containers are exposed and have multiple vulnerabilities. Your stakeholders are increasingly anxious after the last security incident and don’t want to hear bad news. What should you do first?

Well, in such situations, you should rely on your Security Incident Response Policy (SIRP) to show you the next steps. This is like a set of pre-approved and necessary security controls to help you detect security vulnerabilities and incidents. In addition, it outlines the processes and procedures to resolve them.

More specifically, you should have a section for vulnerability remediation processes with workflows to fix and neutralize detected weaknesses. If your organization does not have a SIRP, you need to create one ASAP.

If you have established that the vulnerabilities are real, then you need to investigate the scope of those vulnerabilities, find official patches, and assess the real impact they can have. If you’re lucky, only 10 (1%) of the 1,000 vulnerabilities will be critical, which is a more manageable situation.

In your effort to categorize the vulnerability types, you need to check how many of them are related to base images that you control. For example, if the container is based on Ubuntu and all critical vulnerabilities are associated with that base image, then you can prioritize updating the base image on all deployments. If the vulnerabilities are related to the application code that you installed within the container image, the respective teams need to be notified to patch the build steps.

Depending on the severity of the vulnerabilities, you may have to shut down parts of the system to apply patches and ensure that the containers are running efficiently. You need to make sure that all relevant teams are informed about those decisions and ready to assist with any front-facing impacts.

Given that it is very important to prioritize and understand which vulnerabilities pose an imminent and significant risk, we’ll explore those strategies next.

Prioritizing Vulnerability Types

Vulnerabilities in Docker containers come in all shapes and sizes. Some of them are of a purely technical origin (for example, when the network or host OS is affected so that the Docker daemon is also exposed to unauthorized access). There are also vulnerabilities that have non-technical aspects, such as when a human error causes a misconfiguration that means the container images are affected, or when an attacker injects exploits based on the weak security practices of your development teams.

It’s important to recognize that whenever you expose services publicly, there is risk involved – and that includes container-related technologies. Here is what you can do to actively address vulnerabilities in your containers:

Prioritize Critical Issues

Not all vulnerability types have significant risks. Usually, an established vulnerability includes an associated score (like a CVSS score) as well as status and impact metrics. Use such criteria to sort published, high-risk vulnerabilities first, then let the vulnerabilities with more moderate risk and disputed/rejected issues fall to the bottom of your priority list. You can use the following sorting criteria as a guide:

Use Multiple Scanning and Patching Tools

Although you may be committed to one particular vendor for scanning vulnerability types in your container images, you should consider cross-validating those scans with multiple tools. These can surface better contextual information about the scope of the problem so that you can make informed decisions about your next steps. Some tools are better than others for certain procedures. For example, one tool could be better at scanning and another at patching.

Create Security Task Actions

Once you’ve established the work required, you need rapid resolution so that you minimize the risk of exposure. Updating and patching software should be a collective effort; otherwise, you won’t be able to protect it in time. You want to make sure that all relevant parties are aware of the issues and actively working on resolving them. For example, the security team needs to enforce deadlines for patching containers that each team must meet and also post regular updates about the imminent risks associated with failing to patch them on time. That means organizing meetings and interrupting regular development sprints to make sure those patches are deployed in production.

Overview of Emerging Technologies for Container Security

Software security is an ongoing effort to implement mechanisms to protect sensitive business resources. New tools and technologies are invented almost every day to prevent container-related security issues. In addition, organizations now use DevSecOps methodologies to attempt to increase collaboration between security and operations teams.

Let’s explore some of the best tools for preventing security vulnerabilities in your containers:

Tools for Building Secure Containers

By far the most effective tool for building secure containers is the Slim Toolkit. This is an open-source program that you can run via Docker or on its own. It works by analyzing and slimming the final build container images so that they can run in production safely. If an image is compromised, it can help prevent malware or a potential attacker from being able to run or do something to spread the exploit further. When it comes to security, this is a powerful concept to put into practice. Slim reduces the risk of having multiple vulnerabilities in your containers, and it can be easily integrated into your CI/CD pipelines. Slim also offers SaaS tooling that allows you to see a vulnerability diff to analyze which vulnerabilities were removed in the container hardening process.

Tools for Secure Container Connectivity

There are tools that provide a safe and secure environment so that if you have multiple vulnerabilities in your containers, the damage can be isolated within a specific sub-system. For example, Calico and Cilium are both open-source software for providing, securing, and observing network connectivity between container workloads. They can be used to add network security policies, adopt Zero Trust protocols, and limit privilege escalations. If the environment of an infected container is secure by default, then the impact of those vulnerabilities is limited.

Tools for Container Scanning

There are myriad tools that perform static or runtime analysis of known vulnerabilities by scanning periodically. The most notable ones are Grype, Dagda, docker-bench, and Clair. You can set up these tools to run either as part of a CI/CD pipeline or as self-hosted services, and they’ll scan your containers for vulnerabilities. This way, if there are indeed thousands of vulnerabilities in your containers, you will be notified early.

Other Technologies

Falco is a great security threat detection engine that can be used to programmatically add checks and alerts for any type of suspicious use of Linux system calls. You deploy it in K8s as a DaemonSet and then customize it with Falco Rules.

MLSecOps technologies can also be adopted to create an early detection system and prevent the proliferation of vulnerabilities. The idea is that you train models for both secure and unsafe configurations for Docker images and predict if a configuration is insecure when you submit it for deployment. This way, you get an increased chance of detecting and preventing issues in your containers.

Conclusion

In this article, we provided some practical guidance for handling multiple vulnerabilities in your containers. It's important to understand the reasons why vulnerabilities can accumulate and what to do to help keep your containers safe.

Organizations using containers must adopt container security best practices to respond to any incidents. Automated tools like Slim.AI can help you remove vulnerabilities and reduce risk early in the development process.

We hope this article helped you learn a little bit more about slimming your containers. Feel free to drop your questions in our Discord (https://discord.com/invite/BmT5hRrZp6) or dive into to the Slim Platform (https://portal.slim.dev/home) any try it for yourself! We'd love to hear your feedback.