Trivy 实战手册：容器安全扫描从入门到「真香」

晨平安

岁岁平，岁岁安，岁岁平安

3902 字

20 分钟

Trivy 实战手册：容器安全扫描从入门到「真香」

2026-06-07

原创

Trivy

/

Docker

/

容器安全

/

DevOps

/

CI/CD

/

K8s

🔍 为什么 Trivy 成了「标配」？#

2026 年如果你去参加任何技术大会，随便找一个 DevOps 工程师问他：「你们用啥做容器安全扫描？」

十有八九的答案是——Trivy。

由 Aqua Security 开源的 Trivy，从 2024 年的「小众工具」到 2026 年的「几乎标配」，只用了两年时间。GitHub 上 Trending 常客，今天又上榜了，总星数已经突破 25K。

它的卖点很简单：又快又准又省心。一个二进制文件，不需要数据库，不需要长时间的学习，trivy image nginx:latest 就能扫出所有 CVE 漏洞。

📦 安装 Trivy#

Trivy 的安装方式很多，我最推荐直接下载二进制：

1
# macOS
2
brew install trivy
3

4
# Linux (一键安装)
5
curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh
6

7
# Docker
8
docker pull aquasec/trivy:latest

确认安装成功：

1
trivy --version
2
# Version: 0.58.0
3
# Vulnerability DB:
4
#   Next Update: 2026-06-08 06:00:00 (UTC)
5
#   Installed: 2026-06-07 06:00:00 (UTC) ← 今天刚更新的数据库

Trivy 每天更新六次漏洞数据库，这意味着你扫出来的漏洞基本是实时的。

🚀 基本用法：扫描镜像#

先来个最基础的操作：扫描一个 Docker 镜像：

1
# 扫描 nginx 最新版
2
trivy image nginx:latest
3

4
# 输出（简化）:
5
# nginx:latest (debian 12.8)
6
# ==========================
7
# Total: 87 (UNKNOWN: 0, LOW: 45, MEDIUM: 32, HIGH: 8, CRITICAL: 2)
8
#
9
# ┌────────────────────────┬──────────────┬──────────┬────────────────────────────┐
10
# │        Library         │ Vulnerability │ Severity │         Installed Version   │
11
# ├────────────────────────┼──────────────┼──────────┼────────────────────────────┤
12
# │ libssl3                │ CVE-2026-1234 │ CRITICAL │ 3.0.12-1                   │
13
# │ libcrypto3             │ CVE-2026-5678 │ HIGH     │ 3.0.12-1                   │
14
# │ libxml2                │ CVE-2026-9012 │ MEDIUM   │ 2.9.14+dfsg-1.3            │
15
# │ curl                   │ CVE-2025-8901 │ LOW      │ 7.88.1-10+deb12u6          │
16
# └────────────────────────┴──────────────┴──────────┴────────────────────────────┘

注意那两个 CRITICAL 级别的漏洞！这就是为什么你不能直接拿 nginx:latest 上生产环境的原因。

🔧 进阶用法：自定义策略#

Trivy 的强大之处在于它的可定制性。你可以设定「严重级别」的阈值，只有超过某个级别的漏洞才阻断 CI：

1
# 只显示 HIGH 和 CRITICAL 级别的漏洞
2
trivy image --severity HIGH,CRITICAL myapp:latest

更高级的是使用 自定义策略文件：

1
severity: HIGH,CRITICAL
2

3
ignore:
4
  # 已知的误报可以忽略
5
  - vulnerability: CVE-2025-9999
6
    reason: "这个 CVE 只影响 Windows 平台，我们的镜像跑在 Linux 上"
7

8
  # 某些基础镜像的已知问题
9
  - vulnerability: CVE-2024-0001
10
    expiry: "2026-07-01"  # 到期后自动重新生效
11
    reason: "等待上游镜像更新"
12

13
scan:
14
  # 扫描配置文件和密钥
15
  secrets:
16
    enabled: true
17

18
  # 扫描 IaC (Terraform, K8s manifest 等)
19
  misconfiguration:
20
    enabled: true
21

22
  # SBOM 生成
23
  sbom:
24
    format: "cyclonedx"

然后运行：

1
trivy image --policy trivy-policy.yaml myapp:v2.1.0

🏭 CI/CD 集成（这才是重头戏）#

Trivy 最值钱的应用场景就是集成到 CI/CD 流水线中。下面是一个 GitHub Actions 的完整配置：

1
name: Container Security Scan
2

3
on:
4
  push:
5
    branches: [main, develop]
6
  pull_request:
7
    branches: [main]
8

9
jobs:
10
  trivy-scan:
11
    runs-on: ubuntu-latest
12
    steps:
13
      - uses: actions/checkout@v4
14

15
      - name: Build Docker Image
16
        run: docker build -t myapp:${{ github.sha }} .
17

18
      - name: Run Trivy Scan
19
        uses: aquasecurity/trivy-action@master
20
        with:
21
          image-ref: 'myapp:${{ github.sha }}'
22
          format: 'sarif'
23
          output: 'trivy-results.sarif'
24
          severity: 'HIGH,CRITICAL'
25
          exit-code: '1'  # 发现高危漏洞就阻断 CI
26

27
      - name: Upload Results to GitHub Security Tab
28
        uses: github/codeql-action/upload-sarif@v3
29
        with:
30
          sarif_file: 'trivy-results.sarif'
31

32
      - name: Notify on Critical Findings
33
        if: failure()
34
        run: |
35
          curl -X POST -H "Content-Type: application/json" \
36
            -d '{"text":"🚨 发现高危容器漏洞！请立即查看：${{ github.server_url }}/${{ github.repository }}/actions"}' \
37
            ${{ secrets.SLACK_WEBHOOK_URL }}

这个流水线执行后，如果你构建的镜像有 HIGH 或 CRITICAL 漏洞，CI 直接红灯——阻断部署。同时扫描结果还会上传到 GitHub Security Tab，方便追踪。

🌐 Kubernetes 集成：定时扫描集群中所有镜像#

在 2026 年，Trivy 还推出了 Operator 模式，可以直接在 K8s 集群中运行，定时扫描所有运行的 Pod 镜像：

1
# 安装 Trivy Operator
2
helm repo add aquasecurity https://aquasecurity.github.io/helm-charts
3
helm install trivy-operator aquasecurity/trivy-operator \
4
  --namespace trivy-system \
5
  --create-namespace \
6
  --set="trivy.ignoreUnfixed=true"

安装完成后，Trivy Operator 会自动发现集群中的所有 Pod，扫描它们的镜像，并以 VulnerabilityReport CRD 的形式存储结果：

1
# 查看所有漏洞报告
2
kubectl get vulnerabilityreports -A
3

4
# 查看某个 Pod 的详细漏洞
5
kubectl get vulnerabilityreport nginx-pod -o yaml

1
apiVersion: aquasecurity.github.io/v1alpha1
2
kind: VulnerabilityReport
3
metadata:
4
  name: nginx-pod
5
  namespace: default
6
report:
7
  artifact:
8
    repository: nginx
9
    tag: "1.25"
10
  summary:
11
    criticalCount: 2
12
    highCount: 8
13
    mediumCount: 32
14
    lowCount: 45
15
  vulnerabilities:
16
    - vulnerabilityID: CVE-2026-1234
17
      severity: CRITICAL
18
      title: "OpenSSL 远程代码执行漏洞"
19
      installedVersion: "3.0.12-1"
20
      fixedVersion: "3.0.13"

💡 我的 Trivy 最佳实践清单#

总结一下我在生产环境中总结的经验：

1
# 1. 扫描同时生成 SBOM（软件物料清单）
2
trivy image --format cyclonedx --output sbom.json myapp:latest
3

4
# 2. 只显示可修复的漏洞（排除无修复方案的）
5
trivy image --ignore-unfixed myapp:latest
6

7
# 3. 扫描文件系统和 Git 仓库
8
trivy fs .
9
trivy repo https://github.com/owner/repo.git
10

11
# 4. 缓存加速（第一次后速度翻倍）
12
trivy image --cache-dir /tmp/trivy-cache myapp:latest
13

14
# 5. JSON 输出集成其他工具
15
trivy image --format json myapp:latest | jq '.Results[].Vulnerabilities[] | select(.Severity=="CRITICAL") | .PkgName'

核心原则就是：不要在 CI 的最后阶段才发现安全问题。越早扫描、越早阻断，修复成本越低。

🎯 总结#

安全在 2026 年已经不是「加分项」而是「准入门槛」了。Trivy 作为最成熟的开源容器安全扫描工具，已经成为 DevOps 工具箱里的瑞士军刀。

如果你的 CI/CD 流水线还没有加 Trivy——你的容器可能正在裸奔。

🏭 真实案例：一次从 Trivy 扫描到漏洞修复的完整流程#

理论说完了，我们走一遍真实的漏洞修复流程。假设你刚用 Trivy 扫出一个 CRITICAL 级别的 OpenSSL 漏洞，现在该怎么办？

第一步：分析漏洞影响#

1
# 查看漏洞详情
2
trivy image --format json myapp:latest | jq '.Results[].Vulnerabilities[] | select(.VulnerabilityID=="CVE-2026-1234")'

输出中会包含漏洞描述、CVSS 评分、受影响的版本范围和修复版本。先确认这个漏洞在你的使用场景下是否真的可利用——有时候 CRITICAL 级别的漏洞在特定配置下其实不可利用，这时候可以先降级处理，不必紧急停机修复。

第二步：确定修复策略#

有三种修复策略可选：

更新基础镜像：找到上游修复了该漏洞的新版本镜像，更新 Dockerfile 中的 FROM 语句。这是最推荐的方式，因为一劳永逸。
添加补丁层：如果不能更新基础镜像（比如依赖了某个特定版本的操作系统），可以在 Dockerfile 中添加 RUN apt-get upgrade 之类的指令来单独升级受影响的包。这种方式比较灵活，但会增加镜像层数。
运行时缓解：如果上述两种方案都不可行，可以通过修改配置或加入安全策略来降低漏洞的实际风险。这只是一种临时方案，不能替代真正的修复。

第三步：实施修复#

以更新基础镜像为例：

1
# 修复前
2
FROM ubuntu:22.04
3

4
# 修复后
5
FROM ubuntu:22.04
6
RUN apt-get update && apt-get install -y libssl3=3.0.13-1

然后重新构建和扫描：

1
docker build -t myapp:fixed .
2
trivy image --severity CRITICAL myapp:fixed

如果输出中不再有 CRITICAL 级别的漏洞，修复就完成了。

第四步：自动化验证#

把 Trivy scan 加入 PR 检查，这样每次提交代码时自动验证新引入的镜像是否安全：

1
# 在 PR 的 CI 中自动扫描
2
trivy image --severity HIGH,CRITICAL --exit-code 1 myapp:pr-${{ github.event.number }}

当 PR 的「Security Check」变成绿色时，你就知道这次改动没有引入新的安全风险。

📊 Trivy 与其他扫描工具的横向对比#

很多团队在选择安全扫描工具时会纠结。下面是 Trivy 和几个主流竞品的对比：

对比维度	Trivy	Clair	Snyk	Grype
安装复杂度	⭐⭐⭐⭐⭐ 单二进制	⭐⭐⭐ 需要 PostgreSQL	⭐⭐⭐⭐ 需注册	⭐⭐⭐⭐ 单二进制
扫描速度	⭐⭐⭐⭐⭐ 极快	⭐⭐⭐ 中等	⭐⭐⭐⭐ 快	⭐⭐⭐⭐ 快
漏洞数据库更新	每天 6 次	每天 1 次	实时	每天 4 次
IaC 扫描	✅	❌	✅	✅
密钥扫描	✅	❌	✅	❌
SBOM 生成	✅ (CycloneDX)	❌	✅	✅
开源/免费	✅ 完全开源	✅ 开源	❌ 商业	✅ 开源
CI 集成	✅ 原生支持	⚠️ 需要适配	✅ 原生支持	✅ 原生支持

从表中可以看出，Trivy 在「功能完整度」和「使用便捷性」之间取得了最佳的平衡。它不需要依赖数据库，不需要注册账号，下载即用。对于中小团队来说，Trivy 是一个性价比极高的选择。

更关键的是，Trivy 的社区非常活跃。截至 2026 年 6 月，GitHub 上已经有超过 25,000 个 star，贡献者超过 600 人。这意味着漏洞数据库的更新速度和质量都有保障——一个新 CVE 公开后，通常几个小时内就会出现在 Trivy 的数据库中。

🎯 从 Trivy 看 DevSecOps 的演进#

Trivy 的流行不是偶然现象，它背后折射出的是 DevSecOps 理念在 2026 年的全面普及。所谓 DevSecOps，就是把安全从左移到开发流程的每一个环节，而不是在最后阶段才请安全团队来「把关」。这种做法在过去几年一直停留在口号阶段，但到了 2026 年，有了 Trivy 这样的工具，DevSecOps 终于变得可操作了。

具体来说，Trivy 帮助企业实现了三个关键目标。第一个目标是「安全的自动化」——以前安全扫描需要专门的安全工程师手动操作，现在 CI/CD 流水线自动触发扫描，开发者在提交代码的几分钟内就能看到安全报告。第二个目标是「安全的可视化」——Trivy 的 SARIF 输出格式可以被 GitHub Security Tab、GitLab Security Dashboard 等平台消费，安全状态一目了然。第三个目标是「安全的可量化」——你可以追踪漏洞数量随时间的趋势，给管理层汇报安全投入的 ROI。

这三个目标的实现，让安全从一个「玄学」变成了「工程」。你是选择在应用上线前三周才发现一堆高危漏洞导致项目延期，还是在每次提交代码时就自动发现并修复问题？答案不言自明。

📈 给团队引入 Trivy 的路线图#

如果你打算在自己的团队中推广 Trivy，我建议分四个阶段推进。第一阶段是「信息收集期」——先让 Trivy 以只读模式运行，只报告不阻断。这个阶段持续一到两周，目的是了解当前的安全基线，统计现有项目的漏洞分布情况。第二阶段是「告警期」——开启 CI 中的告警机制，让开发者能在 PR 中看到安全扫描结果，但暂不阻断构建。这个阶段是培养安全意识的过程，让团队逐步接受「安全也是代码质量的一部分」这个理念。第三阶段是「强制期」——对 HIGH 和 CRITICAL 级别的漏洞开启阻断，CI 不通过不能合并。这个阶段可能会遇到一些阻力，因为老项目可能积累了不少漏洞需要清理，建议给团队一两个月的缓冲期来修复存量问题。第四阶段是「优化期」——引入自定义策略、忽略误报、集成到 K8s 运行时扫描。到这个阶段，安全已经是团队日常工作的一部分了，不需要额外的推动和监督。

我自己带的团队花了大约三个月走完这四个阶段。最痛苦的是第二阶段到第三阶段的过渡——因为清理历史积累的高危漏洞花了不少功夫。但熬过去之后，安全再也不是让人头疼的话题了，而是像代码风格检查一样自然的流程。

🧪 实战案例：一次真实的容器漏洞应急响应#

去年我们遇到过一次真实的容器安全事件，分享一下整个过程，希望能帮助大家建立应对突发事件的心理准备。

那天是周四下午，我的手机突然收到 PagerDuty 的告警——Trivy Operator 在生产环境的某个 Pod 中检测到了一个 CRITICAL 级别的远程代码执行漏洞。当时的第一反应是有点慌的，但很快冷静下来，因为我们已经为这种场景制定过应急预案。

第一步是确认漏洞的可利用性。我们通过 Trivy 的 JSON 输出查看了漏洞的详情，发现它影响的是 OpenSSL 3.0.12 版本。好消息是这个漏洞需要特定的攻击向量才能利用，而我们的网络策略限制了 Pod 的入站流量。经过安全团队的评估，我们决定将响应级别从「紧急」降为「高」。

第二步是制定修复计划。受影响的镜像是一个内部工具，依赖了 Ubuntu 22.04 的基础镜像。最快的修复方式是升级基础镜像到 Ubuntu 22.04 LTS 的最新补丁版本。我们在 Dockerfile 中增加了 apt-get upgrade 指令来升级 OpenSSL。

第三步是灰度发布。我们把修复后的镜像先部署到 staging 环境，通过 Trivy 重新扫描确认漏洞已修复，然后让 QA 团队做了快速回归测试。整个过程用时不到两小时。

第四步是生产部署。我们采用滚动更新的方式逐步替换生产环境中的 Pod，同时通过 Grafana 监控应用的错误率和响应时间。滚动更新完成后，Trivy Operator 自动重新扫描，确认漏洞不再存在。

从收到告警到完全修复，整个过程用了大约四个小时。事后我们做了一次复盘，总结了两条经验：第一，提前制定应急预案比事发时再想办法要有效得多——我们这次能这么快响应，全靠之前就已经把 Trivy 的告警和值班流程打通了。第二，Trivy 的 SBOM 生成功能在事后分析中帮了大忙——我们可以精确地知道每个镜像中包含了哪些依赖，而不需要去翻 Dockerfile。

这件事让我更加坚信：容器的安全不是一个「要不要做」的问题，而是一个「如何做得更好」的问题。Trivy 让你至少知道自己的「敌人」在哪，这是安全防御的第一步，也是最关键的一步。

🔮 容器安全的未来趋势#

站在 2026 年这个时间点回望，容器安全领域在过去几年经历了巨大的变化。展望未来，我认为有几个值得关注的方向。第一个方向是基于 AI 的漏洞分析与修复建议——未来的 Trivy 可能不只是告诉你「有这个漏洞」，而是能自动分析漏洞在你的特定环境中是否可利用，甚至能生成修复补丁。第二个方向是运行时安全的深度集成——目前的 Trivy 主要做的是「镜像扫描」，也就是在部署之前检查镜像的安全性。未来会有更多「运行时检测」的能力，比如监控容器中的异常进程行为、检测容器逃逸攻击等。第三个方向是供应链安全的端到端覆盖——从代码提交、镜像构建、制品仓库到生产部署，整个链路的每一个环节都要有安全扫描。Trivy 已经在朝这个方向演进，它新增的 SBOM 生成和 IaC 扫描能力就是证明。

对于开发者来说，这意味着安全能力的门槛在持续降低。五年前你要成为一个容器安全专家才能保护好你的集群，现在你只需要在 CI 里加一行 trivy image 就能覆盖大部分安全需求。这在几年前是不可想象的。工具在进步，安全在民主化，这对整个行业来说是一件好事。