4、镜像漏洞扫描：Trivy工具安装与使用、Clair集成、漏洞报告解读与修复策略

4.1 为什么我们需要镜像漏洞扫描？

说实话，我见过太多团队把镜像往仓库里一推就完事了。他们觉得「基础镜像都是官方的，能有什么问题？」

嗯，问题大了去了。官方镜像也会包含已知漏洞。比如一个老版本的Alpine，里面可能藏着几十个CVE。你想想看，这些漏洞一旦被利用，整个生产环境就裸奔了。

我个人习惯是：任何镜像在进入生产环境之前，必须经过漏洞扫描。这不是可选项，是底线。

4.2 Trivy：轻量级但够用

Trivy是我用得最多的工具。为什么？因为它简单、快、而且覆盖全面。

4.2.1 安装Trivy

安装方式很多，我推荐用官方脚本，省心。

# 一键安装
curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh

# 或者用Homebrew（macOS）
brew install trivy

# 或者用Docker直接跑
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock aquasec/trivy image nginx:latest

装完之后，验证一下版本：

trivy --version
我的小习惯： 我会把Trivy集成到CI/CD流水线里。每次构建完镜像，自动跑一次扫描。如果发现高危漏洞，直接阻断构建。

4.2.2 扫描镜像

基本用法很简单：

trivy image nginx:1.21

输出结果会列出所有漏洞，按严重程度排序。你会看到类似这样的信息：

nginx:1.21 (debian 11.6)
===========================
Total: 45 (UNKNOWN: 0, LOW: 12, MEDIUM: 20, HIGH: 10, CRITICAL: 3)

我曾经在一个客户的镜像里扫出过3个CRITICAL级别的漏洞。客户当时还觉得「没事，跑了好几个月了」。我给他们看了漏洞详情——全是远程代码执行。嗯，他们当天就改了。

4.2.3 输出格式

Trivy支持多种输出格式。我个人喜欢用JSON或HTML，方便集成到报告系统。

# JSON格式
trivy image --format json --output result.json nginx:1.21

# HTML格式（需要安装trivy-to-html）
trivy image --format template --template "@contrib/html.tpl" -o report.html nginx:1.21
重要： 扫描结果中，重点关注CRITICAL和HIGH级别的漏洞。LOW和MEDIUM可以排期修复，但高危漏洞必须立即处理。

4.3 Clair：企业级集成方案

Clair是另一个老牌的漏洞扫描工具。它和Trivy最大的区别是：Clair更偏向于服务端部署，适合大规模镜像仓库的持续扫描。

4.3.1 Clair架构

Clair由几个组件组成：

  • Clair API：接收镜像扫描请求
  • Clair Updater：定期更新漏洞数据库
  • Clair Matcher：将镜像层与漏洞进行匹配

说白了，Clair是一个后台服务。你把镜像推送过去，它异步扫描，然后返回结果。

4.3.2 集成Clair到Harbor

如果你在用Harbor作为镜像仓库，集成Clair非常方便。Harbor从2.0版本开始内置了Clair。

配置步骤大致如下：

  1. 安装Harbor时，启用Clair组件
  2. 配置Clair的漏洞数据库更新策略
  3. 在Harbor UI中开启「自动扫描」
# harbor.yml 配置片段
clair:
  enabled: true
  updaters_interval: 12h  # 每12小时更新一次漏洞库
注意： Clair的漏洞数据库更新需要联网。如果你的环境是离线环境，需要手动导入漏洞数据。我曾经在离线项目里折腾了两天才搞定这个。

4.4 漏洞报告解读

拿到扫描报告后，怎么看？很多人只盯着「CRITICAL」几个字，其实不够。

4.4.1 报告结构

一份典型的漏洞报告包含：

字段 说明
CVE编号 漏洞的唯一标识，比如CVE-2023-1234
严重程度 CRITICAL / HIGH / MEDIUM / LOW
受影响的包 比如openssl、libcurl等
当前版本 镜像中实际使用的版本
修复版本 升级到哪个版本可以修复
描述 漏洞的简要说明

4.4.2 如何判断优先级？

我一般按这个顺序处理：

  • CRITICAL + 可远程利用：立即修复，阻断上线
  • CRITICAL + 本地利用：24小时内修复
  • HIGH：排入下一个迭代
  • MEDIUM / LOW：记录到技术债务，定期清理
避坑指南： 我曾经遇到过一种情况——扫描报告显示有CRITICAL漏洞，但仔细一看，那个漏洞只影响Windows系统，而我们的镜像跑在Linux上。所以，一定要看漏洞的适用范围，别盲目升级。

4.5 修复策略

修复漏洞，说白了就是升级依赖。但怎么升级，有讲究。

4.5.1 升级基础镜像

最直接的方法：换一个更新的基础镜像。

# 旧版本
FROM node:14-alpine

# 新版本
FROM node:18-alpine

但要注意，大版本升级可能带来兼容性问题。我建议先在小范围测试。

4.5.2 单独升级包

如果不想换基础镜像，可以单独升级有漏洞的包。

# 在Dockerfile中
FROM ubuntu:20.04
RUN apt-get update && apt-get install -y \
    openssl=1.1.1f-1ubuntu2.16 \
    && rm -rf /var/lib/apt/lists/*

4.5.3 使用多阶段构建

多阶段构建可以减少最终镜像中的漏洞数量。因为你可以只复制必要的二进制文件，不包含构建工具链。

# 构建阶段
FROM golang:1.19 AS builder
WORKDIR /app
COPY . .
RUN go build -o myapp

# 运行阶段
FROM alpine:3.17
COPY --from=builder /app/myapp /usr/local/bin/
CMD ["myapp"]

你看，运行阶段只用了Alpine，没有Go编译器，漏洞面自然小很多。

4.5.4 定期扫描与自动化

我建议把漏洞扫描做成自动化任务：

  • 每次构建镜像时自动扫描
  • 每周对仓库中所有镜像做一次全量扫描
  • 漏洞数据库更新后，重新扫描历史镜像
我的经验： 在CI/CD中，我会设置一个阈值。比如「如果CRITICAL漏洞超过5个，构建失败」。这样能强制团队及时修复。

4.6 总结

镜像漏洞扫描不是一次性工作，而是持续的过程。Trivy适合快速扫描和CI集成，Clair适合企业级仓库管理。拿到报告后，别慌，按优先级处理。修复时优先考虑升级基础镜像，其次单独升级包。

嗯，最后说一句：安全不是某个人的事，是每个人的事。把扫描工具用起来，把修复流程跑起来，你的容器环境会安全很多。

← 上一章 📖 返回目录 下一章 →