3. 镜像漏洞扫描：Trivy 与 Clair 工具使用、CVE 库更新策略、扫描结果解读与修复流程

镜像漏洞扫描是容器安全左移的核心实践。在 Kubernetes 准入控制链中，扫描结果直接决定镜像是否允许运行。本章聚焦两款主流开源扫描器——Trivy（轻量、全语言支持）与 Clair（静态分析、API 驱动），覆盖工具部署、CVE 库更新、结果解读与修复闭环。

3.1 工具选型对比：Trivy vs Clair

3.2 Trivy 实战：安装、扫描与 CI 集成

3.2.1 安装与基础扫描

# 安装 Trivy（Linux / macOS）
curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh

# 扫描本地镜像
trivy image nginx:1.25.3

# 扫描并输出 JSON 格式（便于后续解析）
trivy image --format json --output nginx-scan.json nginx:1.25.3

# 仅输出高危及以上漏洞
trivy image --severity CRITICAL,HIGH nginx:1.25.3

3.2.2 CVE 库更新策略

Trivy 默认在首次运行时下载完整 CVE 数据库（约 500MB），后续增量更新。生产环境建议使用持久化缓存目录，避免每次 CI 构建重复下载。

# 指定缓存目录（挂载持久卷）
trivy image --cache-dir /data/trivy-cache nginx:1.25.3

# 手动更新数据库（不扫描）
trivy image --download-db-only --cache-dir /data/trivy-cache

# 使用私有镜像仓库时，设置认证
export TRIVY_USERNAME=myuser
export TRIVY_PASSWORD=mypass
trivy image registry.example.com/myapp:v1.0

3.2.3 CI/CD 流水线集成（GitLab CI 示例）

# .gitlab-ci.yml 片段
container_scan:
  stage: test
  image: aquasec/trivy:latest
  script:
    - trivy image --severity CRITICAL,HIGH --exit-code 1 myapp:${CI_COMMIT_SHA}
  only:
    - main

当扫描到 CRITICAL 或 HIGH 漏洞时，流水线失败，阻止镜像进入生产仓库。

3.3 Clair 实战：服务部署与 API 调用

3.3.1 使用 Docker Compose 部署 Clair

# docker-compose.yml
version: '3.8'
services:
  clair-db:
    image: postgres:15
    environment:
      POSTGRES_PASSWORD: clairpass
      POSTGRES_DB: clair
  clair:
    image: quay.io/projectquay/clair:4.7
    depends_on:
      - clair-db
    ports:
      - "6060:6060"
      - "6061:6061"
    environment:
      CLAIR_CONNECTION_STRING: host=clair-db port=5432 dbname=clair user=postgres password=clairpass sslmode=disable

3.3.2 推送镜像并获取扫描结果

# 使用 clairctl 推送镜像
clairctl --config clairctl.yaml push myapp:latest

# 获取漏洞报告（JSON）
clairctl --config clairctl.yaml report myapp:latest

# 通过 API 查询（需先获取 manifest hash）
curl -s "http://localhost:6061/v4/clair/vulnerabilities?manifest_hash=sha256:xxx" | jq .

3.4 扫描结果解读与修复流程

3.4.1 漏洞报告结构（Trivy JSON 示例）

{
  "Results": [
    {
      "Target": "nginx:1.25.3 (debian 12.0)",
      "Vulnerabilities": [
        {
          "VulnerabilityID": "CVE-2024-1234",
          "PkgName": "libssl3",
          "Severity": "CRITICAL",
          "InstalledVersion": "3.0.11-1",
          "FixedVersion": "3.0.12-1",
          "Title": "OpenSSL: Buffer overflow in X.509 certificate verification",
          "Description": "A flaw in the X.509 certificate verification...",
          "References": ["https://nvd.nist.gov/vuln/detail/CVE-2024-1234"]
        }
      ]
    }
  ]
}

3.4.2 修复优先级矩阵

3.4.3 修复流程（五步闭环）

1. 识别：通过 Trivy/Clair 扫描获取 CVE 列表，标记受影响镜像。
2. 评估：确认漏洞是否影响运行时逻辑（如 libc 漏洞在静态编译 Go 应用中可能不适用）。
3. 修复：升级基础镜像版本（如 FROM nginx:1.25.3 → FROM nginx:1.26.0），或使用 apt-get upgrade 安装补丁。
4. 验证：重新构建镜像并扫描，确认漏洞消失。
5. 部署：通过 K8s 滚动更新替换旧 Pod，确保准入控制策略只允许已修复镜像。

3.5 镜像漏洞扫描与准入控制联动架构

下图展示扫描结果如何通过 Admission Webhook 阻断高风险镜像进入集群：

3.6 常见问题与避坑指南

• 误报处理：Trivy 可能将“未修复但无利用条件”的漏洞标记为高危。建议建立 .trivyignore 文件，按 CVE ID 或包名豁免。
• 数据库同步延迟：Clair 的 updater 默认每 6 小时同步一次 NVD。新披露的 0-day 可能延迟进入扫描结果。可手动触发 clairctl health 检查同步状态。
• 镜像层缓存：Trivy 扫描时若缓存目录权限不足，会报错 permission denied。确保 CI 容器内 /tmp/trivy 可写。
• 多架构镜像：扫描 --platform linux/arm64 时，Trivy 需下载对应架构的数据库。使用 --skip-db-update 可复用已有缓存。