3. 镜像扫描原理：Trivy漏洞数据库更新机制、层扫描与缓存策略、SBOM生成原理

Trivy 作为云原生生态中最流行的开源镜像扫描器，其核心扫描原理围绕三个关键环节展开：漏洞数据库的增量更新、镜像层的并行扫描与缓存、以及 SBOM 的实时生成。理解这三部分机制，是配置扫描队列水位和仓库配额管理的基础。

3.1 漏洞数据库更新机制

Trivy 采用 “客户端拉取 + 增量合并” 的数据库更新策略，避免每次扫描都下载全量数据。

更新流程的核心是 OCI 层差分：Trivy 将漏洞数据库打包为 OCI 镜像，每次发布新漏洞时只推送变更的层。扫描器通过对比本地已有层的 digest，仅拉取缺失的层，然后合并到本地的 SQLite 数据库中。

# 查看当前数据库版本与更新时间
trivy db info

# 手动触发增量更新（通常由扫描命令自动执行）
trivy image --download-db-only

# 强制重置数据库（用于解决数据损坏）
trivy image --reset

3.2 层扫描与缓存策略

Trivy 对容器镜像的扫描并非逐文件遍历，而是基于 镜像层（Layer） 进行并行分析。每一层对应 Dockerfile 中的一条指令（如 RUN apt-get install）。

层扫描的缓存策略分为三级：

1. 内存缓存： 扫描过程中，已解析的包管理器索引（如 APT、RPM、APK 的元数据）暂存在内存中，避免重复解压。
2. 文件系统缓存： 每个层的扫描结果（漏洞列表、包列表）以 JSON 格式存储在 ~/.cache/trivy/fanal/ 目录下，key 为层的 digest。
3. 数据库缓存： 漏洞匹配结果写入 SQLite 数据库，下次扫描相同层时直接查询，跳过重新匹配。

# 缓存目录结构示例
~/.cache/trivy/
├── db/
│   └── trivy.db          # 漏洞数据库
├── fanal/
│   ├── sha256:abc123...  # 层扫描结果缓存
│   └── sha256:def456...
└── java-db/
    └── trivy-java.db     # Java 依赖数据库（可选）

3.3 SBOM 生成原理

Trivy 在扫描过程中会同步生成 SPDX 或 CycloneDX 格式的 SBOM。SBOM 的生成并非独立步骤，而是层扫描的副产品。

生成流程分为三个阶段：

• 包提取： 从每个镜像层中解析包管理器数据库（如 /var/lib/dpkg/status、/lib/apk/db/installed），提取包名、版本、许可证信息。
• 依赖关系构建： 对于 Java（pom.xml）、Node.js（package-lock.json）、Python（requirements.txt）等语言，Trivy 会解析锁定文件，构建完整的传递依赖树。
• 格式序列化： 将提取的包列表和依赖关系序列化为 SPDX 2.3 或 CycloneDX 1.5 JSON 格式，并嵌入扫描结果中。

# 生成 CycloneDX 格式的 SBOM
trivy image --format cyclonedx --output result.cdx.json alpine:3.18

# 生成 SPDX 格式的 SBOM
trivy image --format spdx-json --output result.spdx.json alpine:3.18

# 仅生成 SBOM，不进行漏洞匹配
trivy image --format spdx-json --ignore-unfixed alpine:3.18

3.4 三者的协同关系

在扫描队列和仓库配额管理的上下文中，这三个机制共同决定了扫描的 吞吐量 和 存储消耗：