1 はじめに
新規に脆弱性（CVE）が見つかった場合、運用する環境への影響を即座に確認し、必要であれば速やかにパッチ適用などの対応を行う必要があります。しかし、実際に運用している環境の中に該当の脆弱性が含まれているかどうかを即座に調べることは、容易ではありません。
この課題を解決するのが、Trivy Operatorです。Trivy Operatorは、ワークロード（DeploymentやDaemonSetなど）が作成または更新されると、そのワークロードで使用されるコンテナイメージを自動的にスキャンし、イメージに含まれる脆弱性を検出するツールです。
検出結果は VulnerabilityReport というKubernetesリソースとして保存されるため、kubectl コマンドを使用して、クラスタ内で利用されているコンテナイメージにどのような脆弱性が存在するかを確認できます。
本記事では、Trivy Operatorを導入し、実際に稼働中のPodが特定のCVEに該当するかどうかを検証します。
なお、本記事は、以下の記事で紹介している手順が完了していることを前提としています。
2 検証環境
2.1 ネットワーク構成
検証環境は、VMware Workstation Pro上に構築した3台の仮想マシンでKubernetesクラスタを構成しています。各仮想マシンはブリッジ接続により、PCと同じネットワーク（192.168.1.0/24）に接続されています。
一方、10.244.0.0/16 は、CalicoのCNIプラグインによってクラスタ内に作成されるPodネットワークです。各Podにはこのアドレス帯からIPアドレスが割り当てられ、異なるノード上のPod同士が相互に通信する際に使用されます。Calicoは各ノードに経路を設定することで、Pod間通信を透過的に実現しています。
+--- control ---+ +--- worker1 ---+ +--- worker2 ---+
|AlmaLinux 10.2 | |AlmaLinux 10.2 | |AlmaLinux 10.2 |
| | | | | |
| Pod | | Pod | | Pod |
| | | | | | | | |
| 10.244.x.0/24 | | 10.244.y.0/24 | | 10.244.z.0/24 |
| ------------- | | ------------- | | ------------- |
| | | | | |
+-------+-------+ +-------+-------+ +-------+-------+
|.19 |.20 |.22
| | |
| 192.168.1.0/24 | |
+--------------------------------------------------------+
| VMware Workstation Pro（Bridged networking） |
+--------------------------------------------------------+
|
+---------------+
| |
| PC |
| |
+---------------+
それぞれの役割は以下のとおりです。
1台をコントロールノード、2台をワーカーノードとして使用します。
| ホスト名 | 名称 | 役割 |
|---|---|---|
| control | コントロールノード | クラスタ（control、worker1、worker2）の状態を管理し、Pod をどのノードで実行するかを決定するノード |
| worker1 | ワーカーノード | Pod を実行するノード |
| worker2 | ワーカーノード | Pod を実行するノード |
2.2 ソフトウェアのバージョン
各ノードのAlmaLinuxバージョンは以下のとおりです。
[root@control ~]# cat /etc/redhat-release
AlmaLinux release 10.2 (Lavender Lion)
各ノードのカーネルバージョンは以下のとおりです。
[root@control ~]# uname -r
6.12.0-211.7.3.el10_2.x86_64
Kubernetesのバージョンは以下のとおりです。
[root@control ~]# kubectl version
Client Version: v1.36.2
Kustomize Version: v5.8.1
Server Version: v1.36.2
2.3 ノードのリソース
各ノードには4GBのメモリを割り当てています。
[root@control ~]# free -h
total used free shared buff/cache available
Mem: 3.6Gi 1.3Gi 1.0Gi 5.8Mi 1.5Gi 2.3Gi
Swap: 0B 0B 0B
各ノードは 4コアのCPU（4 vCPU） を搭載しています。
[root@control ~]# lscpu -xe
CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE
0 0 0 0 0:0:0:0 yes
1 0 1 1 1:1:1:1 yes
2 0 2 2 2:2:2:2 yes
3 0 3 3 3:3:3:3 yes
lscpuコマンドの詳しい使い方は、以下のページをご覧ください。
3 事前準備
3.1 Harborのホスト名登録
すべてのノード（コントロールノード、ワーカーノード）の /etc/hosts に、Harbor（harbor.home.lab）のIPアドレスを登録します。これにより、各ノードがharbor.home.labというホスト名でHarborを参照できるようになります。
[root@control ~]# cat /etc/hosts
-snip-
192.168.1.10 control
192.168.1.11 worker1
192.168.1.12 worker2
192.168.1.200 harbor.home.lab
3.2 ワーカーノードへのCA証明書の配置（全てのワーカーノードで実施）
コントロールノードには、HarborをHTTPS化した際に作成したCA証明書がすでに配置されています。
[root@control ~]# find . -name ca.crt
./harbor-certs/ca.crt
CA証明書の作成方法は、以下の記事で説明していますので参考にしてください。
全てのワーカーノードに、CA証明書を配置するためのディレクトリを作成します。CA証明書はワーカーノードのcontainerdがHarborへHTTPSで接続する際、Harborから送られてくるサーバー証明書の署名を検証するために使用します。今回のHarborは自己署名のCA証明書で署名されているため、そのCA証明書をワーカーノードへ配置する必要があります。
[root@worker1 ~]# mkdir -p /etc/containerd/certs.d/harbor.home.lab
[root@worker2 ~]# mkdir -p /etc/containerd/certs.d/harbor.home.lab
コントロールノードで作成したCA証明書を、全てのワーカーノードへコピーします。
[root@control ~]# scp /root/harbor-certs/ca.crt worker1:/etc/containerd/certs.d/harbor.home.lab/ca.crt
root@worker1's password:
ca.crt 100% 2033 267.8KB/s 00:00
[root@control ~]# scp /root/harbor-certs/ca.crt worker2:/etc/containerd/certs.d/harbor.home.lab/ca.crt
root@worker2's password:
ca.crt 100% 2033 969.9KB/s 00:00
全てのワーカーノードで、containerdがHarborへHTTPS接続する際に参照する設定ファイルhosts.tomlを作成します。caにはCA証明書のパスを配列形式で指定します。
[root@worker1 ~]# vi /etc/containerd/certs.d/harbor.home.lab/hosts.toml
[root@worker1 ~]# cat /etc/containerd/certs.d/harbor.home.lab/hosts.toml
server = "https://harbor.home.lab"
[host."https://harbor.home.lab"]
ca = ["/etc/containerd/certs.d/harbor.home.lab/ca.crt"]
3.3 containerdのレジストリ証明書参照設定（全てのワーカーノードで実施）
全てのワーカーノードでcontainerdの設定ファイル(config.toml)を編集します。設定ファイルはデフォルトでは存在しないため、以下のように実行して作成します。
[root@worker1 ~]# containerd config default > /etc/containerd/config.toml
編集前に、変更差分を確認できるよう設定ファイルのバックアップを取得します。
[root@worker1 ~]# cp /etc/containerd/config.toml /etc/containerd/config.toml.org
containerdがCA証明書を格納したディレクトリを参照するようconfig_pathを設定します。
[root@worker1 ~]# vi /etc/containerd/config.toml
変更内容を確認します。config_pathにCA証明書を格納したディレクトリを指定しています。なお、SystemdCgroup = trueはKubernetes構築時に設定済みの内容です。
[root@worker1 ~]# diff -Nur /etc/containerd/config.toml.org /etc/containerd/config.toml
--- /etc/containerd/config.toml.org 2026-07-14 09:12:25.609474288 +0900
+++ /etc/containerd/config.toml 2026-07-22 19:59:21.408811282 +0900
@@ -51,7 +51,7 @@
sandbox = 'registry.k8s.io/pause:3.10.1'
[plugins.'io.containerd.cri.v1.images'.registry]
- config_path = ''
+ config_path = '/etc/containerd/certs.d'
[plugins.'io.containerd.cri.v1.images'.image_decryption]
key_model = 'node'
@@ -106,7 +106,7 @@
NoNewKeyring = false
Root = ''
ShimCgroup = ''
- SystemdCgroup = false
+ SystemdCgroup = true
[plugins.'io.containerd.cri.v1.runtime'.cni]
bin_dir = ''
Harbor用の証明書ファイルが正しく配置されていることを確認します。
[root@worker1 ~]# ls -l /etc/containerd/certs.d/harbor.home.lab/
合計 8
-rw-r--r--. 1 root root 2033 7月 22 19:51 ca.crt
-rw-r--r--. 1 root root 127 7月 22 20:32 hosts.toml
設定を反映するため、containerdを再起動します。
[root@worker1 ~]# systemctl restart containerd
3.4 Harborのデプロイ防止ポリシーの無効化
Harborには、指定した重大度以上の脆弱性を含むイメージのpullを禁止するポリシー（Prevent vulnerable images from running）があります。今回は脆弱性を含むイメージをTrivy Operatorでスキャンすることが目的であるため、このポリシーを一時的に無効化します。
3.5 Harborの名前解決設定
Trivy Operatorが作成するスキャン用Podは、イメージをpullする際にHarbor(harbor.home.lab)へアクセスします。そのため、harbor.home.labをIPアドレスに変換するための設定を追加します。
CoreDNSの設定はConfigMapとして管理されているため、kubectl editコマンドで編集します。
[root@control ~]# kubectl edit configmap coredns -n kube-system
CoreDNSの設定ファイルにhosts を追加します
prometheus :9153
hosts {
192.168.1.200 harbor.home.lab
fallthrough
}
forward . /etc/resolv.conf {
max_concurrent 1000
}
設定を反映するため、CoreDNSのDeploymentを再起動します。
[root@control ~]# kubectl rollout restart deployment coredns -n kube-system
一時的にBusyBoxコンテナを起動し、Harbor(harbor.home.lab)の名前解決が正常に行えることを確認します
[root@control ~]# kubectl run dns-test --image=busybox:1.28 --rm -it --restart=Never -- nslookup harbor.home.lab
Server: 10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local
Name: harbor.home.lab
Address 1: 192.168.1.200 harbor.home.lab
All commands and output from this session will be recorded in container logs, including credentials and sensitive information passed through the command prompt.
If you don't see a command prompt, try pressing enter.
Session ended, resume using 'kubectl attach dns-test -c dns-test -n default -i -t' command
pod "dns-test" deleted from default namespace
4 Trivy Operatorのインストール手順
Trivy Operatorが含まれるリポジトリをaquaという名前で登録します。
[root@control ~]# helm repo add aqua https://aquasecurity.github.io/helm-charts/
"aqua" has been added to your repositories
登録済みリポジトリを確認します。
[root@control ~]# helm repo list
NAME URL
metallb https://metallb.github.io/metallb
ingress-nginx https://kubernetes.github.io/ingress-nginx
harbor https://helm.goharbor.io
aqua https://aquasecurity.github.io/helm-charts/
Helmはリポジトリ情報をローカルにキャッシュしており、古いキャッシュのままでは最新バージョンのチャートがインストールできない場合があるため、helm repo updateコマンドを実行して最新のチャート情報を取得します。
[root@control ~]# helm repo update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "metallb" chart repository
...Successfully got an update from the "aqua" chart repository
...Successfully got an update from the "ingress-nginx" chart repository
...Successfully got an update from the "harbor" chart repository
Update Complete. ?Happy Helming!?
Trivy Operator 用の namespace を作成します。
[root@control ~]# kubectl create namespace trivy-system
namespace/trivy-system created
Trivy Operator用の設定ファイルを保存するディレクトリを作成します。
[root@control ~]# mkdir -p ~/trivy-operator-install
trivy-operatorの設定ファイル(values.yaml)を作成します。sslCertDirには、CA証明書を格納したディレクトリを指定します。Trivy Operatorは、このディレクトリをhostPathボリュームとしてスキャン用Podにマウントし、プライベートレジストリとのHTTPS通信で使用するCA証明書として利用します。また、ignoreUnfixed: falseを設定することで、修正版が提供されていない脆弱性についても除外せず、検出結果に含めるようになります。
[root@control ~]# vi ~/trivy-operator-install/values.yaml
[root@control ~]# cat ~/trivy-operator-install/values.yaml
trivy:
ignoreUnfixed: false
sslCertDir: "/etc/containerd/certs.d/harbor.home.lab"
useBuiltinCache: false
operator:
scanJobsConcurrentLimit: 1
scanJobsConcurrentLimit は、同時に実行できるスキャンジョブの最大数を指定するパラメータです。今回の検証環境では、当初このパラメータを設定していなかったため、複数のスキャンジョブが同時に実行され、スキャンが完了しない状況が発生しました。そこで、この値を 1 に設定したところ、スキャンが正常に完了しました。環境によっては、同時実行数を増やしても問題なく動作するため、利用するクラスタのリソース状況に応じて適切な値を設定するとよいでしょう。
作成した values.yaml を指定して、Trivy Operator をインストールします。
[root@control ~]# helm install trivy-operator aqua/trivy-operator --namespace trivy-system -f ~/trivy-operator-install/values.yaml
NAME: trivy-operator
LAST DEPLOYED: Sun Jul 26 08:49:21 2026
NAMESPACE: trivy-system
STATUS: deployed
REVISION: 1
DESCRIPTION: Install complete
TEST SUITE: None
NOTES:
You have installed Trivy Operator in the trivy-system namespace.
It is configured to discover Kubernetes workloads and resources in
all namespace(s).
Inspect created VulnerabilityReports by:
kubectl get vulnerabilityreports --all-namespaces -o wide
Inspect created ConfigAuditReports by:
kubectl get configauditreports --all-namespaces -o wide
Inspect the work log of trivy-operator by:
kubectl logs -n trivy-system deployment/trivy-operator
Helm リリース一覧を確認します。
[root@control ~]# helm list -n trivy-system
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
trivy-operator trivy-system 1 2026-07-26 08:49:21.026057855 +0900 JST deployed trivy-operator-0.34.0 0.32.0
インストール直後は、クラスタ内で稼働している全てのワークロードを対象に、スキャンが一斉に開始されます。Trivy Operatorはワークロード1つに対してスキャン用Pod（scan-vulnerabilityreport-*）を1つ生成し、スキャンが完了すると自動的に削除します。スキャン対象のワークロードが複数存在する場合、この処理がワークロードの数だけ繰り返されるため、インストール直後はscan-vulnerabilityreport-*という名前のPodの生成と終了が続く状態になります。
[root@control ~]# kubectl get pods -n trivy-system
NAME READY STATUS RESTARTS AGE
node-collector-855455d7f8-2bflx 0/1 Pending 0 58s
scan-vulnerabilityreport-7b99c4b95d-wts2h 1/1 Running 0 60s
trivy-operator-5f54f465b7-nbrwh 1/1 Running 0 62s
以下のコマンドを実行すると、スキャン結果のレポートが順次作成されていく様子が確認できます。最終的にはクラスタ内の全てのPodに対するレポートが表示されますが、全てのレポートが出揃うのを待たずに次の手順に進んでも問題ありません。
[root@control ~]# kubectl get vulnerabilityreports -A
NAMESPACE NAME REPOSITORY TAG SCANNER AGE
harbor statefulset-harbor-database-database goharbor/harbor-db v2.15.1 Trivy 36s
harbor statefulset-harbor-trivy-trivy goharbor/trivy-adapter-photon v2.15.1 Trivy 91s
kube-system pod-kube-scheduler-control-kube-scheduler kube-scheduler v1.36.2 Trivy 41s
5 動作確認
ここでは、Harborに登録したNginxのイメージを使ってPodを起動し、Trivy Operatorが脆弱性レポートを生成できることを確認します。
(1) Harbor認証用のSecretを作成
Nginxのイメージを登録したlibraryプロジェクトは、Privateに設定しているため、containerdがHarborからイメージをpullする際に認証が必要です。Harborの認証情報をSecretとして登録します。
[root@control ~]# kubectl create secret docker-registry harbor-cred \
--docker-server=harbor.home.lab \
--docker-username=admin \
--docker-password=Harbor12345 \
--docker-email=dummy@example.com \
-n default
secret/harbor-cred created
Secretが作成されたことを確認します。
[root@control ~]# kubectl get secrets
NAME TYPE DATA AGE
harbor-cred kubernetes.io/dockerconfigjson 1 13s
(2) Deploymentマニフェストの作成
Harborに登録したNginxのイメージ（nginx:1.30）を使用するDeploymentのマニフェストを作成します。imagePullSecretsに先ほど作成したSecretを指定することで、HarborのPrivateプロジェクトからイメージをpullできるようになります。
[root@control ~]# vi nginx-test.yaml
[root@control ~]# cat nginx-test.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-test
namespace: default
spec:
replicas: 1
selector:
matchLabels:
app: nginx-test
template:
metadata:
labels:
app: nginx-test
spec:
containers:
- name: nginx
image: harbor.home.lab/library/nginx:1.30
imagePullSecrets:
- name: harbor-cred
(3) Pod起動確認
マニフェストを適用してDeploymentを作成します。
[root@control ~]# kubectl apply -f nginx-test.yaml
deployment.apps/nginx-test created
Podが正常に起動していることを確認します。
[root@control ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-test-654b84664c-dvhp7 1/1 Running 0 11s
(4) Trivy Operatorの動作確認
Trivy Operatorは、ワークロードで使用されているコンテナイメージを自動的にスキャンし、脆弱性レポートを生成します。まずは、Trivy Operatorが正常に起動していることを確認します。
[root@control ~]# kubectl get pods -n trivy-system
NAME READY STATUS RESTARTS AGE
node-collector-855455d7f8-2nknj 0/1 Pending 0 40s
scan-vulnerabilityreport-5769c7bbdb-psnqd 0/1 Init:0/1 0 6s
trivy-operator-5f54f465b7-nbrwh 1/1 Running 0 9m30s
(5) VulnerabilityReportの生成確認
スキャン結果は、VulnerabilityReportリソースとして保存されます。
[root@control ~]# kubectl get vulnerabilityreports
NAME REPOSITORY TAG SCANNER AGE
replicaset-nginx-test-654b84664c-nginx library/nginx 1.30 Trivy 3m54s
他のPodのスキャン結果は、-Aオプションを指定することで確認できます。
[root@control ~]# kubectl get vulnerabilityreports -A
NAMESPACE NAME REPOSITORY TAG SCANNER AGE
default replicaset-nginx-test-654b84664c-nginx library/nginx 1.30 Trivy 15m
harbor replicaset-harbor-core-57b57bcdd5-core goharbor/harbor-core v2.15.1 Trivy 11m
harbor replicaset-harbor-jobservice-7cddc45866-jobservice goharbor/harbor-jobservice v2.15.1 Trivy 19m
harbor replicaset-harbor-portal-5b6bc45d5c-portal goharbor/harbor-portal v2.15.1 Trivy 18m
harbor replicaset-harbor-registry-748df588c7-registry goharbor/registry-photon v2.15.1 Trivy 20m
harbor statefulset-harbor-database-database goharbor/harbor-db v2.15.1 Trivy 25m
harbor statefulset-harbor-redis-redis goharbor/redis-photon v2.15.1 Trivy 24m
harbor statefulset-harbor-trivy-trivy goharbor/trivy-adapter-photon v2.15.1 Trivy 26m
ingress-nginx replicaset-ingress-nginx-controller-5cd9869bf8-controller ingress-nginx/controller v1.15.1 Trivy 14m
kube-system daemonset-calico-node-calico-node calico/node v3.32.1 Trivy 10m
kube-system daemonset-kube-proxy-kube-proxy kube-proxy v1.36.2 Trivy 8m47s
kube-system pod-etcd-control-etcd etcd 3.6.8-0 Trivy 23m
kube-system pod-kube-apiserver-control-kube-apiserver kube-apiserver v1.36.2 Trivy 24m
kube-system pod-kube-controller-manager-control-kube-controller-manager kube-controller-manager v1.36.2 Trivy 21m
kube-system pod-kube-scheduler-control-kube-scheduler kube-scheduler v1.36.2 Trivy 25m
kube-system replicaset-7d57bc9844 calico/kube-controllers v3.32.1 Trivy 21m
kube-system replicaset-coredns-779fc6c7c4-coredns coredns/coredns v1.14.2 Trivy 15m
local-path-storage replicaset-c64f4fcf9 rancher/local-path-provisioner v0.0.36 Trivy 13m
metallb-system replicaset-metallb-controller-bc9cbb54b-controller metallb/controller v0.16.1 Trivy 12m
trivy-system replicaset-trivy-operator-5f54f465b7-trivy-operator aquasec/trivy-operator 0.32.0 Trivy 24m
6 脆弱性の確認
Trivy Operatorによって生成されたVulnerabilityReportを使い、脆弱性の確認方法を説明します。特定のPodに絞った確認と、クラスタ全体を横断した確認の2つの観点で説明します。
6.1 特定のPodの脆弱性確認
まず、default namespaceに存在するVulnerabilityReportの一覧を確認します。
[root@control ~]# kubectl get vulnerabilityreports -n default
NAME REPOSITORY TAG SCANNER AGE
replicaset-nginx-test-654b84664c-nginx library/nginx 1.30 Trivy 40m
(1) 特定のPodに含まれる脆弱性を表示する方法
nginx:1.30に含まれる全CVEを、CVE ID・重大度・対象パッケージ・インストール済みバージョン・修正済みバージョンの形式で表示します。fixedVersionが空のものは、現時点で修正版が提供されていないCVEです。
[root@control ~]# kubectl get vulnerabilityreport replicaset-nginx-test-654b84664c-nginx -n default -o json | jq '.report.vulnerabilities[] | {id: .vulnerabilityID, severity: .severity, resource: .resource, installedVersion: .installedVersion, fixedVersion: .fixedVersion}'
{
"id": "CVE-2011-3374",
"severity": "LOW",
"resource": "apt",
"installedVersion": "3.0.3",
"fixedVersion": ""
}
{
"id": "TEMP-0841856-B18BAF",
"severity": "LOW",
"resource": "bash",
"installedVersion": "5.2.37-2+b9",
"fixedVersion": ""
}
-snip-
(2) CVE件数のサマリー表示
nginxに含まれる脆弱性の総数、修正版が提供されているCVE数、修正版が未提供のCVE数を表示します。nginx:1.30の場合、合計347件の脆弱性が検出されており、修正版が提供されているものは1件、残りの346件は現時点で修正未提供の状態です。
[root@control ~]# kubectl get vulnerabilityreport replicaset-nginx-test-654b84664c-nginx -n default -o json | \
jq '{total: (.report.vulnerabilities | length), fixable: [.report.vulnerabilities[] | select(.fixedVersion != "")] | length, unfixable: [.report.vulnerabilities[] | select(.fixedVersion == "")] | length}'
{
"total": 347,
"fixable": 1,
"unfixable": 346
}
(3) 修正版が存在するCVEのみ表示
修正版が提供されているCVEのみを絞り込んで表示します。対応可能な脆弱性を優先的に把握したい場合に使用します。
[root@control ~]# kubectl get vulnerabilityreport replicaset-nginx-test-654b84664c-nginx -n default -o json | \
jq '.report.vulnerabilities[] | select(.fixedVersion != "") | {id: .vulnerabilityID, severity: .severity, resource: .resource, installedVersion: .installedVersion, fixedVersion: .fixedVersion}'
{
"id": "CVE-2026-12912",
"severity": "UNKNOWN",
"resource": "libtiff6",
"installedVersion": "4.7.0-3+deb13u2",
"fixedVersion": "4.7.0-3+deb13u3"
}
[root@control ~]#
6.2 システム全体の脆弱性確認
(1) 全ワークロードの脆弱性サマリー表示
クラスタ内の全ワークロードについて、重大度別（Critical・High・Medium・Low・Unknown）のCVE件数を一覧表示します。どのコンポーネントにどの程度の脆弱性が存在するかを把握するのに役立ちます。
[root@control ~]# kubectl get vulnerabilityreports -A -o json | \
jq '.items[] | {namespace: .metadata.namespace, name: .metadata.name, critical: .report.summary.criticalCount, high: .report.summary.highCount, medium: .report.summary.mediumCount, low: .report.summary.lowCount, unknown: .report.summary.unknownCount}'
{
"namespace": "default",
"name": "replicaset-nginx-test-654b84664c-nginx",
"critical": 4,
"high": 16,
"medium": 35,
"low": 111,
"unknown": 181
}
{
"namespace": "harbor",
"name": "replicaset-harbor-core-57b57bcdd5-core",
"critical": 6,
"high": 46,
"medium": 56,
"low": 5,
"unknown": 32
}
-snip-
(2) 特定のCVEに該当するワークロードを横断検索
新たなCVEが公表された際、そのCVEに該当するワークロードがクラスタ内のどこで稼働しているかを即座に特定できます。以下はCVE-2026-12912を例に検索した結果です。
[root@control ~]# kubectl get vulnerabilityreports -A -o json | jq '.items[] | select(.report.vulnerabilities[]?.vulnerabilityID == "CVE-2026-12912") | {namespace: .metadata.namespace, name: .metadata.name}'
{
"namespace": "default",
"name": "replicaset-nginx-test-654b84664c-nginx"
}