Making your application secure
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 Infrastructure-as-code (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, after each running, the community – security specialist, vendors, etc. – identifies, defines, and adds publicly disclosed cybersecurity vulnerabilities to the catalog. (Remember to keep in mind that when you run some scanners on your server or laptop, they 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 – e.g., 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 scanners for vulnerabilities in container images
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
Using Trivy offers a couple advantages:
- it can scan Terraform conf files
- 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 when 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 in 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 were many security specialists, DevOps searching CVE-2021–44228 (Log4j) connected with a common Java logging library. This can be reused in many other projects.
- You can integrate vulnerability scanners in Kubernetes.
- The Trivy kubectl plug-in allows scanned images to run in a Kubernetes pod or deployment.
KubeClarity
There is a tool for detection and management of Software Bill Of Materials (SBOM) vulnerabilities called KubeClarity. It scans both runtime K8s clusters and CI/CD pipelines for enhanced software supply chain security.
The 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?
If you are new to this, let me suggest the DevNet learning track Container Introduction to containers and container management. 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 the KubeClarity UI visible using port-forward and LoadBalancer for the kubeclarity-kubeclarity service.
I hope this helps. Here are some resources where you can learn more:
- Try it yourself with the new Container Scanning and KubeClarity learning lab
- Learn more about Cisco at KubeCon – join us virtually at KubeCon + CloudNativeCon Europe 2022
- Learn more about Cisco portfolio of security APIs and application security tools
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
CONNECT WITH US