Chainguard Adds Support for Multi-Layer Hardened Container Images
Chainguard has added support for multi-layer images to its repository for accessing hardened container images that are free of vulnerabilities.
Jason Hall, principal engineer for Chainguard, said that while it has been possible to use multi-layer Docker images for many years now, the declarative apko tool that Chainguard developed to create hardened Chainguard Container images lacked the ability to use layers to package distinct parts of the filesystem as individual archives. Container runtimes use these layers for caching and deduplication and if multiple images share the same set of layers, developers only need to store and download them once.
If there is only a single layer container image option that means that any update requires users to download the entire image again. Eventually, downloading entire images takes its toll on everything from pull times and bandwidth usage to overall developer velocity. That’s become a more pressing issue now that large, complex, third-party applications such as PyTorch and TensorFlow are being deployed using container images, noted Hall.
Now a large hardened image can span multiple containers to help reduce the size of an image in a way that ultimately serves to improve overall performance using a “per-origin” strategy, where packages that derive from the same upstream source are grouped into the same layer. That approach results in, on average, a 70% reduction in the total size of unique layer data across the Chainguard image catalog and a 70-85% reduction in the cumulative bytes transferred when simulating sequential pulls of updated images.
Chainguard also added an additional final layer that captures frequently updated OS-level metadata, developed intelligent layer ordering to optimize compatibility and ensured sufficient layer counts to optimize parallel downloads by container clients.
It’s not clear how widely employed hardened container images are. While the need for them is apparent, old developer habits tend to die hard. Many still pull container images from public repositories without much regard for the vulnerabilities that might be included. However, as more responsibility for application security continues to shift left to application developers, many of them are starting to have a greater appreciation for hardened container images.
There are, of course, now multiple repositories through which application developers can access hardened container images. Chainguard, however, has already hardened more than 1,300 container images to create one of the largest repositories.
Regardless of approach, the easiest vulnerability to remediate is the one that was never created in the first place. In fact, nothing slows the pace of application development and deployment down more than a vulnerability that is discovered just before an application is supposed to be deployed. As such, one of the ways that application developers can accelerate the pace of application development is to eliminate vulnerabilities before they are discovered in a software build, or worse yet, in a production environment.
After all, the one thing no application developer wants is to be called out for not fixing the one vulnerability that resulted in the organization having to choose between missing an application deployment deadline and deploying software that might enable one or more exploits to wreak all kinds of cybersecurity havoc.