Linux系统下安装Trivy

1.1 添加 Trivy 官方 YUM 源

首先，创建 Trivy 的 YUM 仓库配置文件。

bash

复制代码

sudo tee /etc/yum.repos.d/trivy.repo << 'EOF'
[trivy]
name=Trivy repository
baseurl=https://aquasecurity.github.io/trivy-repo/rpm/releases/$basearch/
gpgcheck=1
enabled=1
gpgkey=https://aquasecurity.github.io/trivy-repo/rpm/public.key
EOF

1.2 执行 YUM 安装

添加源后，更新 YUM 缓存并安装 Trivy：

bash

复制代码

sudo yum update
sudo yum install trivy -y

安装完成后，验证是否成功：

bash

复制代码

trivy --version

2. 首次扫描：数据库下载超时

拉取待扫描的测试镜像，并执行基础扫描命令：

bash

复制代码

docker pull tomcat:9.0.110-jdk11
trivy image tomcat:9.0.110-jdk11

此时极大概率会出现典型的网络超时错误，如下所示：

text

复制代码

FATAL failed to download vulnerability DB: OCI artifact error: 
Get "https://mirror.gcr.io/v2/": dial tcp 173.194.202.82:443: connect: connection timed out

原因：Trivy 默认的漏洞数据库源 mirror.gcr.io 在国内访问不稳定，需要更换为国内镜像源。

2.1 使用国内镜像源下载数据库

Trivy 支持通过命令行参数指定漏洞库和 Java 库的国内镜像地址，从而大幅提升下载速度：

bash

复制代码

trivy image \
  --db-repository ghcr.nju.edu.cn/aquasecurity/trivy-db:2 \
  --java-db-repository ghcr.nju.edu.cn/aquasecurity/trivy-java-db:1 \
  tomcat:9.0.110-jdk11

这样便解决了数据库下载超时的问题。

3. 遇到的常见报错及解决方法

在实际扫描过程中，还可能会遇到以下两种典型错误。

3.1 缓存锁错误

报错信息：

text

复制代码

FATAL run error: ... cache may be in use by another process: timeout

原因：Trivy 使用基于文件的 BoltDB 进行缓存管理，BoltDB 存在文件锁限制，如果同时运行了多个 Trivy 进程，或上次扫描未正常释放锁，就会导致此错误。

解决方案 ：使用 --cache-backend memory 参数，将缓存存储在内存中，以避免文件锁冲突。

bash

复制代码

trivy image ... --cache-backend memory

3.2 扫描超时

报错信息：

text

复制代码

FATAL ... context deadline exceeded

原因：tomcat:9.0.110-jdk11 镜像体积较大，包含完整的 JDK，默认的超时时间可能不足。

解决方案 ：通过 --timeout 参数增加超时时间，例如设置为 30 分钟。

bash

复制代码

trivy image ... --timeout 30m

综合以上调整，最终可用的完整扫描命令为：

bash

复制代码

trivy image \
  --db-repository ghcr.nju.edu.cn/aquasecurity/trivy-db:2 \
  --java-db-repository ghcr.nju.edu.cn/aquasecurity/trivy-java-db:1 \
  --cache-backend memory \
  --timeout 30m \
  tomcat:9.0.110-jdk11

4. 扫描结果分析与漏洞修复

扫描完成后，Trivy 会输出详细的汇总表和漏洞列表。以下是对扫描报告的解读与分析。

4.1 扫描结果总览

目标	类型	漏洞数
`tomcat:9.0.110-jdk11` (Ubuntu 24.04)	操作系统	86
各类 Tomcat 及业务 JAR 包	Java 依赖	3+

分析：

操作系统漏洞 ：共86个，其中 LOW 36个，MEDIUM 41个，HIGH 9个，CRITICAL 0个。
Java 依赖漏洞 ：业务 WAR 包中的依赖库（如 commons-collections、log4j 等）暴露了多个 CRITICAL 和 HIGH 级别的漏洞。

4.2 高危漏洞分析与修复

组件	CVE	严重度	漏洞描述	修复建议
`tomcat-coyote.jar` (Tomcat)	CVE-2026-24734	HIGH	OCSP 证书撤销检查绕过，可能导致中间人攻击	立即升级 Tomcat ：将基础镜像版本从 `9.0.110` 升级到 `9.0.115` 或更高。
`dirmngr` / `gnupg` (系统包)	CVE-2025-68973	HIGH	信息泄露或任意代码执行	更新系统包：在 Dockerfile 中添加 `RUN apt-get update && apt-get upgrade -y && apt-get clean`。
`commons-collections` (WAR包)	CVE-2015-7501	CRITICAL	反序列化远程代码执行（RCE）	升级或排除依赖：将 `commons-collections` 升级到 3.2.2 版本。
`log4j` (WAR包)	多个	CRITICAL	JMSAppender RCE、SocketServer 反序列化等	迁移到 Log4j 2.x ：`log4j` 1.x 版本已停止维护，必须升级到 2.x 版本或使用 `logback` 替代。

总结：WAR 包内的第三方依赖库是此次扫描的重灾区，修复重点应放在应用依赖的升级上，而非仅仅替换 Tomcat 或 JDK。

4.3 生成详细的漏洞报告

为了方便归档或与团队分享，可以将扫描结果导出为文件。

bash

复制代码

# 导出为 JSON 格式
trivy image --format json --output report.json tomcat:9.0.110-jdk11

# 导出为表格格式（便于查看）
trivy image --format table --output report.txt tomcat:9.0.110-jdk11

# 仅导出高危和严重漏洞，减少报告噪音
trivy image --severity HIGH,CRITICAL --format json --output high-critical-report.json tomcat:9.0.110-jdk11

5. 总结

本次实战涵盖了 Trivy 在麒麟操作系统上的 YUM 安装、国内网络环境下的数据库源配置、典型错误（锁、超时）的排查，以及对一份真实扫描报告的分析与修复。最终结论如下：

安全状况：镜像本身无 CRITICAL 漏洞，但业务应用依赖库存在严重安全隐患。
修复重点 ：WAR 包内的第三方依赖库（如 commons-collections, log4j 等）是此次扫描的重灾区，修复重点应放在应用依赖的升级上，而非仅仅替换 Tomcat 或 JDK。
建立流程：建议将 Trivy 集成到 CI/CD 流水线中，每次构建后自动扫描，实现"安全左移"。

附录：常用 Trivy 命令速查

bash

复制代码

# 国内镜像 + 内存缓存 + 长超时
trivy image --db-repository ghcr.nju.edu.cn/aquasecurity/trivy-db:2 \
            --java-db-repository ghcr.nju.edu.cn/aquasecurity/trivy-java-db:1 \
            --cache-backend memory --timeout 30m <image_name>

# 仅扫描高危及以上漏洞，并返回非零退出码（用于 CI）
trivy image --severity HIGH,CRITICAL --exit-code 1 <image_name>

# 跳过数据库更新（离线使用）
trivy image --skip-db-update --skip-java-db-update <image_name>