Businesses realize that containers can make application packaging and shipping cheaper and easier to manage at scale. Because containers are standardized — application code, dependencies, libraries, and runtime are packaged into containers (and images) to increase agility and help deliver a service to end users quickly. But while containers provide developers with several benefits, they also increase risk for the business because a developer has access to a wide range of tools and libraries to implement a feature.
It is crucial for developers to have visibility into the vulnerabilities early in the Software Development Life Cycle(SDLC) process to minimize the attack surface and save developers time. The Lens Security feature, where Lens Desktop comes with built-in container image scanning capabilities to spot scan an image and immediately identify and mitigate the vulnerabilities present in that container image, bridges this gap.
Before we dive into how the Lens Security feature works and how developers can benefit from it, let me walk you through the steps involved in identifying and fixing vulnerabilities in an enterprise organization:
- A developer writes code
- The developer pushes code to a code repository (such as GitLab or GitHub)
- The CI / CD Process is triggered, building and pushing the image to the registry and deploying it in a cluster
- Developers validate the deployment in the Dev environment
- The application is promoted to higher environments
- Security or Operations teams evaluate the risk in higher environments (typically Prod)
- Because it is not common to scan applications or containers in lower environments, the security team creates a report with the list of vulnerabilities and the development teams that are responsible for addressing them
- The issue is triaged and addressed in the next release.
This process is extensive, time-consuming, and not developer friendly, because the vulnerabilities are identified at the last stage of the SDLC and developers are interrupted to fix vulnerabilities.
Lens 6 improves the developer experience with the addition of the Lens Security feature, which enables developers to scan container images and view vulnerability reports early in the development process. For example, a developer can trigger an image scanning from:
- The Pod Object’s menu item, accessing the result on the Pod Object details page
- The Images section, by selecting the image from the list of images the developer has access to. The report appears on the details page. The Image section also provides a high-level summary of status, results, and vulnerabilities
There are several tools like Trivy, sync, Dive, Docker bench, and so on, which help developers to scan images, identify vulnerabilities and provide guidance to the developers to fix them, but these tools are not directly integrated into the developer workflow, commonly resulting in failure to uncover the failures early in the process. Several organizations have adopted the DevSecOps framework to identify the issues early in the release process, enabling developers to fix the vulnerabilities before they are in production. But in this process, a developer has to rely on tools that are not directly integrated into their development workflow, thus increasing the complexity.
Lens Security uses Trivy, an open source project from Aqua Security, to scan containers and other artifacts. Trivy detects vulnerabilities and the results in Lens Desktop make it super easy to showcase the vulnerabilities for developers within their workflow. This eliminates complexity for developers because there is no need to jump to yet another dashboard or wait for the security or operations team to give an extensive list of vulnerabilities and interrupt your priorities to fix these vulnerabilities.
Let me go through an example of how a developer can scan images and fix identified vulnerabilities.
As an application developer, I started working on a web application with the following configuration:
- Image Source: Docker Hub
- Container base image: golang:1.18.5
- Purpose: For the demo, the page displays a “Hello world” message.
- Source code: GitHub Repo
When I choose the “golang:1.18.5” image, I don’t have any visibility into the vulnerabilities in the image. All I was looking for is a Docker image that provides the runtime for the code I’ve developed. It is important for me to develop the feature.
Once the code is ready, I deploy the container in my development environment. Let’s say a minikube cluster, using the following command.
kubectl apply -f https://raw.githubusercontent.com/avinashdesireddy/go-webapp-demo/main/deploy/deployment.yaml
The deployment will turn into the ready state in a few minutes.
Now, I can browse the pod configuration to test the application and validate if configMaps, secrets, or any other objects are mounted correctly. Assuming everything is good, I can focus on identifying the vulnerabilities in the application right from Lens by selecting the scan button.
Once the scanning process is complete, I can directly find the vulnerabilities present in the container and focus on addressing them. In this demo application, there are 21 CRITICAL, 85 HIGH, and 91 MEDIUM vulnerabilities.
These vulnerability reports and scanning can also be performed from the Images section.
This Lens Security feature, directly embedded in my development workflow, helps identify security vulnerabilities early in the process and has minimal or no interruptions from the security or operations team.
This text was written by Avinash Desireddy for our blog!