What is Container Hardening?

Developers around the world adore software containers thanks to their portability, scalability, and efficiency. They are the backbone of today’s microservices-driven architecture. According to a recent survey by Dell, more than 50% of enterprise applications are in containerized environments.

Because containers are built on open source, container registries like Docker Hub offer free downloads of hundreds of thousands of software packages. But is it wise to download a free container image and run it in production? Probably not.

Just because a container image is popular or distributed by a trusted source doesn’t mean it’s safe or secure to run in your infrastructure. In fact, it’s highly likely that any container you download online comes riddled with security vulnerabilities and risks. This is why you need container hardening.

What is container hardening?

Container hardening is a two-step process:

1. Scan a container for vulnerabilities, and
2. Remediate as many of the vulnerabilities as possible

Software Component Analysis (SCA) scanners detect security issues such as Common Vulnerabilities and Exposures (CVEs). Scanners are important security tools and check against vulnerability databases like cve.mitre.org.

A container can never be perfectly safe. Even small containers can have vulnerabilities, and even hardened containers can have undiscovered vulnerabilities. Open source builds upon open source, using dozens (if not hundreds or thousands) of software dependencies. Software is written by humans—and humans write buggy software.

Hardening a container minimizes its attack surface, which makes it more secure. It does not eliminate the attack surface. Hardened containers are still likely to have vulnerabilities, but the risk of a breach due to known vulnerabilities is as low as possible.

Why is container hardening important?

Nobody wants their production infrastructure breached by malicious cyber attacks. The after-effects of a breach are laborious, expensive, and could put a company out of business.

Hardening containers does more than protect infrastructure from attacks and breaches:

• Meet compliance requirements: Industry-specific regulations may require security teams to secure their applications and data to specific standards. By hardening containers, teams can meet those requirements and avoid company responsibility for punitive action or fines.
• Attack surface reduction: Hardening removes unnecessary software packages and disables commonly-exploited services or ports. These tactics make it much harder for a bad actor to have a successful attack and reduce the risk of a breach.
• Develop a culture of proactive security: When product teams get serious about security, they develop automated workflows and implement security tools that improve their security without compromising on throughput.

Container image hardening is an important practice that every organization should take to protect their applications and data from attack; meet compliance requirements; reduce their attack surface; and develop a culture of security and trust.

What’s the difference between container hardening and VM hardening?

Containers are portable software packages that run on a Linux-based host operating system as separate processes, like an application. Virtual Machines (VMs) are entire computing environments in a single file. VMs emulate a computer system that can run its own operating system and applications as if it were a physical computer. A VM file contains its own hard drive storage and uses a share of a host computer to execute its internal processes. 

In principle, container hardening and VM hardening are practically the same thing: run a vulnerability scan, then remediate detected vulnerabilities. However, the actual work of scanning and remediating is quite different. VMs contain an entire operating system, such as Microsoft Windows Server 2022, and all of the applications that may or may not be needed to run on that virtual machine. It works and appears as a completely separate computing device on a network.

This fundamental difference between the two technologies means that VMs have a much larger attack surface than a container. Containers only include the necessary components to run the applications they contain. VMs include much more. Hardening a container is much less complex than securing a VM image.

VMs, however, are much more isolated than a container. They are self-contained, whereas a container shared resources with its host. If an attacker gains access to a VM, they are likely to have less access to the host system and the surrounding environment than a container breach.

Because containers are more scalable across the development lifecycle and better suited for dynamic provisioning, they may require more careful management to ensure security across a large number of instances.

Are there standards or best practices for hardening containers?

Container image hardening does have best practices, but there’s not really a set of standards to determine whether a container is properly or sufficiently hardened. Infrastructure and application security can be a sort of cat-and-mouse game because new vulnerabilities are discovered in existing software on a regular basis, just as we saw with Log4j in 2021.

Every organization has its own requirements and acceptable risk levels for security. Some organizations may even have varying requirements across departments or lines of business. However, the widespread proliferation and adoption of open source software has gotten attention from the federal government. For example, the U.S. Department of Defense (DoD) has its own container hardening process guide which can be a helpful indicator and the White House has issued an executive order to improve federal cybersecurity. 

Some of the emerging best practices for Docker container hardening include:

• Container image scanning and generating software bills of materials (SBOMs)
• Using minimal and secure base images
• Keeping container packages and dependencies updated
• Eliminating unnecessary and unused software packages
• Disabling unnecessary services and ports
• Using built-in security features of container orchestration platforms (e.g. Kubernetes, Docker Swarm)

The container image hardening process

A comprehensive set of container security best practices is illustrated in the figure above. Every step can be deployed via automation in a standard CI/CD pipeline.

• Build your containerized app

• Use the latest patches and package updates

• Instrument the container for SCA scanning and SBOM generation
• Exercise the container with coverage scripts (not QA tests, but functional usage execution)

• Generate an inventory of known vulnerabilities
• See what software packages are used and which can be deleted

• Harden the container
• Run your tests on the container
• Deploy the container

The hardening process should:

• Apply a set of minimally-viable configurations (enable ports and services)
• Remove any software components that are unused by the application (discovered via coverage scripts)

A hardened Docker container should have the smallest possible attack surface based on the risk tolerance for running that container in production. This should be measured against organizational security and operations standards (e.g. “No critical vulnerabilities allowed in production”), fully documented and auditable, and—wherever possible—fully automated.

Get container security today with RapidFort

RapidFort is the world’s first Software Attack Surface Management platform, built and designed from the ground up by software developers and security professionals. You can harden containers for free on our software attack surface management platform.