Trivy 操作系统（OS）与容器镜像支持覆盖全指南：支持矩阵、包管理器与源码实现

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

导读

本文以 Trivy 官方文档中“OS 覆盖范围（Coverage/OS）”章节（docs/guide/coverage/os/index.md）为主线，系统梳理 Trivy 对操作系统发行版与容器镜像的扫描能力矩阵：哪些 OS 支持 SBOM 生成、漏洞扫描与许可证扫描，各自覆盖哪些版本、使用何种包管理器，以及诸如 CentOS Stream、RHEL 10 这类“只支持部分能力”的特殊情形。同时结合仓库中 pkg/detector/ospkg、pkg/fanal/types 等源码，讲清楚“OS 类型是如何被识别、路由到对应漏洞检测器”的底层机制。读完本文，你既可以对照矩阵快速判断自己的镜像/系统是否在支持范围内，也能理解 Trivy 内部 OS 检测器的注册与调度原理。

覆盖文档怎么看：每类 OS 支持的三项扫描能力

Trivy 对“系统包（OS packages）”层面提供三类能力，正文表格中的每一项都对应这三者之一：

• SBOM：从系统包清单生成软件物料清单（见 docs/guide/supply-chain/sbom.md）；
• Vulnerabilities（漏洞）：将已安装包与各发行版官方安全公告比对，检测 CVE 等漏洞（见 docs/guide/scanner/vulnerability.md）；
• Licenses（许可证）：读取包元数据识别开源许可证信息（见 docs/guide/scanner/license.md）。

索引页本身只给出“该 OS 是否被支持”的总览，而每个发行版在 docs/guide/coverage/os/ 下都有一份独立详情页（如 alpine.md、debian.md、rhel.md），逐项给出功能支持表（检测未修复漏洞、依赖关系图、EOL 感知）、数据来源、修复版本与上游差异、严重级别计算规则、漏洞状态（Status）支持情况与 License 识别来源等。索引页末尾明确说明“Each page gives more details”，即详情页是索引表的展开。

支持的操作系统一览（核心支持矩阵）

下表为当前仓库文档声明支持的操作系统、对应支持版本与其包管理器（docs/guide/coverage/os/index.md）：

OS	支持版本	包管理器
Alpine Linux	2.2 - 2.7, 3.0 - 3.22, edge	apk
Wolfi Linux	（不适用）	apk
Chainguard	（不适用）	apk
MinimOS	（不适用）	apk
Red Hat Enterprise Linux	6, 7, 8, 9	dnf/yum/rpm
Red Hat Enterprise Linux	10（仅 SBOM）	dnf/yum/rpm
CentOS[^1]	6, 7, 8	dnf/yum/rpm
AlmaLinux	8, 9, 10	dnf/yum/rpm
Rocky Linux	8, 9	dnf/yum/rpm
Oracle Linux	5, 6, 7, 8	dnf/yum/rpm
Azure Linux (CBL-Mariner)	1.0, 2.0, 3.0	tdnf/dnf/yum/rpm
Amazon Linux	1, 2, 2023	dnf/yum/rpm
openSUSE Leap	42, 15	zypper/rpm
openSUSE Tumbleweed	（不适用）	zypper/rpm
SUSE Linux Enterprise	11, 12, 15	zypper/rpm
SUSE Linux Enterprise Micro	5, 6	zypper/rpm
Photon OS	1.0, 2.0, 3.0, 4.0, 5.0	tndf/yum/rpm
CoreOS[^3]	所有版本（仅 SBOM）	rpm
Echo	（不适用）	apt/dpkg
Debian GNU/Linux	7, 8, 9, 10, 11, 12	apt/dpkg
Ubuntu	Canonical 支持的所有版本	apt/dpkg
Bottlerocket	1.7.0 及以上	bottlerocket
安装了 Conda 的 OS	-	conda

脚注说明：

• [^1] CentOS Stream 不受支持：CentOS 的滚动发行变体 CentOS Stream 被明确排除在支持范围外，只有传统的 CentOS 6/7/8 走 dnf/yum/rpm 路线；
• [^3] CoreOS 的范围：指 Fedora CoreOS 与已停止维护的 CoreOS Container Linux，且仅支持 SBOM 生成，不支持漏洞检测；
• RHEL 10 仅 SBOM：注意表格中 RHEL 10 单独一行，与 RHEL 6-9 的完整支持不同，为“SBOM only”。

上表“（不适用）”——如 Wolfi、Chainguard、MinimOS、openSUSE Tumbleweed 等——表示这些系统为滚动/无固定大版本号形态，或版本概念不适用（详见各详情页）。

按包管理体系归类理解

• apk 系（Alpine 及其衍生）：Alpine Linux（2.2 - 2.7、3.0 - 3.22、edge 通道），以及同基于 apk 的 Wolfi Linux、Chainguard、MinimOS；
• rpm 系（dnf/yum/rpm、tdnf、zypper/rpm）：覆盖 RHEL、CentOS、AlmaLinux、Rocky、Oracle、Azure Linux、Amazon Linux、openSUSE、SLES/SLE Micro、Photon、CoreOS 等，是目前支持面最广的一族；
• apt/dpkg 系：Debian 7-12、Ubuntu（跟随 Canonical 支持期）、Echo；
• 独立体系：Bottlerocket（面向容器宿主的专用 OS，要求 1.7.0+）以及带 Conda 运行时的系统（对应 docs/guide/coverage/others/conda.md，通过 conda 管理包）。

支持的容器镜像

除“原生 OS”外，文档还单列了两类常见“容器化镜像形态”：

容器镜像	支持版本	包管理器
Google Distroless[^2]	任意	apt/dpkg
Bitnami	任意	-

• [^2] Google Distroless：即由 Google 主导的 GoogleContainerTools/distroless 系列精简镜像。它没有传统包管理器，但保留了 apt/dpkg 层的数据库信息，因此 Trivy 通过 apt/dpkg 识别其中的系统组件；
• Bitnami：由 Bitnami 产线维护的镜像，包管理器列为 -（不适用），Trivy 借助其自有的安装目录/清单结构解析软件（详见 docs/guide/coverage/others/bitnami.md）。

此外，仓库在 docs/guide/coverage/others/ 下还记录了 RPM、ActiveState、RapidFort、RootIO、Seal 等补充形态，其中 RapidFort / RootIO / Seal 属于“第三方重建并再分发包”的供应商（见下文源码解析）。

源码透视：OS 类型如何被识别并路由到检测器

索引表描述的是“面向用户的承诺”，在源码里这些承诺落实为一套**OS 类型（OSType）→ 漏洞检测器（Driver）**的注册表。

OS 家族常量定义

OS 家族的字符串常量集中在 pkg/fanal/types/const.go，例如 Alpine、Debian、Ubuntu、RedHat、CentOS、CentOSStream（与 CentOS 分开定义）、Alma、Rocky、Oracle、Amazon、Azure（azurelinux）、CBLMariner（cbl-mariner）、Wolfi、Chainguard、MinimOS、Echo、Bottlerocket、CoreOS、Photon、OpenSUSELeap、OpenSUSETumbleweed、SLES、SLEMicro 等。同一文件中的 OSTypeAliases（如 "debian gnu/linux" -> Debian、"amazon linux" -> Amazon）用于把云环境（EKS、Kind 等）上报的松散名称归一化到标准家族。

值得注意：常量表中还有 Fedora、CentOSStream、ActiveState 等类型，但它们在检测器注册表（见下）中没有对应的驱动条目，这也印证了索引页“CentOS Stream 不受支持”的声明——不是每个枚举常量都意味着“漏洞可检测”。

漏洞检测器的注册与调度

OS 包漏洞检测的核心在 pkg/detector/ospkg/detect.go：Detector 持有一个 driver.Driver，而 drivers 是一个 map[ftypes.OSType]driver.Driver，把文档表格中的每个受支持 OS 家族映射到专门的扫描器：

• Alpine → alpine.NewScanner()；
• Debian → debian.NewScanner()，Ubuntu → ubuntu.NewScanner()；
• RedHat 与 CentOS 共用 redhat.NewScanner()（两个家族的公告格式同源，源码注释也说明二者复用）；
• Alma / Rocky / Oracle / Photon / Wolfi / Chainguard / Echo / MinimOS / CoreOS / Bottlerocket / Amazon 各有独立 scanner；
• SUSE 家族通过 suse.NewScanner(...) 按风味参数区分 openSUSE Tumbleweed、openSUSE Leap、SLES、SLE Micro；
• Azure 家族由 azure.NewAzureScanner() 与 azure.NewMarinerScanner()（对应 CBL-Mariner/Azure Linux）覆盖。

路由逻辑 resolve() 的判定顺序是：先尝试 suppliers，再回退到标准 drivers 表：

for _, supplier := range r.suppliers { if d := supplier(os, pkgs); d != nil { return d } }
if d, ok := r.drivers[os.Family]; ok { return d }
log.Warn("Unsupported os", ...)
return nil, ErrUnsupportedOS

也就是说，扫描目标 OS 家族不在上述 map 中时，会打出 Unsupported os 告警并返回 ErrUnsupportedOS——对应到用户侧，就是某个系统“不在支持矩阵内、无法做 OS 包漏洞检测”。

suppliers：RapidFort / RootIO / Seal 等动态供应商

在标准驱动之前，suppliers（pkg/detector/ospkg/detect.go）会先被尝试：

suppliers = []driver.Supplier{
	rapidfort.Supplier,
	rootio.Supplier,
	seal.Supplier,
}

这类 supplier 会结合包信息与环境探测“动态生成”驱动，用于覆盖第三方重建发行包的系统（对应 docs/guide/coverage/others/rapidfort.md、rootio.md、seal.md）。Detect 流程还有一个细节：默认会丢弃来自第三方仓库（如 EPEL、Docker 安装的包），因为“OS 厂商公告并不会描述它们”；但如果某驱动自身的数据源本就覆盖这类包（Echo、Seal、RapidFort），它会实现 PackageFilter 接口把包保留下来继续检测（pkg/detector/ospkg/detect.go）。

版本支持判定与 EOL 感知

检测器还承担“该版本是否仍在支持期”的判定（pkg/detector/ospkg/detect.go）：

eosl := !d.driver.IsSupportedVersion(ctx, d.target.OS.Family, d.target.OS.Name)

每个驱动实现 IsSupportedVersion，用各自维护的“支持版本范围”去比对 OS 具体版本；超出范围即视为 EOL（End of Life），并通过返回值向上传递，供报告层做 EOL 感知标记。版本比较的基础设施集中在 pkg/detector/ospkg/version/（version.go、compare.go、constraint.go）。这正对应各详情页功能表中的“End of life awareness”。

OS 分析发生在哪一步

OS 识别属于前置分析阶段：pkg/fanal/analyzer/os 下的分析器解析 /etc/os-release 等文件得到 family + name，随后漏洞检测阶段才依据 pkg/fanal/types/const.go 的 OSType 去查驱动。整体可以概括为一条链路：

镜像/文件系统 → OS 分析器（识别 family/name） → 包分析器（apk/rpm/dpkg… 列出包清单） → ospkg.Detector 按 OSType 路由到具体驱动 → 驱动调用各发行版安全公告数据比对 → 输出漏洞结果

详情页里的通用维度：以 RHEL 与 Ubuntu 为例

索引表之下，各详情页承载了更细的“功能与数据质量”说明，虽然每一页的 OS 不同，但栏目结构高度一致。以 rhel.md 为例，典型栏目包括：

• 功能总览：未修复漏洞（Unfixed vulnerabilities）、依赖关系图（对应 vulnerability origin 溯源）、EOL 感知，三者均标注支持；
• SBOM 覆盖范围：仅识别通过 dnf/yum 等包管理器安装的包；
• 数据来源（Data Source）：指向 docs/guide/scanner/vulnerability.md 的 Data Sources 小节（各发行版使用各自官方公告，而非一律 NVD）；
• 修复版本与上游差异：RHEL 的修复版本是其自研补丁版本号，例如 CVE-2023-0464 在 RHEL 9 的修复版本是 3.0.7-16.el9_2，而上游是 3.0.9/3.1.1，不能混淆；
• 严重级别映射：RHEL 使用“Impact”字段，NVD 严重性仅作兜底，映射关系为：

Red Hat Impact	Trivy 严重级别
Low	Low
Moderate	Medium
Important	High
Critical	Critical

• 漏洞状态（Status）：RHEL 支持 Fixed / Affected / Under Investigation / Will Not Fix / Fix Deferred / End of Life 全部六种状态；其中 End of Life 状态会被检出（RHEL 提示应按受影响对待），而 Under Investigation 状态不会被检出（需等待调查结论）。状态过滤的具体使用见 docs/guide/configuration/filtering.md；
• License 来源：通过解析 RPM 包的元数据识别许可证。

ubuntu.md 的栏目结构类似，但细节差异体现出“每发行版独立公告体系”的原则：Ubuntu 采用其 [Security Tracker] 的 Priority 字段计算严重级别（NVD 仅兜底），例如 CVE-2019-15052 在 NVD 是 Critical、而 Ubuntu 标记为 Medium，Trivy 便显示 Medium；修复版本也以 Ubuntu 补丁为准（如 CVE-2023-3269 在 lunar 的修复版本是 6.2.0-26.26 而非上游 6.5）。

这些“页面级”差异恰恰是阅读支持矩阵时最容易踩坑的地方：同一份索引表只能回答“支不支持”，具体到严重级别口径、可报告的状态集、能否检出未修复漏洞，请以对应发行版详情页为准。

实操建议：使用前如何确认支持情况

• 先对照本文“支持的操作系统一览”定位你的目标系统与版本；滚动发行或未列出的小版本通常不被保证，应以各详情页“支持的版本”口径为准；
• 需要漏洞检测时，确认系统家族在 pkg/detector/ospkg/detect.go 的 drivers 注册表内；扫描时若日志出现 Unsupported os 并返回“unsupported os”错误，即表示当前 OS 不支持 OS 包级漏洞检测（此时仍可尝试 SBOM 等其它模式）；
• 同源系统注意别被“名字相近”误导：CentOS 可用但 CentOS Stream 不可用；RHEL 6-9 全能力而 RHEL 10 目前仅 SBOM；CoreOS（Fedora CoreOS / CoreOS Container Linux）仅 SBOM；
• 生成 SBOM 的用法可参考 docs/guide/supply-chain/sbom.md，漏洞报告与许可证检测分别参见 docs/guide/scanner/vulnerability.md 与 docs/guide/scanner/license.md。

支持边界的限制说明

• 上表“支持版本”是当前仓库文档所声明的范围，会随 Trivy 版本演进调整，请以所使用版本的仓库文档为准；
• 由于每个发行版的公告数据源不同，可检出的漏洞状态集、严重级别口径、修复版本号语义在各系统间并不完全一致，不能把某一页的规则机械推广到其它发行版；
• “支持”不等于“每个版本都能检出所有漏洞”：未修复（unfixed）检测、EOL 标记、依赖图等能力是逐系统开关的，具体能力请以各详情页功能表为准。

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