1.6.15.1. Trivy

This toolchain section introduces many tools used by AVM for module maintenance and governance. As mentioned in the Pipeline Execution Context, to provide a consistent development experience between the CI/CD pipeline and the developer's local environment, we have built a container image containing all the tools we use, ensuring that the tools used by developers are consistent with those in the pipeline. However, these tools themselves are composed of a large number of third-party open-source libraries, which may expose high-risk security vulnerabilities over time. As a critical part of supply chain security, ensuring that all tool dependencies are secure is also a problem that AVM must address.

Trivy is an open-source security scanning tool developed by the Aqua Security team, focusing on detecting known vulnerabilities and misconfigurations in container images, file systems, and code repositories. It supports various scanning targets, including container images, file systems, Git repositories, Kubernetes configurations, cloud platform infrastructure (such as AWS), etc., and can quickly identify operating system vulnerabilities, dependency library vulnerabilities, misconfigurations, and sensitive information leaks. Trivy is known for its fast scanning speed, ease of integration, and real-time updates of its vulnerability database. It is widely used in security monitoring for CI/CD pipelines, local development environments, and image registries. Its architecture includes modules for image parsing, vulnerability databases, policy execution, and report generation, supporting rich output formats (such as JSON, SARIF, JUnit, etc.) and compatible with mainstream security orchestration tools. In short, Trivy is comprehensive, easy to get started with, and is a commonly used unified scanning platform in DevSecOps scenarios.

1.6.15.1.1. Why Choose Trivy

  • Multi-dimensional Scanning Capability: Trivy combines three major functions: vulnerability scanning, configuration scanning, and secret scanning. In a single scan, it can check for image vulnerabilities (OS and language dependency libraries), check for configuration misuse (IaC, Dockerfile, K8s, etc.), and find hardcoded credentials. For example, it can directly scan a Git repository trivy repo https://github.com/example/project to detect vulnerabilities, configurations, and key exposures within it, or scan the local file system or remote container images.

  • Timely Database Updates: Trivy integrates multiple vulnerability data sources (such as NVD, security databases of various Linux distributions and language ecosystems) and provides an incremental update mechanism. The vulnerability database can be quickly synchronized via trivy db update, ensuring that scanning results cover the latest CVEs in a timely manner. This design saves developers from downloading the full new database every time, saving network bandwidth (saving about 98% of the update volume).

  • Easy to Integrate and Automate: Trivy has ready-made integration solutions on different CI/CD platforms. For example, GitHub Actions can use the official aquasecurity/trivy-action, Azure DevOps Pipeline has corresponding Trivy tasks, and GitLab CI can directly add Trivy commands in YAML. Its command-line arguments are flexible, allowing settings for scanning levels, output formats, exit codes, etc., facilitating automated pipeline processing of scanning results. In addition, Trivy also supports ignoring certain known but unfixable vulnerabilities through .trivyignore files, thereby avoiding blocking CI pipelines.

  • Lightweight Local Usage: A single Trivy binary file can be deployed on a development machine or build server. It caches indexes during scanning without needing to start a service, supporting offline environments. Even without an internet connection, local scanning can be performed as long as the vulnerability database image is downloaded in advance. The convenient installation and deployment methods allow teams to quickly implement and maintain consistent security check processes.

1.6.15.1.2. Container Image Scanning and Dockerfile Checks

One of the most common scenarios for Trivy is to scan container images containing a large number of Terraform tools or dependencies for vulnerabilities. For example, the image may have Terraform CLI, Az CLI, Python/Ruby, and other language dependencies installed, or even the toolchain used to build Terraform Modules. These images are often large in size and contain rich software packages, making them prone to legacy vulnerabilities. Using Trivy can quickly identify vulnerabilities and outdated components in images. For example:

trivy image --format table --severity HIGH,CRITICAL avmrunner

The command above will scan the specified image, reporting only high-risk and critical vulnerabilities, and output the report in a table format. In a CI/CD pipeline, this command can be placed after the image build step. Once vulnerabilities exceeding the threshold are detected, the pipeline fails, forcing developers to fix them as soon as possible. Trivy's GitHub Action task has built-in caching mechanisms for updating the database, ensuring that the database is the latest downloaded during scanning, avoiding frequent downloads that affect speed.

For configuration and best practice issues in Dockerfiles, Trivy can also check them through configuration scanning (trivy config). For example, you can scan the Dockerfile in the project directory:

trivy config ./Dockerfile

This command will detect common security errors in the Dockerfile (such as not specifying a base image tag, using privilege escalation parameters, etc.) and output the test results. In fact, Trivy's config mode supports scanning various IaC files (Terraform, Kubernetes, Helm, Dockerfile, etc.), automatically matching corresponding rules for detection. In practice, Dockerfile checks can be performed before image building, or vulnerability detection can be performed on the generated image after building, forming a double guarantee before and after. By incorporating Trivy image scanning into CI, the team can ensure that every pushed image undergoes unified security assessment and audit records, improving the consistency and traceability of automated processes.

1.6.15.1.3. Hardcoded Credentials (Secret) Scanning

A major feature of Trivy is that Secrets scanning is enabled by default, capable of detecting hardcoded keys, tokens, or password strings in container images, file systems, or Git repositories. It matches common sensitive information patterns based on a series of built-in rules, such as AWS Access Keys, GCP Service Accounts, GitHub/Slack/SMTP API tokens, etc. For example, when executing:

trivy fs /path/to/terraform/project

1.6.15.1.4. Terraform Misconfiguration Detection

For Infrastructure as Code (IaC) configurations like Terraform, Trivy also provides built-in best practice detection capabilities. Using the trivy config command, you can scan Terraform files in the project directory, compare defined resource configurations with security baseline rules, and mark configurations that do not meet best practices. Trivy includes multiple policies by default, covering common security checks in fields like Docker, Kubernetes, Terraform, CloudFormation, etc. For instance, it identifies risks in Terraform such as unspecified resource versions, unused security parameters, exposing unnecessary permissions, etc.; in environments like AWS/GCP/Azure, it can also detect compliance with norms like CIS security baselines (e.g., AWS IAM least privilege, S3 unencrypted, etc.).

In addition, users can use the Open Policy Agent (OPA) Rego language to customize rules, encoding organizational compliance standards or business requirements into scanning. For example, custom rules can be written to require all azure_storage_account resources to enable encryption, or all Kubernetes controllers to use Pod security policies. These custom rules, combined with Trivy's --config parameter, can take effect during trivy config, allowing for early detection locally or during the PR stage.

It is very important to discover configuration risks early in the Terraform module development process. It is best to scan with Trivy while writing code locally to avoid submitting insecure configurations to the central repository. In the CI/CD pipeline, it can be set to block merge requests when Trivy detects medium-to-high risk violations. Combined with module example code testing, developers can ensure that every submitted Terraform code has undergone automated checks, thereby reducing the probability of configuration vulnerabilities in the production environment.

In Azure Verified Modules, since we already use conftest with policy-library-avm, we do not repeat Trivy's Terraform detection capabilities.

1.6.15.1.5. Practical Examples

In actual projects, Trivy often appears as an automated inspection tool. For example, the official Azure "Terraform Module Scaffold" project (Azure Verified Terraform Module Scaffold) integrates Trivy into its GitHub Actions pipeline. In its .github/workflows/check.yml, Trivy scanning is run after every image build to check for vulnerabilities in the image and configuration issues in Terraform code, and the results are reported in the CI interface. Similarly, many teams also add Trivy steps in the "pre-commit" or "continuous integration" stages of their projects, outputting scanning results in the form of comments or summary reports, ensuring that container security policies and Terraform configuration audit processes are automatically executed consistently. Through these practices, the consistency and traceability of the entire code review process can be achieved, making security checks part of the daily development process rather than a patch job done afterwards.

- name: Docker Build Test
  run: |
    docker build $(sh build-arg-helper.sh version.env) -t localrunner .
- name: Run Trivy vulnerability scanner
  env:
    TRIVY_DB_REPOSITORY: 'ghcr.io/aquasecurity/trivy-db,public.ecr.aws/aquasecurity/trivy-db'
    TRIVY_JAVA_DB_REPOSITORY: 'ghcr.io/aquasecurity/trivy-java-db,public.ecr.aws/aquasecurity/trivy-java-db'
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: 'localrunner'
    format: 'table'
    exit-code: '1'
    severity: 'CRITICAL,HIGH'
    trivyignores: '.trivyignore'
    timeout: '120m'
    scanners: 'vuln'

In the example above, if any critical or high-level vulnerabilities (CRITICAL, HIGH) are detected in the image, trivy image will terminate the process with a non-zero exit code, triggering a CI error warning.

Any violations will be marked in Trivy's output, which CI can use as a basis for check failure. We can also set up scheduled tasks to check the latest Dockerfile weekly, ensuring that newly published vulnerabilities can be fixed as soon as possible. In short, by unifying Trivy adoption across various stages of building and testing, engineering teams can establish a complete automated governance process to efficiently deal with security challenges in large-scale Terraform module development.

results matching ""

    No results matching ""