How do you install and configure Trivy?

Installing Trivy is like setting up a new power tool in your workshop. You can buy it from a hardware store (package manager), order it online and assemble it yourself (binary download), or rent one that comes ready to use (Docker image). Once you have the tool, you adjust its settings (configuration) to match the type of work you do most often.

Trivy offers multiple installation methods to suit different environments. On macOS, the simplest approach is brew install trivy using Homebrew. On Debian and Ubuntu systems, you add the Aqua Security APT repository and run apt-get install trivy. On Red Hat and CentOS, you add the YUM repository and install with yum install trivy. For environments where package managers are not available or not desirable, you can download the pre-built binary from the GitHub releases page and place it in your PATH. In CI/CD pipelines for services like payments-api or user-auth-service, many teams use the official Trivy Docker image (aquasec/trivy) to avoid installing anything on the build agent. There is also a Trivy GitHub Action for GitHub Actions workflows and a Trivy plugin for Jenkins.

Configuration in Trivy follows a precedence hierarchy: CLI flags override environment variables, which override the configuration file. The configuration file is named trivy.yaml and can be placed in the project root or specified with the --config flag. This file allows you to define default settings that apply every time Trivy runs in that project. Common configuration options include the severity levels to report, the output format, the cache directory location, vulnerability database mirror URLs for air-gapped environments, and scanner types to enable. Environment variables follow the pattern TRIVY_ followed by the setting name in uppercase, so --severity becomes TRIVY_SEVERITY and --format becomes TRIVY_FORMAT.

In production environments, teams configure Trivy differently depending on the context. For local development on a service like order-processing-service, a trivy.yaml file in the repository root sets sensible defaults so developers just run trivy fs . without remembering flags. For CI pipelines, environment variables or CLI flags override the defaults to enforce stricter policies. For air-gapped environments where the build agents cannot reach the internet, Trivy is configured to use an internal mirror for the vulnerability database. The database can be downloaded on a machine with internet access using trivy image --download-db-only and then transferred to the internal mirror. Cache management is also important: Trivy caches the vulnerability database locally (default location is ~/.cache/trivy) and only downloads updates when the cache expires.

A common mistake during installation is forgetting to initialize the vulnerability database before the first scan. Trivy downloads the database automatically on the first run, but this can take 30 to 60 seconds depending on network speed. In CI pipelines for checkout-service or inventory-sync, this delay adds up if the database is downloaded fresh on every build. The solution is to either cache the database directory between builds or run trivy image --download-db-only as a separate pipeline step that executes less frequently.