Containers are created using a container image, and a container image is created using a Dockerfile/Containerfile that includes instructions for building an image.
Considering the patch management and vulnerability management for containers, let's focus on container images, the most dynamic component of the supply chain.
In the container management workflow, most of the exploits are encountered due to various security gaps in container images.
As the name indicates, these base images are used as parent images for most of the custom images that are built within the organization.
Enterprise Images Custom images are created and built from base images and include enterprise-specific components, standard packages, or structures as part of enterprise security and governance.
Application Images These images are built using enterprise custom images as a base.
Builder Images These images are primarily used in the CI/CD pipeline for compiling, building, and deploying application images.
These images are based on enterprise custom images and include software required to build applications, create container images, perform testing, and finally, deploy images as part of the pipeline.
Similar to traditional patches provided by vendors, image owners proactively patch these base images to mitigate security issues and make new versions available regularly in the container registries.
These images are created by organizations using base images to add enterprise-specific components to the image and harden it further for use within the organization.
If the base image changes in the external registry, the enterprise custom image should be updated to use a newer version of the base image.
The same workflow should be followed to update any of the downstream images, such as application and builder images that are built using Enterprise custom images.
As far as COTS images, the same process is followed by the vendor, and consumers of the images have to make sure new versions of images are being used in the organization.
As far as mitigating such vulnerabilities, the process involves the same steps mentioned in the patch management section; i.e., updating the Containerfile to create a new Docker image, rescanning the image to make sure reported vulnerabilities don't exist anymore, testing the image and publish it to image registry.
As per the hierarchy mentioned in image-1, all downstream images should be updated with the new image in order to fix the reported CVE across all images.
Along with these tools, scanning tools should be made available so that developers can scan images pulled from external registries to determine if those images are safe to use.
Build Time Scanning Integrate image scanning tools in the CI/CD pipeline during the image build stage to make sure every image is getting scanned.
Performing image scans as soon as the image is built and determining if the image can be published to the image registry is a good approach to allowing only safe images in the image registry.
Patch management means making sure everything is up to date, starting from basic images to more specific application and builder images.
At the same time, vulnerability management involves regularly checking for potential security issues and fixing them, like updating files and creating new images.
This Cyber News was published on feeds.dzone.com. Publication date: Tue, 06 Feb 2024 22:43:05 +0000