Trivy 不直接扫描 Kubernetes 节点宿主机操作系统，但可通过扫描节点组件容器镜像、本地已拉取镜像及挂载的文件系统（如 dpkg/rpm 清单）间接评估系统级漏洞；推荐优先批量扫描 kube-proxy、etcd 等组件镜像并聚焦 HIGH/CRITICAL OS 包漏洞。

Trivy 本身不直接扫描 Kubernetes 节点（即宿主机）的操作系统漏洞，它主要面向容器镜像、文件系统、Kubernetes资源配置、SBOM/KBOM 等目标。但你可以通过合理组合方式，间接覆盖节点上运行的关键组件所依赖的系统级漏洞——关键是明确“节点组件”指什么，并选择对应扫描路径。

下面分三类常见场景说明如何有效利用 Trivy 实现系统级漏洞评估：

明确目标：哪些“节点组件”可被 Trivy 覆盖？

Kubernetes 节点上的关键组件通常包括：

• kubelet、kube-proxy、containerd（或 docker）、etcd 等二进制本身（运行在宿主机上）
• 它们所依赖的基础操作系统包（如 Ubuntu/Debian 的 apt 包、CentOS/RHEL 的 rpm 包）
• 这些组件以容器形式部署时所用的镜像（例如 k8s.gcr.io/kube-proxy:v1.28.9）

⚠️ 注意：Trivy 不能直接 SSH 登录节点执行 apt list --upgradable 或 yum updateinfo list security；它不替代 lynis、oscap 或 kube-bench 对宿主机配置的检查。

但 Trivy 可以精准扫描：

• 所有以容器方式运行的控制平面/节点组件镜像（如 kube-proxy、coredns、etcd 镜像）
• 节点上已拉取的本地镜像（含你自建的运维工具镜像、日志采集器等）
• 若节点文件系统可挂载访问（如调试用的 hostPath 卷），也可扫描其 /usr/bin、/lib 等路径

---

扫描集群中所有容器化节点组件镜像（推荐首选）

这是最实用、最符合云原生安全左移原则的方式：

1. 提取所有节点组件使用的镜像

   kubectl get pods -A -o jsonpath='
     {range .items[*]}{range .spec.containers[*]}{.image}{"\n"}{end}{range .spec.initContainers[*]}{.image}{"\n"}{end}{end}
   ' | sort -u | grep -v '^\s*$'

   常见组件镜像示例：

   

   Kubernetes Network Policy Generator

   使用加权评分卡在12项标准上评估和比较隐私解决方案供应商。适用于选择隐私管理软件、比较数据保护方案等场景。

   下载
   • k8s.gcr.io/kube-proxy:v1.28.9
   • quay.io/coreos/etcd:v3.5.12
   • k8s.gcr.io/coredns/coredns:v1.11.3
   • registry.k8s.io/pause:3.9

2. 批量扫描并只关注 High/Critical 系统漏洞

   # 先确保数据库最新（首次或定期运行）
   trivy image --download-db-only
   
   # 批量扫描，仅输出高危及以上漏洞，跳过已知不可修复项（减少噪音）
   xargs -I {} trivy image \
     --severity HIGH,CRITICAL \
     --ignore-unfixed \
     --format table \
     --output {}.report.json \
     {} < image-list.txt

3. 解读结果重点看 “OS Packages” 分类 Trivy 报告中会明确标出：

   • 漏洞 ID（如 CVE-2023-45853）
   • 影响的 OS 包名与版本（如 openssl 3.0.2-0ubuntu1.10）
   • 是否有修复版本（Fixed Version 字段）
   • 所属发行版（如 ubuntu-22.04）

   ✅ 这就是你要的“系统级漏洞”评估依据——它告诉你：该镜像基于哪个 Linux 发行版、哪些基础包存在未修复漏洞。

---

扫描节点本地文件系统（需访问权限，适合离线审计）

如果你有节点 SSH 权限或可通过 hostPath 挂载根文件系统（如调试 Pod），可用 Trivy 扫描其 OS 包数据库：

1. 在节点上导出已安装包清单

   # Ubuntu/Debian
   dpkg-query -f '${binary:Package} ${Version}\n' -W > /tmp/dpkg-list.txt
   
   # CentOS/RHEL
   rpm -qa --queryformat '%{NAME} %{VERSION}-%{RELEASE}\n' > /tmp/rpm-list.txt

2. 用 Trivy 扫描该清单（无需容器运行时）

   trivy filesystem \
     --security-checks vuln \
     --scanners vulnerability \
     --input /tmp/dpkg-list.txt

   ⚠️ 此模式要求清单格式符合 Trivy 解析规范（如 dpkg-list.txt 可直用，rpm-list.txt 需转为 rpm -qa --qf "%{NAME} %{VERSION}-%{RELEASE}\n" 格式）。官方支持 dpkg, rpm, apk, pacman 四种包管理器清单。

---

不推荐也不可行的做法

• ❌ 在工作节点上直接运行 trivy image $(hostname) —— hostname 不是镜像名
• ❌ 试图用 trivy k8s cluster 扫描 kubelet 进程内存 —— Trivy 不做运行时进程分析
• ❌ 期望 Trivy 替代 kube-bench 检查 CIS 基准配置项 —— 这是不同维度（漏洞 vs 配置）

如需完整节点安全评估，应组合使用：

• Trivy → 评估镜像和 OS 包漏洞
• kube-bench → 评估 Kubernetes 组件配置合规性
• oscap 或 lynis → 评估宿主机操作系统加固状态

不复杂但容易忽略的是：真正影响生产安全的，往往不是某个 CVE 编号，而是你是否知道 coredns:v1.11.3 镜像里那个 glibc 2.35-0ubuntu3.6 包，已在 ubuntu-22.04 的 CVE 数据库中标记为 Critical，且修复版 2.35-0ubuntu3.7 已发布一周——Trivy 正是帮你快速定位这一事实的工具。