Trivy is a comprehensive, easy-to-use open source vulnerability scanner for container images. Since its introduction two years ago, the project has gained a broad following among open source community members. I’m excited to share that it has now become the first container image vulnerability scanner to surpass 8,000 GitHub stars, making it the world’s leading scanner. Unlike other open source scanners, Trivy covers both OS packages and language-specific dependencies and is easy to integrate into organizations’ software development pipelines.
The Journey of Trivy
Three years ago, I was operating Kubernetes clusters and felt the need to manage vulnerabilities in container images. However, security is not a profit generator, but rather a cost. Therefore, I didn’t want to spend a lot of time and money on security, and I needed a tool that was easy to set up. In addition, according to the concept of “shift left,” I was looking for a solution that would easily detect vulnerabilities in the CI/CD pipeline and prevent an image with critical vulnerabilities from being deployed. There were no existing vulnerability scanners that met all of those requirements. In the end, I decided to develop a new scanner that is easy to set up and easy to use in CI/CD.
I just had a long vacation, so I stayed home and started writing Trivy as a hobby project. Shortly after I published Trivy on GitHub, I received an offer from Aqua Security to develop my OSS project as a full-time job. I decided to take this great opportunity and joined Aqua with Trivy.
In the two years since then, Trivy has greatly evolved and gained a lot of users. Hitting the 8,000 GitHub stars milestone is a good opportunity to share our guiding principles for developing Trivy and look at what made it so popular.
The Philosophy of Trivy
My original motivation for development is still the soul of Trivy. It means it must be easy to set up and easy to use.
Trivy has no prerequisites such as database or other middleware. It is a single binary and does not depend on OS commands or external libraries, so you can just download the binary and start using it right away. You can easily integrate it into your CI/CD because nothing needs to be set up except for downloading the Trivy binary.
When scanning a container image, all you have to do is to specify the image name that you want to scan. You don’t need to build the vulnerability database by hand, and Trivy will automatically keep the database up to date by downloading the latest pre-built one from GitHub.
It isn’t easy to avoid dependency on OS commands and so on. The Red Hat database has its own format, and rpm command is written in C, and language-specific dependencies like Node.js are managed by a language-specific package manager written in the language. Trivy is written in Go and can’t import these commands as libraries due to language differences. The easiest way is to run OS commands such as “rpm” and “npm” installed in the host OS, but it means that Trivy requires the external dependencies. I really wanted to make Trivy easy to set up and easy to use, so we rewrote each library in Go. Compared to the easier approach, this method is more time-consuming. However, such a step is the philosophy of Trivy.
I believe that these efforts have led to the adoption of Trivy by many leading cloud native platforms and software providers, including Harbor registry, AWS Marketplace, Alpine, GitLab, and Istio.
Another principle is to focus on fewer false positives. If the security scanner shows too many false positives, users will no longer trust it. We believe it’s better to take the time to develop and release a high-quality feature than rush to release a low-quality feature and lose the trust of our users. Many industry reviews evaluating existing scanners have stated that Trivy is highly accurate.
The Evolution of Trivy
In fact, Trivy is no longer a vulnerability scanner only for container images. It supports scanning for file systems and git repositories as well. And it works not only as a standalone but also as a client and server. You don’t need to worry about how to use these features. They are all easy to set up and start using. An official Helm chart is provided so that the Trivy server can be installed in a Kubernetes cluster, and Redis is also supported as a cache backend for scale.
GitHub Action is also provided for easy integration with GitHub code scanning, as are templates for the AWS Security Hub.
If you want to scan images used by workloads in a Kubernetes cluster, you can also use Starboard, which is a Kubernetes-native security toolkit.
Recently, we published a new capability to scan configuration files of infrastructure as code (IaC) such as Kubernetes, Dockerfile, and Terraform, to detect misconfigurations.
The Future of Trivy
We plan to add support for the recently released AlmaLinux, Rocky Linux, and other new operating systems. We’ll also expand the support for programming languages. There is still a lot of work to be done on IaC scanning, including support for CloudFormation, Ansible, and Helm. In addition, detection of sensitive information such as secret keys and passwords is planned. Software bill of material (SBOM) support will be released soon.
Trying Trivy
I’m honored that the project that started as a hobby has become so widely used. There are many more features we would like to add to Trivy, so the journey goes on!
All this wouldn’t have been possible without you, our amazing users. We look forward to you using Trivy on your projects. As always, we welcome any feedback or pull requests that you may have.
