Trivy 安全扫描器

对容器镜像、文件系统、Git 仓库及基础设施即代码（IaC）执行 Trivy 扫描，再通过智能分类（triage）过滤漏洞噪声。本能力不向团队直接抛出 500 个 CVE，而是依据可利用性（EPSS）、可达性分析、修复可用性及业务上下文，对发现项进行优先级排序，最终生成可落地的修复计划。

适用场景包括：“扫描该镜像是否存在漏洞”、“执行一次安全扫描”、“对 CVE 进行分类处理”、“检查我们依赖项中的漏洞”、“容器安全审计”，或在准备合规性审查时使用。

前提条件

# 确保已安装 Trivy
trivy version  # 版本需 ≥ 0.50

# 若尚未安装：
# Debian/Ubuntu 系统
sudo apt-get install -y wget apt-transport-https gnupg lsb-release
wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key | gpg --dearmor | sudo tee /usr/share/keyrings/trivy.gpg > /dev/null
echo "deb [signed-by=/usr/share/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 trivy

# macOS 系统
brew install trivy

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

使用方法

提供一个或多个扫描目标：

• 容器镜像 — 如 nginx:1.25、ghcr.io/org/app:latest 或本地镜像
• 文件系统路径 — 扫描项目依赖项与源代码
• Git 仓库 URL — 扫描远程仓库
• Kubernetes 集群 — 扫描正在运行的工作负载
• SBOM 文件 — 扫描已有的 CycloneDX 或 SPDX 格式 SBOM

可选参数：

• 严重性阈值 — 报告的最低严重等级（CRITICAL、HIGH、MEDIUM、LOW）
• 合规框架 — 将发现项映射至特定标准（SOC2、PCI-DSS、HIPAA、CIS）
• 忽略文件 — 指定 .trivyignore 路径以声明已接受的风险
• 仅显示可修复项 — 仅报告存在可用修复方案的漏洞

调用示例：

扫描我们的生产镜像 registry.example.com/api:v2.3.1，并提供一份优先级排序后的修复计划。

对该项目的文件系统执行扫描，并指出哪些漏洞在实际运行中真正可达。

扫描我们 Kubernetes 集群中的所有容器镜像，并生成一份面向 SOC2 的合规报告。

工作原理

步骤 1：执行扫描

运行对应类型的 Trivy 扫描，并以 JSON 格式输出，便于结构化分析：

容器镜像扫描：

trivy image --format json --output /tmp/trivy-image.json 
  --severity CRITICAL,HIGH,MEDIUM 
  --vuln-type os,library 
  --scanners vuln,secret,misconfig 
  --list-all-pkgs 
  registry.example.com/api:v2.3.1

文件系统扫描（项目依赖项）：

trivy fs --format json --output /tmp/trivy-fs.json 
  --severity CRITICAL,HIGH,MEDIUM 
  --scanners vuln,secret,misconfig,license 
  --list-all-pkgs 
  /path/to/project

IaC 扫描（Terraform、CloudFormation、Kubernetes 清单、Dockerfile）：

trivy config --format json --output /tmp/trivy-iac.json 
  --severity CRITICAL,HIGH,MEDIUM 
  /path/to/terraform

Kubernetes 集群扫描： trivy k8s --format json --report all --severity CRITICAL,HIGH cluster

SBOM 生成与扫描： 使用 trivy image --format cyclonedx 生成 SBOM，再用 trivy sbom --format json 执行扫描。

步骤 2：原始结果解析

解析 Trivy 的 JSON 输出，提取结构化的漏洞数据：

# 提取漏洞摘要
cat /tmp/trivy-image.json | jq '{
  target: .Results[].Target,
  total_vulns: [.Results[].Vulnerabilities // [] | length] | add,
  by_severity: [.Results[].Vulnerabilities // [] | .[]] | group_by(.Severity) |
    map({severity: .[0].Severity, count: length}),
  fixable: [.Results[].Vulnerabilities // [] | .[] | select(.FixedVersion)] | length,
  unfixable: [.Results[].Vulnerabilities // [] | .[] | select(.FixedVersion == null)] | length
}'

步骤 3：可利用性增强分析

为每个 CVE 补充可利用性数据，从而区分真实威胁与理论风险：

EPSS（Exploit Prediction Scoring System）：

# 获取已发现 CVE 的 EPSS 分数
CVES=$(cat /tmp/trivy-image.json | jq -r '[.Results[].Vulnerabilities[]?.VulnerabilityID] | unique | join(",")')
curl -s "https://api.first.org/data/v1/epss?cve=$CVES" | jq '[.data[] | {
  cve: .cve,
  epss: .epss,
  percentile: .percentile
}] | sort_by(-.epss)'

KEV（CISA Known Exploited Vulnerabilities）：

# 对照 CISA KEV 目录校验
curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json | 
  jq --argjson cves "$(cat /tmp/trivy-image.json | jq '[.Results[].Vulnerabilities[]?.VulnerabilityID] | unique')" 
  '[.vulnerabilities[] | select(.cveID as $id | $cves | index($id))]'

分类策略（Triage classification）：

步骤 4：可达性分析

判断存在漏洞的代码是否在应用中实际可达：

# 检查漏洞包是直接依赖还是传递依赖
# Node.js 项目：
npm ls  2>/dev/null
# 检查是否为 devDependency（不会进入生产环境）
jq '.devDependencies[""]' package.json

# Python 项目：
pip show  | grep -i "required-by"
# 检查是否仅出现在 requirements-dev.txt 中
grep -l "" requirements*.txt

# Go 项目：
go mod why 
go mod graph | grep 

# Java 项目：
mvn dependency:tree -Dincludes=:

代理评估的可达性因素：

1. 直接依赖 vs 传递依赖 — 传递依赖通常不可达
2. 运行时依赖 vs 构建/测试依赖 — 开发依赖不会进入生产环境
3. 是否调用漏洞函数 — 具体的漏洞函数是否被实际导入并使用
4. 网络暴露面 — 漏洞组件是否接收来自不可信来源的输入
5. OS 包 vs 应用包 — 在 distroless 镜像中的 OS 包通常未被使用

步骤 5：修复计划制定

针对每个可操作的发现项，生成具体修复建议：

依赖升级：

# 显示所需的确切版本升级
cat /tmp/trivy-image.json | jq '[.Results[].Vulnerabilities // [] | .[] |
  select(.FixedVersion) | {
    package: .PkgName,
    installed: .InstalledVersion,
    fixed: .FixedVersion,
    cve: .VulnerabilityID,
    severity: .Severity
  }] | unique_by(.package) | sort_by(.Severity)'

基础镜像升级：

# 检查更新的基础镜像是否能修复 OS 层 CVE
trivy image --format json --severity CRITICAL,HIGH alpine:3.20 | 
  jq '[.Results[].Vulnerabilities // []] | add | length'

Dockerfile 加固（基于 IaC 扫描结果）：

# 改造前（不安全）：
FROM ubuntu:latest
RUN apt-get update && apt-get install -y curl
COPY . /app
CMD ["./app"]

# 改造后（加固）：
FROM ubuntu:24.04 AS builder
RUN apt-get update && apt-get install -y --no-install-recommends curl 
    && rm -rf /var/lib/apt/lists/*
COPY . /app
RUN ./build.sh

FROM gcr.io/distroless/base-debian12:nonroot
COPY --from=builder /app/binary /app/binary
USER 65532:65532
ENTRYPOINT ["/app/binary"]

步骤 6：合规性映射

将发现项映射至合规框架控制点：

SOC2 映射：

• CC6.1（逻辑访问控制）—— 容器以 root 用户运行、缺少 RBAC
• CC6.8（漏洞管理）—— 存在未修复的关键 CVE
• CC7.1（系统监控）—— CI/CD 中未集成安全扫描
• CC8.1（变更管理）—— 镜像使用 :latest 标签

PCI-DSS 映射：

• Req 6.3 — 软件组件中存在已知漏洞
• Req 6.5 — 安全编码实践（IaC 配置错误）
• Req 11.2 — 漏洞扫描要求

步骤 7：.trivyignore 管理

为已接受的风险生成或更新 .trivyignore 文件：

# 格式：CVE-ID + 过期时间 + 合理说明
# .trivyignore.yaml（推荐格式）
vulnerabilities:
  - id: CVE-2024-1234
    paths:
      - "usr/lib/libfoo.so"
    expired_at: "2026-06-30"
    statement: "不可达 — 库已加载但漏洞函数未被调用。经 @security-team 于 2026-04-30 审核确认。"

  - id: CVE-2024-5678
    paths:
      - "node_modules/dev-only-package"
    expired_at: "2026-07-31"
    statement: "仅为开发依赖 — 不会包含在生产镜像中。上游暂无修复方案。"

步骤 8：CI/CD 集成建议

根据项目所用 CI 系统，推荐管道集成方式：

GitHub Actions：

- name: Trivy 漏洞扫描
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: ${{ env.IMAGE }}
    format: 'sarif'
    output: 'trivy-results.sarif'
    severity: 'CRITICAL,HIGH'
    exit-code: '1'  # 发现问题时使构建失败
    ignore-unfixed: true
    trivyignores: '.trivyignore.yaml'

- name: 上传 Trivy SARIF
  uses: github/codeql-action/upload-sarif@v3
  with:
    sarif_file: 'trivy-results.sarif'

输出内容

该代理将生成以下成果：

1. 执行摘要 — 总发现数、可修复与不可修复项数量、预估修复工作量
2. 优先级排序的发现表格 — 按可利用性（EPSS + KEV + 可达性）而非仅 CVSS 排序
3. 修复计划 — 具体的版本升级、基础镜像变更及 Dockerfile 修改建议，并附带工作量估算
4. 已接受风险 — .trivyignore.yaml 条目，含无需修复的发现项的合理说明
5. 合规性映射 — 将发现项关联至相关框架的具体控制点
6. 趋势对比 — 若存在历史扫描结果，则展示新增项与已解决项的对比
7. CI/CD 集成配置 — 即开即用的持续扫描流水线配置

为何采用 EPSS 而非仅依赖 CVSS

CVSS 衡量的是理论严重性，而 EPSS 衡量的是实际被利用的概率。一个 CVSS 9.8 但 EPSS 仅为 0.001 的漏洞，其紧急程度远低于一个 CVSS 7.5 但 EPSS 达 0.85（已在野外被主动利用）的漏洞。本能力综合使用以下指标：

• CVSS — 用于理解漏洞被利用后的潜在影响
• EPSS — 用于评估漏洞被实际利用的可能性
• KEV — 用于确认该漏洞是否已在现实中被利用
• 可达性 — 用于确认该漏洞在您的具体部署环境中是否真正可触发