Trivy 术语体系全解：Target、Scanner、DB、VEX、Plugin 与 Module 核心概念指南

Trivy 术语体系全解：Target、Scanner、DB、VEX、Plugin 与 Module 核心概念指南

【免费下载链接】trivyFind vulnerabilities, misconfigurations, secrets, SBOM in containers, Kubernetes, code repositories, clouds and more项目地址: https://gitcode.com/GitHub_Trending/tr/trivy

导读

Trivy 是一套涵盖容器镜像、Kubernetes、代码仓库、云配置与 SBOM 等多种扫描目标的安全扫描工具，其生态中存在一批含义独特、容易混淆的术语（例如 Target 与 Scanner、Plugin 与 Module、Trivy DB 与 Scan Cache 的区分）。本文以官方术语表 docs/guide/references/terminology.md 为核心骨架，逐条解释这些术语的精确定义、收录边界与底层实现依据，并结合本仓库源码说明它们在实际扫描流程中的角色。读完本文，你将能够准确区分 Trivy 生态中的核心组件，理解漏洞数据库、扫描缓存、插件与模块之间的本质差异，并知道每个概念应该查阅哪份官方文档做深入实践。

术语表的定位：收录什么、排除什么

Trivy 术语表不是一份通用的安全术语字典，而是只收录「Trivy 生态专属」概念的词典。其收录与排除标准（见 terminology.md）清晰划定了边界：

收录范围

1. Trivy 核心组件：主要功能（Scanner、Target）与必需组件（扫描资产如 trivy-db、trivy-java-db），以及用户直接交互的组件；
2. Trivy 特有术语：仅在 Trivy 语境下有特殊含义的词汇（如 Plugin、Module），以及 Trivy 生态专属概念（如 VEX Hub）。

排除范围

1. 通用术语：CVE、CVSS、Container、Registry 等常见安全/技术词汇，以及标准行业术语；
2. 实现细节：组件的内部工作原理与使用说明（这些属于功能文档的范畴）。

理解这个边界有助于读者在阅读 Trivy 文档时快速定位「哪些概念需要专门学习、哪些可以依赖既有知识」。下面按官方文档的章节顺序展开每个术语。

Core Concepts：Target、Scanner 与 Scan Assets

Target——可被扫描的对象

Target 指 Trivy 能够扫描的制品类型，如容器镜像和文件系统。从 pkg/commands/artifact/scanner.go 的源码结构看，Target 具体包括以下类型，每种类型对应独立的 artifact 初始化工厂函数：

从源码还可以观察到 Target 与运行模式的关系：每个 Target 都有Standalone（本地扫描）与Client/Server（客户端-服务器）两种服务创建路径。前者在本地完成「Cache → Applier → OS Scanner → Lang Scanner → Vuln Client」的手工依赖注入链路，后者则通过cache.NewRemoteCache与 RPC 客户端将扫描请求转发给 Trivy Server（pkg/commands/artifact/scanner.go）。

Scanner——内置扫描引擎

Scanner 指 Trivy 内置的安全扫描引擎，共四个：

• Vulnerability Scanner（漏洞扫描）
• Misconfiguration Scanner（配置错误扫描）
• Secret Scanner（秘密扫描）
• License Scanner（许可证扫描）

官方文档特别用「!!! note」强调：SBOM 不是 Scanner，而是输出格式选项。这是一个常见误区——SBOM 是扫描结果的呈现载体（CycloneDX、SPDX 等格式），并非独立的安全检测引擎，这一点在 pkg/report 中也有印证：SBOM 相关实现位于pkg/sbom与报告输出层（cyclonedx、spdx 等），而非检测层。

Scan Assets——扫描时依赖的外部数据

Scan Assets 指 Trivy 在扫描过程中（按需）下载并使用的外部数据，共四类：

• Vulnerability Database（Trivy DB）——漏洞信息数据库
• Java Index Database（Trivy Java DB）——Java 制品识别数据库
• Checks Bundle（trivy-checks）——配置错误检测规则包
• VEX Repository——VEX 文档仓库

Vulnerability Scanning：漏洞扫描数据资产

Vulnerability Database（Trivy DB，trivy-db）

定义：漏洞检测所必需的核心漏洞数据库，包含多个生态系统的综合漏洞信息，通过 OCI Registry 分发。

从本仓库实现看，Trivy DB 的获取逻辑位于 pkg/db/db.go：

• 默认仓库为ghcr.io/aquasecurity/trivy-db:<schema>，同时提供 GCR 镜像mirror.gcr.io/aquasec/trivy-db:<schema>（pkg/db/db.go），schema 版本号直接参与镜像 Tag，保证客户端与数据库的版本耦合；
• 数据库以 OCI 制品形式分发，其 media type 为application/vnd.aquasec.trivy.db.layer.v1.tar+gzip（pkg/db/db.go）；
• 底层存储采用 BoltDB，并以只读模式打开（db.Init中强制附加bolt.Options{ReadOnly: true}）；
• 更新判定逻辑（NeedsUpdate）处理了三种典型场景：本地无trivy.db/metadata.json（首次运行必须下载，此时--skip-db-update会直接报错）、数据库损坏或元数据缺失、本地 schema 版本与支持版本不匹配（pkg/db/db.go）。若元数据的NextUpdate未到或下载时间在一小时以内，则跳过更新。

数据来源：Trivy DB 由一个收集并汇总多种数据源漏洞信息的 GitHub 仓库构建而成，是构建 Trivy DB 的基础，涉及多个上游数据仓库（如 NVD、Red Hat、Debian 等漏洞列表仓库）。

Java Index Database（Trivy Java DB，trivy-java-db）

定义：用于在扫描 JAR/WAR/PAR/EAR 时识别 Java 库及其组件（groupId/artifactId/version）的专用数据库，同样通过 OCI Registry 分发。

其实现位于 pkg/javadb/client.go，有几个值得注意的实现事实：

• 与 Trivy DB 一样采用「GHCR 主仓库 + GCR 镜像」的双仓库策略，media type 为application/vnd.aquasec.trivy.javadb.layer.v1.tar+gzip；
• 每 3 天缓存一次：更新逻辑会检查NextUpdate与下载时间，更新完成后日志明确提示「Java DB is cached for 3 days」，如需更频繁更新可执行trivy clean --java-db清除缓存（pkg/javadb/client.go）；
• 查询接口暴露了三种典型的 Java 识别路径：SearchBySHA1（通过 JAR 的 SHA1 摘要反查坐标）、SearchByArtifactID（按 artifactId 与版本推断 groupId，内部处理了「同一 artifactId 对应多个 groupId」的歧义，例如javax.servlet:jstl与jstl:jstl，采用出现次数最多的 groupId 作为结果）、Exists（判断坐标是否存在）（pkg/javadb/client.go）。这解释了为什么扫描 Java 制品时需要额外下载该数据库——仅凭文件内容无法可靠确定 Maven 坐标。

Misconfiguration Scanning：配置错误扫描术语

官方文档特别说明：当上下文不足以表明这些术语与配置错误扫描相关时，会加上「Misconfiguration」前缀以示清晰，例如「Check」可写作「Misconfiguration Check」，「Checks Bundle」可写作「Misconfiguration Checks Bundle」。这一约定能有效避免与其他扫描器的同名概念混淆。

Check

Check 指定义在 Rego 文件中的规则，用于检测各类 IaC（基础设施即代码）文件中的配置错误。在仓库中，配置扫描的 Rego 规则分布在 pkg/iac/rules、pkg/iac/scanners 与 pkg/iac/rego 等目录，扫描流程由 pkg/iac/scan 驱动，最终通过 pkg/iac/framework 统一组织。

Built-in Checks

内置检查项是随trivy-checks 仓库分发的默认规则集，提供标准的安全与配置最佳实践。它是绝大多数用户开箱即用时的规则来源，无需任何额外配置即可在配置扫描中生效。

Checks Bundle

Checks Bundle 是包含上述内置检查项的 tar.gz 归档，同样通过 OCI Registry 分发。它与 Trivy DB、Java DB 一样属于「扫描资产」——Trivy 启动配置扫描时按需从 OCI Registry 拉取该包。关于 Bundle 的详细使用方式（如--checks-bundle-repository自定义仓库）可参考配置扫描文档 docs/guide/scanner/misconfiguration/index.md。

Secret Scanning：Rule 的结构与执行

Rule

Rule 指用于检测硬编码秘密与敏感信息的模式匹配规则。每条规则由三部分构成：

• 元数据：ID、Category（分类）、Title（标题）等；
• 匹配敏感模式的正则表达式；
• 提升检测准确率的附加上下文。

从 pkg/fanal/secret/scanner.go 的Rule结构体定义可以看到比术语表更完整的字段：ID、Category、Title、Severity、Regex、Keywords、Path、AllowRules、ExcludeBlock、SecretGroupName。其中几个字段直接服务于「准确率」目标：

• Keywords（关键词）：在运行正则之前先对内容做一次小写化匹配（MatchKeywords），不命中关键词的文件直接跳过，大幅降低正则开销；
• Path（路径正则）：MatchPath决定该规则作用于哪些文件路径；
• AllowRules / ExcludeBlock：分别通过「允许规则」与「排除块」过滤误报；SecretGroupName则支持从正则具名分组中提取精确的秘密片段（如 AWS Access Key 规则使用(?P<secret>...)命名组）。

内置规则定义在 pkg/fanal/secret/builtin-rules.go，覆盖 AWS、GitHub、GitLab、Google、Slack、Stripe、JWT、OpenAI、Docker、Azure 等数十个分类（pkg/fanal/secret/builtin-rules.go）。扫描引擎还实现了流式扫描：默认以 64KB 为缓冲块、4KB 为块间重叠区逐块处理文件，保证内存占用与文件大小无关，同时通过重叠区确保跨块边界的秘密不被遗漏（pkg/fanal/secret/scanner.go）。

Kubernetes Integration：KBOM

KBOM（Kubernetes Bill of Materials）

KBOM 是专用于 Kubernetes 集群的特殊 SBOM 格式，包含集群组件的详细信息。它解决了「SBOM 描述软件制品清单、而集群是一个动态组合体」的问题——KBOM 把集群视为一个可描述、可扫描的整体制品。本仓库中 pkg/k8s/scanner/scanner.go 即承担 Kubernetes 集群扫描能力，其输出的 KBOM 结果可进一步用于漏洞与配置分析，相关报告与写入逻辑位于 pkg/k8s/report 与 pkg/k8s/writer.go。

VEX：漏洞可利用性交换

VEX Repository

VEX Repository 是遵循 VEX Repository Specification 存储 VEX 文档的仓库系统，帮助用户管理与共享「漏洞适用性与可利用性」信息。从 pkg/vex 的目录结构看，仓库同时支持多种 VEX 载体：CSAF（csaf.go）、CycloneDX（cyclonedx.go）、OpenVEX（openvex.go），并提供了基于 SBOM 引用（sbomref.go）与文档模型（document.go）的抽象层；pkg/vex/repo.go 实现了仓库的解析逻辑，OCI 形态的 VEX 仓库支持位于 pkg/vex/oci。详细实践请参考 VEX 仓库文档。

VEX Hub

VEX Hub 是 Aqua Security 托管的默认 VEX 仓库，主要聚合软件包维护者在其源码仓库中发布的 VEX 文档，充当 OSS 项目漏洞适用性信息的集中收集与分发中心。对绝大多数用户而言，无需自建 VEX 仓库——直接使用默认的 VEX Hub 即可获得主流 OSS 项目的官方漏洞适用性声明。

Cache System：资产缓存与扫描缓存

Cache Types

Trivy 的缓存目录（默认~/.cache/trivy下）包含若干种类型截然不同的数据，术语表给出了完整清单：

• Vulnerability Database（trivy-db）
• Java Index Database（trivy-java-db）
• Misconfiguration Checks
• VEX Repositories
• Scan Cache

Asset Cache

Asset Cache指已下载的资产，如漏洞数据库与 Java 索引数据库。从实现看，Trivy DB 存放在缓存目录下的db子目录（pkg/db/db.go），Java DB 存放在java-db子目录（pkg/javadb/client.go）。这类缓存的特征是可被trivy clean清理——Client.Clear直接删除整个 db 目录（pkg/db/db.go），Java DB 同理。

Scan Cache

Scan Cache是存储上一次扫描分析结果的缓存机制，用于加速后续扫描。对容器镜像扫描而言，Scan Cache 按层（layer）存储分析结果，包括每层的包名与版本。其底层实现见 pkg/cache/cache.go：缓存使用两个 Bolt 桶组织数据——artifact桶按 artifact ID（如镜像 ID）存放制品信息，blob桶按 blob ID（如层 ID）存放 OS、包与库信息（pkg/cache/cache.go）。MissingBlobs接口用于对比「目标制品需要的 blob ID」与「缓存已有的 blob ID」，只对缺失的层做重新分析，这正是增量扫描能够大幅提速的原因。缓存的详细配置（--cache-dir、--cache-backend、Redis 后端等）参见 缓存文档。

Plugin System：插件与插件索引

Plugin

Plugin 是与 Trivy 集成、扩展其核心功能的附加工具，具备三个关键特性：

• 可用任何编程语言编写，并与 Trivy CLI 无缝集成——出现在trivy help与子命令列表中；
• 可独立安装与移除，不影响核心 Trivy 安装。

从 pkg/plugin/plugin.go 的Plugin结构看，插件的元数据（plugin.yaml）包含name、repository、version、summary、description与platforms等字段（pkg/plugin/plugin.go）。其中Platforms支持按 OS/Arch 声明多平台可执行文件，运行时通过selectPlatform依据runtime.GOOS/GOARCH选择匹配平台，未声明 Selector 的平台作为默认兜底（pkg/plugin/plugin.go）；插件可执行文件安装到 Trivy 主目录下的插件目录，通过exec.Command以子进程方式运行，并透传 stdin/stdout/stderr（pkg/plugin/plugin.go）。插件的安装、管理命令（trivy plugin install/run/uninstall）详见 插件用户指南，开发插件的方法见 插件开发者指南。

Plugin Index（trivy-plugin-index）

Plugin Index 是集中列出可用 Trivy 插件的注册表，维护经人工筛选的官方与社区插件清单，提供插件名称、描述、维护者等元数据。它的价值在于：

• 通过trivy plugin search命令实现插件发现；
• 支持插件自动化安装与更新。

详细使用方式见 插件索引文档。

Module System：基于 WebAssembly 的扩展机制

Module

Module 是基于 WebAssembly 的扩展机制，允许在不修改 Trivy 二进制的情况下加入自定义扫描逻辑。Module 既可以分析文件（作为自定义 Analyzer），也可以后处理扫描结果（作为 Post Scanner），实现方式包括向结果中插入（INSERT）、更新（UPDATE）或删除（DELETE）漏洞/配置错误条目。

Module 文档 提供了完整开发指南。这里补充仓库实现层面的关键事实（pkg/module/module.go）：

• 运行时：采用wazero作为 WebAssembly 运行时，并支持 WASI（wasi_snapshot_preview1），Module 文件以.wasm为扩展名加载；
• API 版本校验：加载时校验 Module 声明的api_version，与 Trivy 内置 API 版本不一致的模块会被跳过并打印日志（pkg/module/module.go），避免二进制升级后旧模块不兼容；
• 启用开关：可通过--enable-modules指定启用名单，未在名单中的 WASM 模块不会被加载；
• 内存协议：Trivy 与 WASM 之间通过线性内存交换 JSON 数据（marshal/unmarshal辅助函数），Module 必须导出name()、version()、api_version()、analyze()、post_scan()等函数（pkg/module/module.go）；
• 双角色：Module 通过is_analyzer与is_post_scanner声明自己的角色，Analyzer 用required()返回需要分析的文件路径正则，Post Scanner 用post_scan_spec()声明对结果的 INSERT/UPDATE/DELETE 动作（pkg/module/module.go）。

官方提供了一个完整的示例 Module：examples/module/spring4shell/spring4shell.go，可作为学习 Module 编写的起步模板。与 Plugin 的本质区别在于：Plugin 是独立的可执行子进程（任意语言），Module 是在 Trivy 进程内运行的 WASM 代码（需遵循 Trivy Wasm SDK 约定）。

快速对照速查表

小结

掌握 Trivy 的术语体系是高效使用与二次开发的前提：Target决定了扫描入口，Scanner决定了检测维度，trivy-db/trivy-java-db/trivy-checks/VEX 仓库构成了支撑扫描的「扫描资产」，Asset Cache与Scan Cache共同优化了重复扫描的成本，而Plugin与Module则从「进程外」与「进程内」两个方向提供了扩展能力。当你下次遇到某个 Trivy 概念时，不妨先回到这份术语表确认它的分类归属，再借助文中给出的对应功能文档与源码路径深入实践。

【免费下载链接】trivyFind vulnerabilities, misconfigurations, secrets, SBOM in containers, Kubernetes, code repositories, clouds and more项目地址: https://gitcode.com/GitHub_Trending/tr/trivy