1.6.15.1. Trivy

本工具链章节中介绍了许多 AVM 用来进行模块维护和治理的工具，我们在流水线运行上下文中介绍过，为了在 CI/CD 流水线和开发者本地之间提供一致的开发体验，我们构建了一个包含了我们所有用到的工具的容器镜像，以确保开发者使用的工具与流水线中的一致。但是这些工具本身也是由大量的第三方社区开源库所组成的，它们本身随着时间的推移，可能也会暴露出高危安全漏洞。作为供应链安全的重要环节，确保所有工具的依赖项都是安全的，也必须是 AVM 要解决的问题。

Trivy 是一款开源安全扫描工具，由 Aqua Security 团队开发，专注于在 容器镜像、文件系统和代码仓库 中检测已知漏洞和配置错误。它支持多种扫描目标，包括容器镜像、文件系统、Git 仓库、Kubernetes 配置、云平台基础设施（如 AWS）等，能够快速识别操作系统漏洞、依赖库漏洞、误用配置以及敏感信息泄露等问题。Trivy 以扫描速度快、易于集成和实时更新漏洞数据库而著称，广泛应用于 CI/CD 流水线、本地开发环境和镜像仓库的安全监控中。其架构包含镜像解析、漏洞数据库、策略执行与报告生成等模块，支持丰富的输出格式（如 JSON、SARIF、JUnit 等）并兼容主流安全编排工具。总之，Trivy 功能全面、上手简便，是 DevSecOps 场景下常用的统一扫描平台。

1.6.15.1.1. 为何选择 Trivy

  • 多维度扫描能力：Trivy 集合了漏洞扫描、配置扫描和秘密扫描三大功能，可在同一次扫描中同时检查镜像漏洞（OS 和语言依赖库）、检查配置误用（IaC、Dockerfile、K8s 等）并查找硬编码凭据。例如，它可以直接扫描 Git 仓库 trivy repo https://github.com/example/project 来检测其中的漏洞、配置和密钥暴露，也可以扫描本地文件系统或远程容器镜像。

  • 数据库及时更新：Trivy 整合了多个漏洞数据源（如 NVD、各 Linux 发行版和语言生态的安全数据库），并提供增量更新机制，漏洞库可通过 trivy db update 快速同步，保证扫描结果及时覆盖最新 CVE。这种设计使得开发者不用每次全量下载新数据库，可节省网络带宽（约节省 98% 更新量）。

  • 易于集成与自动化：Trivy 在不同 CI/CD 平台上都有现成集成方案。例如，GitHub Actions 可使用官方的 aquasecurity/trivy-action，Azure DevOps Pipeline 有对应的 Trivy 任务，GitLab CI 则可直接在 YAML 中添加 Trivy 命令。其命令行参数灵活，可设置扫描级别、输出格式、退出码等，方便自动化流水线处理扫描结果。此外，Trivy 还支持通过 .trivyignore 文件忽略某些已知但无法修复的漏洞，从而避免阻断 CI 流水线。

  • 轻量本地使用：Trivy 单个二进制文件可部署在开发机器或构建服务器上，扫描时缓存索引，无需启动服务，支持离线环境。即使未联网，仅要事先下载好漏洞数据库镜像，也能执行本地扫描。便捷的安装和部署方式，让团队可以快速落地并保持一致的安全检查流程。

1.6.15.1.2. 容器镜像扫描与 Dockerfile 检查

Trivy 最常用的场景之一是对包含大量 Terraform 工具或依赖的 容器镜像 进行漏洞扫描。比如镜像中可能安装了 Terraform CLI、Az CLI、Python/Ruby 等语言依赖，甚至用于构建 Terraform Module 的工具链。这些镜像往往体积较大、包含丰富的软件包，容易遗留漏洞。使用 Trivy 可以快速地识别镜像中的漏洞和过期组件。例如：

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

上面的命令会扫描指定的镜像，仅报告高危和严重漏洞，输出表格形式的报告。在 CI/CD 流水线中，可以将此命令放在镜像构建步骤之后，一旦检测到超过阈值的漏洞就让流水线失败，强制开发者尽早修复。Trivy 的 GitHub Action 任务内置了更新数据库的缓存机制，保证扫描时数据库已最新下载，可避免频繁下载影响速度。

对于 Dockerfile 中的配置和最佳实践问题，Trivy 也能通过配置扫描（trivy config）来检查。例如，可以扫描项目目录下的 Dockerfile：

trivy config ./Dockerfile

此命令会检测 Dockerfile 中常见的安全错误（如未指定基础镜像标签、使用可提权参数等），并输出测试结果。事实上，Trivy 的 config 模式支持扫描多种 IaC 文件（Terraform、Kubernetes、Helm、Dockerfile 等），自动匹配相应的规则进行检测。在实践中，可以在镜像构建前进行 Dockerfile 检查，也可以在构建完成后对生成的镜像再进行漏洞检测，形成前后双重保障。通过将 Trivy 镜像扫描纳入 CI，团队能保证每次推送的镜像都经过统一的安全评估和审计记录，提升自动化流程的一致性和可追溯性。

1.6.15.1.3. 硬编码凭据（Secret）扫描

Trivy 的一大特色是默认开启 Secrets 扫描，能够在容器镜像、文件系统或 Git 仓库中检测硬编码的密钥、令牌或密码字符串。它基于一系列内置规则匹配常见的敏感信息模式，如 AWS Access Key、GCP 服务账号、GitHub/Slack/SMTP 等 API 令牌等。例如，当执行：

trivy fs /path/to/terraform/project

1.6.15.1.4. Terraform 配置误用检测

针对 Terraform 这类基础设施即代码（IaC）配置，Trivy 也提供了内置的最佳实践检测能力。使用 trivy config 命令可以扫描项目目录下的 Terraform 文件，比较定义的资源配置与安全基线规则，将不符合最佳实践的配置标记出来。Trivy 默认包含多种政策（policy），覆盖 Docker、Kubernetes、Terraform、CloudFormation 等领域的常见安全检查。比如，它会识别 Terraform 中未指定资源版本、未使用安全参数、暴露不必要权限等风险；在 AWS/GCP/Azure 等环境下，也能检测是否遵循了 CIS 安全基线等规范（比如 AWS IAM 最小权限、S3 未加密等）。

此外，用户可以使用 Open Policy Agent (OPA) 的 Rego 语言自定义规则，将组织内的合规标准或业务需求编码进扫描。例如，可以编写自定义规则要求所有 azure_storage_account 资源都启用加密，或所有 Kubernetes 控制器都使用 Pod 安全策略。这些自定义规则配合 Trivy 的 --config 参数就能在 trivy config 时生效，提前在本地或 PR 阶段进行检测。

在 Terraform 模块开发过程中尽早发现配置风险非常重要。最好在本地编写代码时，就通过 Trivy 进行扫描，避免将不安全的配置提交到中央仓库。CI/CD 管道中，可以设置当 Trivy 检测到中高风险违规时，阻断合并请求。配合模块示例代码测试，开发者能确保每次提交的 Terraform 代码都经过了自动化检查，从而降低生产环境出现配置漏洞的概率。

在 Azure Verified Modules 中由于我们已经使用了 conftest 搭配 policy-library-avm，所以就不再重复使用 Trivy 的 Terraform 检测了。

1.6.15.1.5. 实践示例

在实际项目中，Trivy 经常以自动化检查工具的身份出现。例如，Azure 官方的 “Terraform 模块脚手架” 项目（Azure Verified Terraform Module Scaffold）就将 Trivy 集成到其 GitHub Actions 流水线中。在其 .github/workflows/check.yml 中，每次构建镜像后都会运行 Trivy 扫描，检查镜像中的漏洞和 Terraform 代码的配置问题，并将结果报告显示在 CI 界面。类似地，不少团队也会在项目的 “预提交” 或 “持续集成” 阶段加入 Trivy 步骤，将扫描结果以评论或汇总报告的形式输出，确保容器安全策略与 Terraform 配置审核流程一致地自动执行。通过这些实践，可以实现整个代码审查流程的一致性与可追溯性，使安全检查成为日常开发流程的一部分，而不是事后才进行的补丁工作。

- 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.awsaquasecurity/trivy-db'
    TRIVY_JAVA_DB_REPOSITORY: 'ghcr.io/aquasecurity/trivy-java-dbpublic.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'

上述示例中，如果镜像中检测到任意严重或高等级漏洞（CRITICAL,HIGH），trivy image 会以非零退出码终止流程，触发 CI 报错警告。

任何违规项都会被标记在 Trivy 的输出中，CI 可将其作为检查失败的依据。我们也可以设置定时任务，每周针对当前最新的 Dockerfile 进行一次检查，确保新公布的漏洞能被尽快修复。总之，通过在构建和测试的各个阶段统一采用 Trivy，工程团队可以建立起完善的自动化治理流程，高效应对大规模 Terraform 模块开发中的安全挑战。

results matching ""

    No results matching ""