Vulnerability Scanning: Trivy vs the Trivy Operator

Over the past few months Aqua Trivy, the all-in-one cloud native security scanner, has rapidly grown in features and tapped into new use cases. In this blog post, we will explore

• An overview of Trivy
• The different use cases that Trivy covers
• An overview of the Trivy Operator
• The difference between Trivy and the Trivy Operator

Trivy Overview

A comprehensive security scanner, Trivy is reliable, fast, extremely easy to use, and works wherever you need it.  It is hosted within the Aqua Security GitHub organization and completely open source; you do not have to sign up to use it nor will Aqua receive any data. Additionally, there are no limitations on its usage.

Trivy is primarily used as CLI tool. Users can either install Trivy on their local machine or through their CI/CD pipeline to scan multiple targets for security issues.

Trivy scan targets include

• Container Images
• Git repositories
• Infrastructure as Code configurations scans (Dockerfile, Terraform, Cloudformation & more)
• Trivy Cloud (AWS Account)
• Kubernetes Clusters

A scan target is either a specific resource such as a Dockerfile, which is a collection of resources like a filesystem, or an instance of a resource such as an AWS account.

Trivy can scan these targets for

• Vulnerabilities (CVEs)
• Exposed Secrets and sensitive information
• Misconfigurations
• OS packages and software dependencies

Additionally, Trivy has the following functionality:

• Generating SBOMs (Software Bill of Materials)
• Attestation, whereby Trivy is used with Cosign from Sigstore

Trivy Use Cases

Trivy is a very versatile security scanner with lots of features targeting a wide range of users and use cases. Thinking about the development lifecycle, it can be integrated at all stages by different team members and engineers within the company.

Below are some possible Trivy use cases:

1. An engineer might scan libraries for vulnerabilities before using them in their project.
2. Trivy has a VSCode integration, among many others, which makes it possible to scan local resources in the middle of development.
3. Once an application has been packaged up in container images, Trivy can be used to scan the base image, as well as the final image, for vulnerabilities. Trivy additionally has a Docker Desktop extension making it possible to scan container images right through the UI, among other features.
4. The Dockerfile can be scanned for misconfiguration issues before building the image of the application.
5. Another use case of Trivy, and the next step that might follow, would be to create the configuration files, such as Terraform and Kubernetes manifests, to deploy the application and scan those for misconfiguration.
6. Similar scans to the ones highlighted above can be performed upon every update to the application within the CI/CD pipeline.
7. An SBOM can be generated to obtain a detailed list of the dependencies of the container image.
8. When the resources have been deployed to the cluster, Trivy can also be used to scan the cluster and its running workloads.

Note that like any open-source tool, there are lots of ways to use Trivy where it can be combined with other open-source tools.

The benefits of using one security scanner for all stages would be instances in which:

• different scans can be performed at the same time where only one step would be required within your CI/CD pipeline to perform multiple scans.
• same scans can be performed at different stages. For example, scanning your IaC files for the same misconfiguration risks in your IDE, then in git, then when applying, then in production.
• knowledge is easily shared across team members; this is particularly important for open-source tools since there is no 1:1 support for the setup and integration of a tool.

Furthermore, Trivy is a notably mature security scanner with wide industry adoption including a high-profile customer base and over 14.000 stars on GitHub. As such, it can be integrated with many other tools, both community maintained and official ones. This makes it possible to integrate Trivy easily and directly within your own setup and existing stack.

Trivy Operator

The Trivy Operator is a Kubernetes Operator which means it can be deployed directly inside of your Kubernetes cluster to run continuous security scans of your running resources and infrastructure. The operator will monitor the running resources in your cluster and generate a new scan whenever resources change, get updated, or are newly deployed. Furthermore, it is built to integrate easily with other cloud native applications. For instance, the Trivy Operator has a Prometheus endpoint for easy integration with your monitoring stack.

Currently, the Trivy Operator runs the following scans:

1. Vulnerability scans which run for each container image in your cluster.
2. Misconfiguration scans that scrutinize your manifests and other deployment configurations for misconfiguration.
3. Secret scans which find and detail the location of exposed Secrets within your cluster.
4. RBAC scans that provide detailed information on the access rights of the different resources installed.

Trivy vs. the Trivy Operator

After detailing both Trivy and the Trivy Operator, you might already have an idea of the use case of each tool and their benefits.

As mentioned earlier, the Trivy CLI can be used to scan your Kubernetes cluster and its running workloads. The ideal usage would be to implement it into existing workflows prior to the deployment of resources while the Trivy Operator scans running workloads already within your Kubernetes environment. Additionally, it is also possible to use a combination of Trivy and the Trivy Operator for end-to-end vulnerability scanning of all your resources.

Some differences between Trivy and the Trivy Operator can be seen in the following.

1. Scans must be manually initiated through the Trivy CLI. This is great for automation pipelines or ad-hoc use. For example, cluster admins could look at the current state of the cluster. However, if you want a tool to run background scans on a continuous basis from within the cluster, then the Trivy Operator would be more suitable.
2. Trivy produces reports in your Terminal. These reports can be exported and displayed in different formats. In comparison, the Trivy Operator produces reports that are CRDs (Custom Resource Definition), a type of Kubernetes resource, which makes it possible to integrate the Trivy Operator with tools that can consume Kubernetes manifests.
3. Kubernetes best practice is always to push information from within the cluster to tools outside rather than pulling information out by tools that are not running within the cluster. If the main goal is Kubernetes vulnerability scanning resources, then the Kubernetes Operator will be more suited.
4. The Trivy Operator does not cover the vulnerability scanning of development resources before deployment. For that purpose, one should always use Trivy.
5. The Trivy CLI cannot detect changes of any in-cluster, running resources. For this reason, the Trivy operator is best.

What’s next?

In this blog post, we provided an overview of both Trivy and the Trivy Operator, highlighted their differences, and detailed their respective use cases.

If you have more specific questions about your environment, consider creating a discussion on GitHub within either the Trivy or the Trivy Operator channel. Alternatively, you can join us on Slack to ask questions and stay up to date with the projects.

Additional Resources

1. Trivy Documentation: https://aquasecurity.github.io/trivy/latest
2. Trivy Repository: https://github.com/aquasecurity/trivy
3. Trivy Operator Documentation: https://aquasecurity.github.io/trivy-operator/latest
4. Trivy Operator Repository: https://github.com/aquasecurity/trivy-operator
5. Video on Kubernetes Operator: https://youtu.be/KRNlDQTeFKs
6. The Aqua Open Source YouTube channel with additional resources: https://www.youtube.com/c/AquaSecurityOpenSource