Containers are now a common tool for packaging and deployment of modern software. They provide developers a uniform environment that can be carried from a laptop to a testing platform and then into production. But a regular container image can contain a lot more software than an application needs. Unused packages, libraries and tools can add to the number of potential security weaknesses.
That's where hardened container images come in handy. They are intentionally designed to minimize the attack surface and eliminate unnecessary parts and stricter security controls are applied before an application is deployed. Hardening is not considered a final scan, but rather as a part of the image-building process.
What Makes a Container Image Hardened?
A hardened container image is an image that has been thoroughly configured for use in a container. It typically includes only the operating-system components and runtime libraries and workload application dependencies needed to run the workload.
General-purpose images can contain shells, package managers, debugging tools, network utilities and other software for convenience. These features can be beneficial when developing, but can be an extra risk when in production. The tools can assist the attacker in scanning the container environment and loading other software or advancing deeper into the system if the attacker is able to compromise the container.
A hardened image eliminates a lot of these components. It can also have secure default permissions, run the application as a non-root user, and deny access to sensitive areas of the file system.
Fewer Packages Mean Fewer Vulnerabilities
One of the primary reasons for fewer vulnerability alerts with hardened images is that they have less software.
Multiple libraries and dependencies are possible in each package installed. Each of those could have a known security problem. Thus, if the application includes a large base image, hundreds or even thousands of findings can be produced during a vulnerability scan, even if the application only uses a small portion of the software in the image.
Unused packages are eliminated, thus minimizing the number of packages to monitor and patch. It also simplifies the comprehension of vulnerability reports as security teams can concentrate on problems which are directly relevant to the application.
While a smaller image doesn't necessarily mean it's more secure, it does mean that there are fewer possible entry points for an attacker.
Continuous Rebuilding Reduces Exposure
Hardened images tend to be rebuilt more often than traditional container images. If a security patch is released for the upstream package, the image provider can update the package and publish a new image.
This model of continuous rebuilding helps minimize the amount of time known vulnerabilities are in production images. It also pushes organizations to migrate to newer containers instead of manually trying to patch running workloads.
Rebuilding frequently is important since images of containers are often shared between many applications. Weaknesses that exist in a base image can be propagated to other services, teams and environments. Updating the shared foundation can thus eliminate risk on a large scale.
Secure Defaults Limit the Impact of an Attack
Hardened images also help to make exploitation more difficult. A common example is running an application as a non-root user. In the event of an attacker exploiting the application, the attacker may only have limited access to the application and not have complete access to the container.
Other controls include read-only file systems, lowered Linux capabilities and the elimination of unnecessary executable tools. While these measures don't stop all attacks, they can limit what an attacker can do once he or she has accessed a system.
Secure defaults are particularly crucial in large cloud deployments where a single insecure container can become a pathway to other services or to sensitive data.
Hardened Does Not Mean Invulnerable
Hardened images may have vulnerabilities. Application code can be flawed, credentials can be exposed, or the container could be deployed with too many permissions. Even if an image has few CVEs reported, it could be hazardous if it is improperly configured.
Security teams also need to determine the source of the image. Digital signatures, software bills of materials (SBOMs), and build attestations can help verify the image's provenance and provide insight into what is included.
There is still a need for runtime monitoring. It is important for organizations to monitor post-deployment network activity, processes, and access to restricted resources that may be unexpected or unusual.
A More Manageable Foundation for Container Security
The biggest benefit of hardened container images is that they do not solve all security issues. What they offer is a way to cut down on unnecessary complexity.
Hardened images provide a clean foundation for development and security teams, removing unused software, applying patches quickly, and introducing safer default configurations. Fewer packages to scan, fewer vulnerabilities to explore and fewer tools that an attacker can exploit.
This can significantly affect the operations of organizations that operate many containers. Security teams can spend less time on lower-value alerts and more time on security issues that could impact the application. As a result, hardened images can enhance security and vulnerability management.
Comments
Loading comments…