10.1 容器安全：Trivy 镜像漏洞扫描

预计阅读时间：15 分钟

Trivy 是 Aqua Security 开源的容器安全工具，用于扫描容器镜像、文件系统、Git 仓库中的已知漏洞（CVE）和错误配置。它以速度快、覆盖全、易集成著称。Trivy 支持多种扫描目标，包括 OCI 镜像、本地文件系统、Git 仓库、Kubernetes 集群以及基础设施即代码（IaC）配置文件。与其他安全工具相比，Trivy 的优势在于零配置即可使用，内置漏洞数据库自动更新，且不需要额外的服务器或数据库。

学习目标

• 掌握 Trivy 的安装方式和基本命令，能够独立扫描容器镜像漏洞
• 理解 CVE 漏洞的严重性分级（CRITICAL / HIGH / MEDIUM / LOW），并能正确解读扫描结果
• 能够将 Trivy 集成到 CI/CD 流水线中，实现构建时自动漏洞门禁
• 了解 Trivy 的多种扫描模式（镜像、文件系统、仓库、K8s 集群、IaC 配置）及其适用场景

前置知识

• Linux 基本命令操作（包管理器、文件系统导航）
• Docker 基础概念（镜像、容器、Dockerfile、镜像分层）
• CI/CD 基本概念（GitHub Actions 或其他流水线工具）
• 了解 CVE（Common Vulnerabilities and Exposures）漏洞编号体系
• 基础的 YAML 语法（用于编写 GitHub Actions 配置）

安装 Trivy

# Ubuntu / Debian（推荐方式，使用 /etc/apt/keyrings/）
sudo apt-get install -y wget apt-transport-https
sudo mkdir -p /etc/apt/keyrings
wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key | gpg --dearmor | sudo tee /etc/apt/keyrings/trivy.gpg > /dev/null
echo "deb [signed-by=/etc/apt/keyrings/trivy.gpg] https://aquasecurity.github.io/trivy-repo/deb $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/trivy.list
sudo apt-get update && sudo apt-get install -y trivy

# 注意：apt-key 在 Debian 11+/Ubuntu 22.04+ 中已弃用，上述方式使用 /etc/apt/keyrings/ 存储密钥

# 直接用二进制（适合 CI）
wget https://github.com/aquasecurity/trivy/releases/download/v0.57.0/trivy_0.57.0_Linux-64bit.deb
sudo dpkg -i trivy_0.57.0_Linux-64bit.deb

# 验证
trivy --version

安装方式对比

1. 扫描容器镜像

# 扫描本地 Docker 镜像
trivy image nginx:1.25

# 扫描远程镜像（无需拉取）
trivy image docker.io/nginx:1.25

# 只输出高危和严重漏洞
trivy image --severity HIGH,CRITICAL nginx:1.25

# 输出 JSON 格式（集成用）
trivy image --format json --output nginx-vulns.json nginx:1.25

# 忽略已修复的漏洞（只显示未修复的）
trivy image --ignore-unfixed nginx:1.25

# 扫描多个镜像
trivy image nginx:1.25 redis:7.2 postgres:16

# 使用自定义漏洞数据库
trivy image --db-repository ghcr.io/aquasecurity/trivy-db nginx:1.25

# 扫描但不更新数据库（离线环境）
trivy image --skip-db-update nginx:1.25

扫描输出格式详解

# 表格格式（默认，人类可读）
trivy image --format table nginx:1.25

# JSON 格式（程序解析用，包含完整漏洞信息）
trivy image --format json nginx:1.25
# JSON 输出包含：Results[].Vulnerabilities[].VulnerabilityID, Severity, FixedVersion 等字段

# SARIF 格式（GitHub Code Scanning 集成）
trivy image --format sarif --output results.sarif nginx:1.25

# CycloneDX 格式（SBOM 软件物料清单）
trivy image --format cyclonedx --output sbom.json nginx:1.25

# 只输出漏洞列表（精简格式）
trivy image --format json --output vulns.json nginx:1.25
cat vulns.json | jq '.Results[].Vulnerabilities[] | {id: .VulnerabilityID, severity: .Severity, pkg: .PkgName}'

2. 理解扫描结果

# 输出示例（简化）：
# nginx:1.25 (debian 12.0)
# ==============================
# Total: 85 (UNKNOWN: 0, LOW: 40, MEDIUM: 35, HIGH: 8, CRITICAL: 2)
#
# ┌─────────┬────────────────┬──────────┬──────────────────────────┐
# │ LIBRARY │ VULNERABILITY  │ SEVERITY │ FIXED VERSION            │
# ├─────────┼────────────────┼──────────┼──────────────────────────┤
# │ openssl │ CVE-2024-XXXX  │ CRITICAL │ 3.0.12-1                 │
# │ zlib    │ CVE-2024-YYYY  │ HIGH     │ 1:1.2.13.dfsg-1          │
# │ curl    │ CVE-2024-ZZZZ  │ MEDIUM   │ 7.88.1-10+deb12u5        │
# └─────────┴────────────────┴──────────┴──────────────────────────┘

解读要点：

• Library：有漏洞的系统库或应用依赖
• Severity：CRITICAL > HIGH > MEDIUM > LOW
• Fixed Version：修复此漏洞的版本号——升级到此版本即可修复
• 忽略未修复：有些漏洞尚无修复版本，需额外评估
• Totals 统计：快速了解镜像整体安全状况，CRITICAL 数量为 0 是基本要求

CVSS 评分参考

3. 集成到 CI/CD

# GitHub Actions 示例
name: Container Security Scan
on:
  push:
    branches: [main]
jobs:
  trivy-scan:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4

    - name: Build image
      run: docker build -t myapp:${{ github.sha }} .

    - name: Run Trivy scan
      uses: aquasecurity/trivy-action@master
      with:
        image-ref: myapp:${{ github.sha }}
        format: sarif
        output: trivy-results.sarif
        severity: HIGH,CRITICAL

    - name: Upload results
      uses: github/codeql-action/upload-sarif@v3
      with:
        sarif_file: trivy-results.sarif

GitLab CI 集成示例

# .gitlab-ci.yml
trivy-scan:
  stage: test
  image:
    name: aquasec/trivy:latest
    entrypoint: [""]
  script:
    - trivy image --exit-code 1 --severity HIGH,CRITICAL --format json --output trivy.json $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
    - cat trivy.json
  artifacts:
    reports:
      container_scanning: trivy.json
  only:
    - main
    - merge_requests

Jenkins Pipeline 集成

// Jenkinsfile
pipeline {
    agent any
    stages {
        stage('Build') {
            steps {
                sh 'docker build -t myapp:${BUILD_NUMBER} .'
            }
        }
        stage('Trivy Scan') {
            steps {
                sh '''
                    trivy image --exit-code 1 \
                      --severity HIGH,CRITICAL \
                      --format json \
                      --output trivy-results.json \
                      myapp:${BUILD_NUMBER}
                '''
            }
            post {
                always {
                    archiveArtifacts artifacts: 'trivy-results.json'
                }
            }
        }
    }
}

4. 其他扫描模式

# 扫描文件系统（本地目录）
trivy filesystem --severity HIGH,CRITICAL /path/to/project

# 扫描 Git 仓库
trivy repo https://github.com/example/myapp

# 扫描 Kubernetes 集群
trivy k8s --report summary cluster

# 扫描 IaC 配置（Terraform/Dockerfile/K8s manifest）
trivy config --severity HIGH,CRITICAL ./deploy/

# 扫描 SBOM（软件物料清单）
trivy sbom ./sbom.json

# 扫描 Rootless 容器
trivy image --rootless nginx:1.25

各扫描模式适用场景对比

5. 阈值门禁（CI 中断策略）

# 当发现严重漏洞时使 CI 失败
trivy image --exit-code 0 --severity MEDIUM,LOW nginx:1.25
trivy image --exit-code 1 --severity HIGH,CRITICAL nginx:1.25

# 结合 --ignorefile（忽略已知误报）
trivy image --ignorefile .trivyignore nginx:1.25

# .trivyignore 文件格式：
# CVE-2024-XXXX
# CVE-2024-YYYY  # 这个是误报，已确认

exit-code 详解

# exit-code 0：无论是否发现漏洞，始终返回 0（CI 不中断）
trivy image --exit-code 0 nginx:1.25

# exit-code 1：发现指定严重性漏洞时返回 1（CI 中断）
trivy image --exit-code 1 --severity HIGH,CRITICAL nginx:1.25

# 组合策略：低危告警但不阻断，高危阻断
trivy image --exit-code 0 --severity LOW,MEDIUM nginx:1.25  # 记录但不阻断
trivy image --exit-code 1 --severity HIGH,CRITICAL nginx:1.25  # 阻断部署

.trivyignore 高级用法

# .trivyignore 示例
# 忽略特定 CVE
CVE-2024-XXXXX

# 忽略特定 CVE 并添加注释说明原因
CVE-2024-YYYYY  # 已确认为误报，该漏洞不影响我们的使用场景

# 忽略特定包的所有漏洞
CVE-2023-0001  # 只影响 Windows，我们运行在 Linux 上

# 忽略所有 LOW 级别漏洞（也可以用命令行 --ignore-unfixed 代替）

6. 漏洞数据库管理

# Trivy 内置漏洞数据库来源
# - NVD（National Vulnerability Database）
# - Debian Security Tracker
# - Ubuntu CVE Tracker
# - Red Hat Security Data
# - Alpine SecDB
# - GitHub Advisory Database

# 手动更新漏洞数据库
trivy image --download-db-only

# 指定数据库缓存目录
trivy image --cache-dir /tmp/trivy-cache nginx:1.25

# 离线环境：先导出数据库，再导入
# 在有网络的机器上：
trivy image --download-db-only --cache-dir /tmp/trivy-db
tar czf trivy-db.tar.gz -C /tmp trivy-db

# 在离线机器上：
tar xzf trivy-db.tar.gz -C /tmp
trivy image --cache-dir /tmp/trivy-db nginx:1.25

7. 扫描 Dockerfile 安全配置

# Trivy 也能检查 Dockerfile 中的安全问题
trivy config --severity HIGH,CRITICAL ./Dockerfile

# 常见 Dockerfile 安全问题
# 1. 使用 root 用户运行（缺少 USER 指令）
# 2. 暴露不必要的端口
# 3. 使用 latest 标签（不可复现）
# 4. 复制敏感文件（如 .env、私钥）
# 5. 安装不必要的包（增大攻击面）

# 好的 Dockerfile 示例
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
RUN npm run build

FROM node:20-alpine
RUN addgroup -g 1001 appgroup && adduser -u 1001 -G appgroup -s /bin/sh -D appuser
WORKDIR /app
COPY --from=builder --chown=appuser:appgroup /app/dist ./dist
COPY --from=builder --chown=appuser:appgroup /app/node_modules ./node_modules
USER appuser
EXPOSE 3000
CMD ["node", "dist/index.js"]

8. CVE 体系与漏洞数据

Trivy 报出的每个漏洞都来自公开漏洞数据库，理解 CVE 体系才能正确解读"这个漏洞有多严重"：

• CVE 编号：CVE-年份-序号（如 CVE-2024-3094），由 CVE 编号机构（CNA）分配，是漏洞的"身份证号"
• CVSS 评分：衡量可利用性的标准向量（AV 攻击途径 / AC 攻击复杂度 / PR 所需权限 / UI 用户交互 / CIA 影响），Trivy 表格里的分数就来自它
• 严重性阈值：各发行版映射不同——同一漏洞在 Ubuntu 可能标 MEDIUM、在 Alpine 可能标 HIGH，因为"修复包是否存在"影响评级
• EPSS：基于真实攻击数据的"被利用概率"评分（0-1），比 CVSS 更贴近实战，建议结合使用（高危且 EPSS 高 → 立即修）

# 查看某个漏洞的详细信息（含 CVSS 向量与描述）
trivy image --format json nginx:1.25 | jq '.Results[].Vulnerabilities[] | select(.VulnerabilityID=="CVE-2024-XXXX")'

# 按 EPSS 概率排序筛选（需要 trivy 1.44+ 的 --epss 支持）
trivy image --format json --list-all-pkgs nginx:1.25 | \
  jq '[.Results[].Vulnerabilities[] | select(.CVSS != null)] | sort_by(.CVSS.nvd.V3Score) | reverse | .[:5]'

9. Trivy 扫描器工作原理

理解 Trivy 的内部流程，才能解释"为什么有时候扫不出问题"以及"为什么扫描这么快"：

1. 层解析：Trivy 按 OCI 镜像规范逐层解包，为每一层建立文件清单（不展开全部文件，只记录元数据与内容哈希）
2. SBOM 生成：通过包管理器数据库特征（dpkg 状态文件、RPM 数据库、APKINDEX、package-lock.json 等）识别已安装的软件包及精确版本
3. 版本匹配：把"包名 + 版本"与漏洞数据库做比对——命中则提取该漏洞的严重性与修复版本
4. 结果聚合：按包、按层去重合并（多层重复文件只报一次），输出 table/json/sarif 等格式

# 查看 Trivy 识别出的包清单（--list-all-pkgs 输出完整 SBOM 视角）
trivy image --list-all-pkgs --format json nginx:1.25 | \
  jq '.Results[0].Packages[] | {name: .Name, version: .Version, type: .Type}' | head -20

# 验证"层归属"：哪个层引入了漏洞包
trivy image --format json nginx:1.25 | \
  jq -r '.Results[].Layers[]?.CreatedBy' | head -5

# 关键点：Trivy 只匹配"已知 CVE"——0-day、不在库中的 CVE 扫不到
# 所以镜像扫描要与运行时监控（Falco）、配置审计（Docker Bench）组合

10. CI 门禁设计模式

门禁不是"一条命令加 --exit-code 1"那么简单，成熟团队通常按"严重性分级 + 基线豁免 + 趋势对比"设计：

# 门禁脚本（CI 中直接调用）
#!/bin/bash
set -euo pipefail

IMAGE="$1"
LEVEL="CRITICAL,HIGH"

# 生成 JSON 结果
trivy image --format json --severity "$LEVEL" --ignore-unfixed -o /tmp/trivy.json "$IMAGE"

# 漏洞数统计
CRITICAL=$(jq '[.Results[].Vulnerabilities[]? | select(.Severity=="CRITICAL")] | length' /tmp/trivy.json)
HIGH=$(jq '[.Results[].Vulnerabilities[]? | select(.Severity=="HIGH")] | length' /tmp/trivy.json)

echo "CRITICAL: $CRITICAL, HIGH: $HIGH"

# 白名单（带原因的豁免清单）
grep -Fxq "CVE-2024-XXXX" .trivyignore || true
# 未修复的 CRITICAL 一律阻断
if [ "$CRITICAL" -gt 0 ]; then
  echo "::error::存在未豁免的 CRITICAL 漏洞，阻断部署"
  exit 1
fi

# HIGH 允许在非生产分支放行
if [ "${ENV:-dev}" != "prod" ] && [ "$HIGH" -gt 0 ]; then
  echo "::warning::非生产分支存在 $HIGH 个 HIGH 漏洞（不阻断）"
  exit 0
fi

# 其余交给 trivy 自身 exit code
trivy image --exit-code 1 --severity "$LEVEL" --ignore-unfixed "$IMAGE"

11. 供应链安全与合规

漏洞扫描只是供应链安全的起点，完整的链条是"SBOM → 签名 → 准入 → 持续验证"：

# 1. 构建时生成 SBOM（软件物料清单）并随镜像归档
trivy image --format cyclonedx --output sbom.cdx.json myapp:1.0
# 或直接用 syft 生成 SPDX/CycloneDX
syft myapp:1.0 -o cyclonedx-json > sbom.cdx.json

# 2. 镜像签名（cosign，K8s 1.24+ 原生支持验签）
cosign sign --key cosign.key myrepo/myapp:1.0
# 验证签名
cosign verify --key cosign.pub myrepo/myapp:1.0

# 3. 准入控制（Kyverno 校验：必须有 SBOM 注解 + 有效签名才允许部署）
kubectl apply -f - <<EOF
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-image-signature
spec:
  validationFailureAction: Enforce
  rules:
  - name: check-signature
    match:
      any:
      - resources:
          kinds: [Pod]
    verifyImages:
    - image: "myrepo/*"
      key: |-
        -----BEGIN PUBLIC KEY-----
        ...
        -----END PUBLIC KEY-----
EOF

# 4. 定期对仓库内全部镜像做全量扫描（独立于 CI）
trivy image --severity HIGH,CRITICAL --ignore-unfixed \
  myrepo/myapp:1.0 myrepo/gateway:2.1 myrepo/worker:0.9

合规场景（等保、SOC 2、行业监管）通常要求：能回答"这个版本由谁在何时构建、包含哪些组件、漏洞状态如何"。建议把 SBOM 文件与镜像 tag 一起存进制品库，并保留扫描报告的历史版本，供审计追溯。

12. 镜像仓库与集群持续扫描

CI 门禁覆盖"新构建的镜像"，但仓库里存量镜像和集群中运行中的镜像同样需要治理：

镜像仓库级扫描

# 方案 A：Harbor 内置 Trivy（Harbor 2.x 默认集成）
# 在 Harbor 配置中开启漏洞扫描，设置"定时扫描 + 漏洞大于阈值阻止拉取"
# 界面路径：项目 → 配置 → 漏洞扫描（按 CRITICAL/HIGH 配置阻止策略）

# 方案 B：脚本全量扫描（配合 CI 调度）
#!/bin/bash
# 每周五扫描仓库内全部活跃 tag
for tag in $(docker images --format '{{.Repository}}:{{.Tag}}' | grep myrepo); do
  trivy image --severity HIGH,CRITICAL --ignore-unfixed \
    --format json --output "scan-$(echo $tag | tr '/:' '__').json" "$tag"
done

# 方案 C：集群内运行中镜像巡检（trivy k8s）
trivy k8s --report summary --severity HIGH,CRITICAL cluster
# 输出：按命名空间/工作负载汇总，直接定位"运行中的高危镜像"

扫描结果的归档与审计

• 扫描报告（JSON/SARIF）按镜像 tag 归档到制品库或对象存储，保留 90 天以上
• 建立"已知问题清单"：每个未修复漏洞记录发现日期、影响版本、处置负责人、到期日
• 安全基线可度量：以"CRITICAL 清零率"和"高危修复 SLA 达成率"作为团队指标

常见错误

最佳实践

• 每次构建镜像时自动扫描（CI 门禁），确保漏洞在部署前被发现
• CRITICAL/HIGH 漏洞阻止构建，MEDIUM/LOW 记录但不阻止
• 每周运行一次全量仓库扫描（trivy repo）
• 定期更新 Trivy 漏洞数据库（默认每 12 小时自动更新）
• 基础镜像选择官方或 distroless 镜像（漏洞更少）
• 使用 .trivyignore 文件记录已确认的误报，附上原因说明
• 优先使用 --ignore-unfixed 减少无修复版本漏洞的噪音
• 在生产环境使用 SBOM（软件物料清单）进行合规审计
• 结合多阶段构建减小镜像体积，同时减少潜在漏洞数量

练习题

1. 基础扫描练习：拉取 nginx:1.25 镜像，使用 Trivy 扫描所有漏洞，然后只筛选出 CRITICAL 级别的漏洞并以 JSON 格式输出到文件。分析输出结果中有多少个 CRITICAL 漏洞，分别影响哪些库。
2. CI 集成练习：为一个已有的 Docker 项目编写 GitHub Actions 配置，实现以下要求：构建镜像后自动扫描，HIGH/CRITICAL 漏洞阻断部署，扫描结果以 SARIF 格式上传到 GitHub Code Scanning。
3. 离线扫描练习：模拟离线环境，先在有网络的机器上导出 Trivy 漏洞数据库，然后使用离线数据库扫描一个本地镜像。记录完整操作步骤和遇到的问题。

学习检查点

学完本章后，请检验自己是否掌握以下内容：

本章总结

镜像漏洞扫描是容器安全"左移"的起点——在构建阶段发现问题，远比漏洞上线后再补救成本低。实践中要对漏洞按 CRITICAL/HIGH/MEDIUM/LOW 分级处置，并在 CI/CD 中设置门禁阈值，让高危漏洞直接阻断构建。同时要清醒认识到扫描器的覆盖有限：Trivy 只能命中已知漏洞数据库中的问题，需要与运行时监控、配置审计、镜像签名等其他安全层组合，才能构成完整的容器安全体系。

延伸阅读