At Druva, we extensively use containerization technology (Docker) for deploying applications on AWS. Containers provide a lightweight and portable way to package and deploy software, which makes them a perfect fit for Druva’s 100% SaaS-based application. Containers also provide a high level of isolation between different applications, which is critical for our multi-tenant applications. There is no such thing as a free lunch and containers are no exception. One of the downsides of using containerized applications is the inherent security risks that get packaged from the base layer. This article shares the approach we followed to mitigate the security risks associated with our container images, which led us to achieve the perfect trifecta of zero vulnerability, minimal attack surface, and slimmed container images.
Druva is an industry leader in SaaS-based data protection and we are vigilant about and closely monitor our Infosec score. Our Infosec score is a metric we use to measure the security of container images. We take into account a variety of factors, such as known vulnerabilities in the software packages included in the image, the age of the image, and the overall size of the image. So, with the Infosec score as the single metric to improve, the goal was pretty clear: we want all our container images with zero vulnerabilities, regularly updated, and of minimal possible size. This activity is imperative for us to ascertain the secure application experience to our customers.
State of Docker Containers in Druva Cloud
The Druva Data Resiliency Cloud on AWS mostly contains Docker containers hosting microservices written in Go and Python programming languages.
Go code is compiled into machine code, which is then packaged into a container. Go's static linking and the ability to build a single binary executable make it easy to create small, self-contained container images. This is because there's no need to include the runtime environment in the container image, as the binary executable contains all the necessary dependencies.
Python, on the other hand, is an interpreted language, which means that it needs to have the Python interpreter and any necessary dependencies along with the application code included in the container image in order to run the code. This increases the size of the container image compared to a compiled language like Go, which only needs to include the binary executable.
The average size of the Go-based Docker container is around 500 MB, while the Python-based Docker containers were around 1.6 GB. The generated SBOM (Software Bill of Materials) of the Go-based Docker images contains around 400 packages while Python-based Docker containers contain 500 packages. Most of the packages listed on the SBOM are introduced from the Base OS layer of the container. The Snyk vulnerability scan on these containers detected around 125 vulnerabilities per container. The detected vulnerabilities are from packages that are not even used by the application running inside the container and are just contributing to increasing the attack surface.