What is Container Scanning (And Why You Need It)

I want to share my experience using vulnerability scanners and other open-source projects for security. First, we need container scanning to make our app and solution secure and safe. The central concept of container scanning is to scan OS Packages and programming language dependencies. Security scanning helps to detect common vulnerabilities and exposures (CVE). The modern proactive security approach provides integration container scanning in CI/CD pipelines. This approach helps detect and fix vulnerabilities in code, containers, and IaC conf files before release or deployment.

How does it work?

Scanners pull the image from the docker registry and try to analyze each layer. After the first running, scanners will download their vulnerability database.  Then each time after running, the community (security specialist, vendors, etc.) identifies, defines, and adds publicly disclosed cybersecurity vulnerabilities to the catalog. We need to consider that sometimes when you run some scanners on your server or laptop, scanners can take some time to update their database.  

Usually, scanners and other security tools use multiple resources for their database: 

◉ Internal database 

◉ National Vulnerability Database (NVD) 

◉ Sonatype OSS Index 

◉ GitHub Advisories 

◉ Scanners also can be configured to incorporate external data sources (e.g., https://search.maven.org/ )

As a result, we see the output with a list of vulnerabilities, name of components or libraries, Vulnerability ID, Severity level (Unknown, Negligible, Low, Medium, High), and Software Bill of Materials (SBOM) format. Using output, we can see or write in a file in which package version vulnerabilities were fixed. This information can help change/update packages or base the image on the secure one. 

Comparing Trivy and Grype

I chose to compare two different open source vulnerability scanners. Trivy and Grype are comprehensive scanners for vulnerabilities in container images, file systems, and GIT repositories. For the scanning and analytics, I chose the Debian image, as it’s more stable for production (greetings to alpine).  

Part of the Grype output

Part of the Trivy output

A couple advantages of Trivy is that 1) it can scan Terraform conf files, and 2) it’s output format (by default as a table output) is better due to colored output and table cells abstract with link to total vulnerabilities description.

Both projects can write output in JSON and XML using templates. This is beneficial in integrating scanners in CI/CD, or using the report for another custom workflow. However, information from Trivy looks more informative due to the vulnerability abstract and extra links with descriptions.

Part of Trivy output JSON

Additional features

◉ You can scan private images and ​self-hosted container registries.

◉ Filtering vulnerabilities is a feature for both projects. Filtering can help highlight critical issues or find specific vulnerabilities by ID. In the latest case where many security specialists, DevOps searching CVE-2021–44228 (Log4j) connected with a common Java logging library, that will also be reused in many other projects.

◉ You can integrate vulnerabilities scanners in Kubernetes

◉ Trivy kubectl plugin allows scan images running in a Kubernetes pod or deployment.

KubeClarity

There is a tool for detection and management of Software Bill Of Materials (SBOM) and vulnerabilities called KubeClarity. It scans both runtime K8s clusters and CI/CD pipelines for enhanced software supply chain security.

KubeClarity vulnerability scanner integrates with the scanners Grype (that we observed above) and Dependency-Track.

KubeClarity Dashboard

KubeClarity Dashboard

Based on my experience, I saw these advantages in KubeClarity:

◉ Useful Graphical User Interface

◉ Filtering features capabilities:

    ◉ Packages by license type

    ◉ Packages by name, version, language, application resources

    ◉ Severity by level (Unknown, Negligible, Low, Medium, High)

    ◉ Fix Version

Source: cisco.com