Trivy指南：39k星容器漏洞扫描，镜像/依赖/密钥一站式检测

项目：aquasecurity/trivy | 星数：38838 | 语言：Go | 协议：Apache-2.0 | GitHub仓库

更新日期：2026-10-30 · 作者：CodeArts 编辑部

镜像里的漏洞，上线后才发现就晚了

有次客户做渗透测试，报上来一条高危漏洞：某开源组件的 CVE 早在两年前就修复了，但我们的镜像基础层一直没更新。那次之后我把漏洞扫描加进了 CI，用的就是 Trivy。38838 星、Apache-2.0，单二进制、零配置起步，是这类工具里门槛最低的一个。

Trivy 能扫的不只是镜像：容器镜像、文件系统、Git 仓库、Kubernetes 集群、IaC 文件（Terraform/Helm/Dockerfile）它都能查，覆盖漏洞、密钥泄露、配置错误、许可证四类问题。

四类扫描目标

命令	扫什么	典型用途
trivy image	容器镜像的所有层	上线前查基础镜像漏洞
trivy fs	本地目录（含 lock 文件）	提交前查依赖漏洞与密钥
trivy repo	远程 Git 仓库	审查第三方代码引入
trivy config	IaC 与配置文件	上线前查 Dockerfile 与 K8s 配置

实际使用中，trivy fs 的性价比最高。它靠 package-lock.json、requirements.txt、go.sum 这类文件反查依赖版本，不需要构建镜像，几秒就能出结果。

先跑起来

# macOS
brew install trivy

# 通用：容器方式（无需安装）
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
  aquasec/trivy image python:3.4-alpine

# 扫本地项目依赖与密钥
trivy fs --scanners vuln,secret,misconfig ./myproject

# 只看高危及以上，输出表格
trivy image --severity HIGH,CRITICAL myapp:latest

第一次运行会下载漏洞数据库，国内网络可能很慢甚至失败。可以指定镜像源：

trivy image --db-repository mirrors.tencent.com/trivy-db myapp:latest

接入 CI：卡住真正该卡的问题

最常见的做法是「发现高危就失败」。但直接这么配，第一次跑会发现几十上百个漏洞，全部要修，团队很快就烦了，最后把整个检查关掉。我的做法是分三步走：

1. 先只报告不拦截：跑一周，看看真实基线是多少。
2. 把已知的历史漏洞写进 .trivyignore，带失败原因和复查日期，只让新增漏洞拦截。
3. 只拦 CRITICAL 和可修复的 HIGH，不可修复的漏洞单独进看板，不强求。

# .trivyignore
# 2026-10-01 上游未发布修复版本，2027-01-01 复查
CVE-2025-12345

--ignore-unfixed 这个参数很关键。它跳过「有漏洞但没有可用修复版本」的条目，能把噪音降低一大半——否则团队会被一堆根本修不了的告警拖垮。

基础镜像选择的影响有多大

我做过一次对比：同一个 Node 应用，分别用 node:20、node:20-slim、node:20-alpine、distroless 作为基础镜像扫描。结论很直观——镜像越小，继承的漏洞越少。

基础镜像	体积量级	漏洞倾向
node:20（完整版）	约 1GB	多，含大量系统包
node:20-slim	约 200MB	中等
node:20-alpine	约 130MB	少，但 musl 兼容需注意
distroless	更小	最少，但调试困难

所以最有效的"漏洞治理"不是逐个打补丁，而是换一个更小的基础镜像。一条 FROM 改动抵得上修三十个 CVE。

常见坑

第一，扫出来一堆 Node/Python 依赖漏洞但报的是系统包路径——那是因为镜像里存在多份副本，看漏洞的 PkgPath 字段定位真正的问题包。

第二，--scanners secret 会把测试文件里的假密钥也报出来，容易淹没真问题。密钥扫描建议单独一条命令跑，并且只扫 git 跟踪的文件。

第三，扫描结果里的 Fixed Version 为空时不要慌，说明上游还没发版，加进 ignore 列表并设置复查时间即可。