Containers have become the gold standard for building modern, cloud-based software. It’s no surprise – using containers for app development has plenty of benefits, such as making code more portable, creating consistency across environments, and offering more efficient use of development resources. 

However, there are some downsides. Many containers are riddled with unchecked security vulnerabilities leading to misconfigurations, runtime attacks, and software supply chain compromises. According to a study on security priorities conducted by Foundry, 90% of organizations’ security dangers stem from container vulnerabilities. 

So, how do you combat this? Prioritizing container security. In this article, we’ll define container security, explore the most common threats, and introduce actionable best practices to help you secure containers within your applications.

What is container security? 

Container security is the set of standards, processes, and actions involved with safeguarding containerized applications from cybersecurity threats across the entire software development lifecycle (SDLC), from development and deployment to runtime.

Typically, container security involves securing the following vulnerable areas:

  • The container image (using trusted base images, scanning images for vulnerabilities, minimizing container size, verifying images, etc.)
  • The runtime environment (limiting privileges where possible, reinforcing runtime profiles, enabling read-only file systems, limiting container capabilities, etc.)
  • The orchestration platform (using access controls, setting strict network policies, enabling audit logging, etc.)
  • The host system security (hardening the host OS, keeping the kernel up to date, using namespaces and cgroups properly, etc.)

Engineering and DevSecOps teams can fuse container security into their software development and security strategy by ensuring container security processes, like image scanning and policy checks, are fully integrated in the CI/CD pipeline. 

The most common threats to container security

Despite the host of benefits containers offer for application development, they also come with a unique set of challenges and threats to consider. For context, a highly impactful recent example of a container security threat is the CVE-2024-21626 vulnerability in runC, discovered in early 2024. This critical flaw, part of the “Leaky Vessels” vulnerabilities, allowed attackers to achieve “container escape” – breaking out of the container’s isolation and gaining access to the host operating system. Such vulnerabilities are particularly dangerous as they can lead to full system compromise, enabling attackers to steal data, execute arbitrary code, or disrupt operations on the underlying infrastructure.

Image vulnerabilities

Both image vulnerabilities and outdated dependencies give bad actors a window to exploit vulnerabilities within your application. 

Any layer within the container image, including the application code, dependencies, and base operating system, could be compromised. Since attackers can automatically scan vulnerable container images and open CVEs, and because images tend to be widely reused within applications, there could be multiple points of exploitation for attackers to capitalize on.

With outdated dependencies, bad actors can look for unpatched bugs that could potentially leak data or even provide unauthorized privileges. Dependencies present an elevated risk because developers might not even realize they’re using outdated or vulnerable packages – especially when it comes to open source software usage. This underscores the importance of creating, maintaining, and using a curated open source software catalog to pull safe and ‘approved’ images and code from.

Misconfigured Dockerfiles or Kubernetes manifests

Using misconfigured Dockerfiles or Kubernetes manifests could risk your ability to secure containers within your application. Misconfigurations can accidentally grant unauthorized, excessive user privileges, expose data, and even weaken isolation efforts, making it easier for attackers to get into and manipulate the underlying system.

Privileged containers and insecure networking

One key way to keep applications safe is by isolating containers from the host and each other. Unsecured privileged containers present a serious risk to container security because they can break key security boundaries. A privileged container is a Docker container that has all capabilities enabled and full access to the host machine’s devices and resources, essentially removing the isolation typically provided by containers. This means it can perform almost any action that the host operating system can, posing a significant security risk if compromised. One container exploit could lead to the entire system collapsing. Plus, insecure networking increases the attack surface, and the chance of data leaks and an internal system compromise.

Supply chain and registry attacks

Supply chain risks look at vulnerabilities created upstream. Essentially, you’re opening the front door and inviting risk inside. Attacks within the supply chain target the very software containers function on – even before they reach your environment. 

Supply chain attacks could include compromised CI/CD pipelines, build tools, and dependencies. With registry attacks, bad actors could upload dangerous images to public repositories that you could unknowingly use within your applications.

Runtime exploits and lateral movement

Unfortunately, your containers aren’t automatically safe after they’re deployed. Both runtime exploits and lateral movement can be significant threats to live containers.

Runtime exploits could potentially compromise both the container and entire system through app bugs and misconfigurations. Once inside one container, an attacker could move laterally to get inside other containers, furthering the damage.

Container security best practices for engineering teams

Now that we’ve covered the main container security threats for your engineering team to be aware of, let’s walk through practical best practices for addressing them.

1. Use minimal, trusted base images to improve your container image security

Images are one of the weakest points for container security. You can help mitigate the risk by minimizing the image itself. Your goal is to include the least possible number of things required, so there is a smaller attack surface and fewer components to keep up-to-date. When using base images, ensure they are from a trusted source. Being extra thorough, especially when reusing images across multiple containers, can help you avoid bad actors getting in.

2. Perform container security monitoring and scan container images early and often

When you do use images, ensure you’re scanning container images early and frequently. So you know that whenever you’re using images within your applications, they’re safe.

3. Apply least privilege to containers and orchestrators for containerization cyber security

Giving each component the bare minimum access it requires to function properly within your application is a key part of minimizing risk and moving towards secure containerization. 

With higher-level access comes increased opportunity for bad actors to make potentially severe and costly changes. By applying least privilege, you ensure that if someone does manage to obtain unauthorized access, the damage they can do is limited and more controlled.

4. Keep images updated and rebuild frequently

How often are your containers reviewed? They can be at risk; they’re often outdated and potentially vulnerable. So, one of the best ways to reduce container security exposures is by keeping images updated and rebuilding frequently. 

Libraries and packages receive frequent security updates. Even official base images, like Ubuntu, Node, and Python, are patched quite often. Rebuilding and regularly revisiting container images ensures they include the latest most up-to-date patches, dependency fixes, and security hardening, keeping your applications safe.

5. Secure the entire CI/CD pipeline with container security best practices

Focusing on your CI/CD pipeline is essential because it forms the important connection between your code and production. If your CI/CD pipeline is tampered with, it could mean vulnerabilities are in your code before they are even made live. A few ways to secure your CI/CD pipeline are:

  • Storing sensitive information or secrets like API keys, tokens, and passwords in secret managers or vaults
  • Using least privilege
  • Using tools to sign images and verify signatures before deploying
  • Isolating your build environments
  • Keep your CI/CD tools up to date
  • Building from source

6. Implement runtime threat detection for proactive container protection

Container runtime security is important, because it can help you stay proactive and catch suspicious activity in real time. Consider adopting a container runtime security tool that can provide alerts and block unsafe behavior, so no attacks go undetected by your team.

7. Enforce Kubernetes security best practices and policies

Maintaining and enforcing strict Kubernetes container security policies helps ensure you’re only allowing compliant workloads to run in your cluster, preventing risky configurations from being deployed. Security policies can include rules for:

  • Container settings
  • Pod behavior
  • Network usage

These policies help your team prevent misconfigurations and maintain Kubernetes security best practices across your apps. 

8. Segment container networks for improved container protection

As mentioned, bad actors who are able to break into a container and then move laterally to attack other containers can wreak havoc on your apps. Since many containers can communicate openly by default, you may not even realize that the containers you’re using within your apps are vulnerable.

To combat this, ensure strict network segmentation by reviewing your containers to set rigid rules and limit which containers are able to speak to each other. 

9. Practice strong container image security by signing and verifying images

The source of your images matters. Before using and deploying images within your container, you need to make sure they are from a trusted source and haven’t been tampered with. 

For good measure, ensure your policy enforcement tools are also set up to reject any unsafe images you may accidentally attempt to deploy. 

10. Regularly audit and monitor container activity

Container security – and cybersecurity in general – is not a set-it-and-forget-it type of practice. Continuously auditing and monitoring container activity will help you identify vulnerabilities and suspicious activity, and take action.

–

For enterprises and large engineering teams, the idea of finding the capacity to consistently monitor containers for security concerns may seem daunting. Luckily, advanced vulnerability management  and remediation tools exist that can offer advantages and real time savings. 

Don’t search the internet for the necessary pieces to run your software. Customize your containers with the most comprehensive open-source component catalog on the market. Our decades of experience building from source creates an unmatched repository of known-good build data, enabling us to drastically increase build success rates for even the most complex dependency chains.

Container security is a shared responsibility. As teams shift security left, Developers, Security Engineers, and Devops Managers  all need to step up to implement and uphold container security best practices. A trusted platform can help unify and automate these efforts, keeping everyone working towards the same goal. 


Learn more about how ActiveState can help you reduce your attack surface by over 70%. Book a demo today.