- If your AI-generated code becomes faulty, who faces the most liability exposure?
- These discoutned earbuds deliver audio so high quality, you'll forget they're mid-range
- This Galaxy Watch is one of my top smartwatches for 2024 and it's received a huge discount
- One of my favorite Android smartwatches isn't from Google or OnePlus (and it's on sale)
- The Urgent Need for Data Minimization Standards
What is Container Scanning (And Why You Need It)
I want to share my experience using vulnerability scanners and other open-source projects for securityIaC 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:
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.
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
What’s next?
I can suggest Learning Track Container Introduction to containers and container management if you are new to this. If you already work with containers, and open-source projects, choose a related scanner and use it for your project. If you already have a Kubernetes cluster, you can easily install KubeClarity in a K8s cluster using Helm, and make KubeClarity UI visible using port-forward and LoadBalancer for the kubeclarity-kubeclarity service.
We’d love to hear what you think. Ask a question or leave a comment below.
And stay connected with Cisco DevNet on social!
LinkedIn | Twitter @CiscoDevNet | Facebook | Developer Video Channel
Share: